 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10-10-2017 16:10, clipka wrote:
> Am 10.10.2017 um 09:27 schrieb Stephen:
>
>>> I seem to remember to have had problems generating transparent png
>>> images while I never had problems with tga.
>>>
>>
>> I recognised the form of the spell. I had the same problem donkey's
>> years ago.
>> There was a time when PNGs behaved badly. I think it was not writing the
>> Alpha values in the output.
>
> If I may clarify:
>
> PNG output in POV-Ray v3.6 had the alpha mode wrong - i.e. how the alpha
> channel is supposed to interact with the colour channels.
>
> The PNG specification mandates so-called "straight alpha", i.e. the
> colour channels should hold the colour as if the image was fully opaque,
> and blending should be done entirely by the display software, using
> Alpha:(1-Alpha) as the ratio between stored colour and background. This
> is akin to the way in which semi-transparent pigments are specified in
> POV-Ray's SDL.
>
> However, POV-Ray's internal computations yield colour channel values
> that already take opacity into account, which is akin to so-called "gay
> alph..." uh, I mean, "associated alpha" aka "premultiplied alpha", in
> which the display software is only responsible for the background
> portion of the blending, using 1:(1-Alpha) as the ratio between stored
> colour and background.
>
> POV-Ray v3.6 neglected the issue of alpha mode entirely: In file output
> it directly wrote the computed colour values, thus always writing in
> associated alpha mode (which happens to be wrong for PNG files). In file
> input, on the other hand, it interpreted the colour values in much the
> same way as in SDL, thus always reading in straight alpha mode (which
> happens to be correct for PNG files but wrong for certain other files).
>
> So not only was POV-Ray v3.6 in violation of the PNG file format specs,
> it also was inconsistent in itself.
>
> In POV-Ray v3.7, a proper alpha handling framework was implemented, and
> the problem fixed for PNG files.
>
>
> (Interestingly, even though the modes are referred to as "associated
> alpha" and "straight alpha", it's not actually the alpha channel that's
> different between the two modes -- the value stored is actually
> identical for both modes -- but the colour channel.)
>
>
> The advantage of "straight alpha" is that you can display an opaque
> version of the image simply by ignoring the alpha channel.
>
> The advantages of "associated alpha" are that (a) it takes less
> computational effort to display, and (b) it can account for situations
> where bright light is to be shown against a highly transparent
> background (e.g. a transparent sphere with highlights).
>
It comes back now, yes. Thanks for the reminder. Interesting to notice
how it is former bad behaviour that sticks in the memory rather than the
later correction. Survival adaptation, no doubt ;-)
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10.10.2017 10:10, clipka wrote:
> Am 10.10.2017 um 09:27 schrieb Stephen:
>
>>> I seem to remember to have had problems generating transparent png
>>> images while I never had problems with tga.
>>>
>>
>> I recognised the form of the spell. I had the same problem donkey's
>> years ago.
>> There was a time when PNGs behaved badly. I think it was not writing the
>> Alpha values in the output.
>
> If I may clarify:
>
> PNG output in POV-Ray v3.6 had the alpha mode wrong - i.e. how the alpha
> channel is supposed to interact with the colour channels.
>
> The PNG specification mandates so-called "straight alpha", i.e. the
> colour channels should hold the colour as if the image was fully opaque,
> and blending should be done entirely by the display software, using
> Alpha:(1-Alpha) as the ratio between stored colour and background. This
> is akin to the way in which semi-transparent pigments are specified in
> POV-Ray's SDL.
>
> However, POV-Ray's internal computations yield colour channel values
> that already take opacity into account, which is akin to so-called "gay
> alph..." uh, I mean, "associated alpha" aka "premultiplied alpha", in
> which the display software is only responsible for the background
> portion of the blending, using 1:(1-Alpha) as the ratio between stored
> colour and background.
>
> POV-Ray v3.6 neglected the issue of alpha mode entirely: In file output
> it directly wrote the computed colour values, thus always writing in
> associated alpha mode (which happens to be wrong for PNG files). In file
> input, on the other hand, it interpreted the colour values in much the
> same way as in SDL, thus always reading in straight alpha mode (which
> happens to be correct for PNG files but wrong for certain other files).
>
> So not only was POV-Ray v3.6 in violation of the PNG file format specs,
> it also was inconsistent in itself.
>
> In POV-Ray v3.7, a proper alpha handling framework was implemented, and
> the problem fixed for PNG files.
>
>
> (Interestingly, even though the modes are referred to as "associated
> alpha" and "straight alpha", it's not actually the alpha channel that's
> different between the two modes -- the value stored is actually
> identical for both modes -- but the colour channel.)
>
>
> The advantage of "straight alpha" is that you can display an opaque
> version of the image simply by ignoring the alpha channel.
>
> The advantages of "associated alpha" are that (a) it takes less
> computational effort to display, and (b) it can account for situations
> where bright light is to be shown against a highly transparent
> background (e.g. a transparent sphere with highlights).
>
Interesting insight, thanks. :-)
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09.10.2017 06:56, Sven Littkowski wrote:
> Hi
>
> is it possible to create a scene where the rendered items are visible
> but the entire empty background becomes transparent, if the output image
> is a PNG?
>
> ---
> Diese E-Mail wurde von AVG auf Viren geprüft.
> http://www.avg.com
>
I want to mention another problem that I have since I switched monitors
(now using a 16:9 monitor): the object of the scene has shifted to the
right side.
I tried to create a better camera, but still fail to get the 0.0 center
of the scene as center of the camera. Any assistance?
This is what i have now:
camera
{
location < 0.0, 0.0, -50.0 >
look_at < 0.0, 0.0, 0.0 >
right 1.77*x
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 11.10.2017 um 12:31 schrieb Sven Littkowski:
> I want to mention another problem that I have since I switched monitors
> (now using a 16:9 monitor): the object of the scene has shifted to the
> right side.
>
> I tried to create a better camera, but still fail to get the 0.0 center
> of the scene as center of the camera. Any assistance?
>
> This is what i have now:
>
> camera
> {
> location < 0.0, 0.0, -50.0 >
> look_at < 0.0, 0.0, 0.0 >
> right 1.77*x
> }
That should work just fine -- at any resolution.
Are you sure it's not just your display software?
A test scene might be helpful.
(Also, I'd recommend using `right x*16/9` rather than the fudgy factor
of 1.77; with full-resolution renders it does make a difference of
something in the order of 10-20 pixels. Or use `right
x*image_width/image_height` to be independent of output image aspect ratio.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11.10.2017 06:49, clipka wrote:
> right
> x*image_width/image_height
Thanks. :-)
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Okay, here is the latest problem and also the scene code.
The value "AmountLines" allows me to set the amount of oar lines above
each other, but strangely, I always get just one line. I am very sure,
the fault is with me: "I am not seeing the forest because of all the
trees in my eyesight". Means, I am looking at the scene code, and just
can't discover the error in thinking/writing. Can you help?
---SCENE-------------------------------------------------------
#local Temp_version = version;
#version 3.7;
#declare MyRadiosity = off; // on
global_settings
{
#if(MyRadiosity)
radiosity
{
media on
pretrace_start 0.08
pretrace_end 0.001
count 400
error_bound 0.75
recursion_limit 1
normal on
}
#end
subsurface {}
adc_bailout 0.0039
ambient_light rgb < 0.000, 0.000, 0.000 >
assumed_gamma 1.000
irid_wavelength rgb < 0.250, 0.180, 0.140 >
max_trace_level 5
number_of_waves 10
noise_generator 3
charset ascii
}
camera
{
location < 7.0, 0.0, -50.0 >
look_at < 7.0, 0.0, 0.0 >
right x*image_width/image_height
}
light_source
{
< -50000.0, 50000.0, -50000.0 > //light position
color rgb < 1.0, 1.0, 1.0 > * 1.0
parallel
point_at < 0.0, 0.0, 0.0 >
}
//
---------------------------------------------------------------------------
-----------------------
#include "textures.inc"
#declare UpperOar = texture
{
DMFDarkOak
pigment { color rgb < 1.0, 1.0, 1.0 > }
normal { wood 0.5 scale 0.3 turbulence 0.1 }
finish { phong 1 }
rotate< 90.0, 0.0, 0.0 >
scale 0.25
}
#declare LowerOar = texture
{
DMFDarkOak
pigment { color rgb < 0.3, 0.01, 0.0 > }
normal { wood 0.5 scale 0.3 turbulence 0.1 }
finish { phong 1 }
rotate< 90.0, 0.0, 0.0 >
scale 0.25
}
#declare TotalLength = 10.0; // length of oars of the lowest line
#declare AmountOarsInLine = 30;
#declare AmountLines = 3;
#declare LineLeftShift = 0.5; // shift towards the left side for
additional lines
#declare LineHeightShift = 0.5; // distance to line below
#declare MyVariance = 4.0; // human irregularity
#declare MyHeightMore = 0.50; // upper lines need longer oars
#declare GeneralAngle = 40; // the angle of each oar from hull
towards water
#declare BladeAngle = 85.0; // the angle of the blade when
touching water
#declare ForwardAngle = 05.0; // to equalize the ends of each line
to the eye
#declare R1 = seed(1);
#declare R2 = seed(2);
#declare R3 = seed(3);
//
---------------------------------------------------------------------------
-----------------------
#macro MyOar(MyHeightMoreThis)
union
{
union
{
cone
{
< 0.0, -10.0, 0.0 > 0.000 < 0.0, -9.9, 0.0 > 0.250
}
cone
{
< 0.0, -9.9, 0.0 > 0.250 < 0.0, -5.5, 0.0 > 0.000
}
texture { LowerOar }
scale < 1.0, 1.0, 0.1 >
}
union
{
cone
{
< 0.0, -9.5, 0.0 > 0.020 < 0.0, -5.5, 0.0 > 0.075
}
cylinder
{
< 0.0, -5.5, 0.0 > < 0.0, 0.0, 0.0 > 0.075
}
#if(MyHeightMoreThis>0)
cylinder
{
< 0.0, MyHeightMoreThis, 0.0 > < 0.0, 0.0, 0.0 > 0.075
}
translate < 0.0, -MyHeightMoreThis, 0.0 >
#end
texture { UpperOar }
} no_shadow
}
#end
#declare MyNumber = 0;
#macro MyOarLine(AmountOarsInLine,MyHeightMoreThis)
union
{
#while(MyNumber<AmountOarsInLine)
#declare MyAngleWater = (rand(R1)*MyVariance)+GeneralAngle;
#declare MyAngleHands = (rand(R2)*MyVariance)+BladeAngle;
#declare MyAngleDirection = (rand(R3)*MyVariance)+ForwardAngle;
object
{
MyOar(MyHeightMoreThis)
rotate < 0.0, MyAngleHands, 0.0 >
rotate < MyAngleWater, 0.0, 0.0 >
rotate < 0.0, 0.0, MyAngleDirection >
translate < (MyNumber*0.925), 0.0, 0.0 >
}
#declare MyNumber = MyNumber+1;
#end
}
#end
union
{
#declare ThisLine = 0;
#while(ThisLine<AmountLines)
object { MyOarLine(AmountOarsInLine,MyHeightMore*ThisLine) translate <
-((AmountOarsInLine*0.925)/2)+0.925-(LineLeftShift*ThisLine),
LineHeightShift*ThisLine, 0.0 > }
#declare ThisLine=ThisLine+1;
#end
box
{
< -20.0, -15.0, 0.0 > < 20.0, 15.0, 0.1 >
pigment { color rgb < 1.0, 1.0, 1.0 > }
}
box
{
< -1.0, -25.0, 2.0 > < 1.0, 25.0, 2.1 >
pigment { color rgb < 0.5, 0.5, 0.5 > }
}
translate < 0.0, 0.0, 0.0 >
}
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sven Littkowski <I### [at] SvenLittkowski name> wrote:
> Okay, here is the latest problem and also the scene code.
>
> The value "AmountLines" allows me to set the amount of oar lines above
> each other, but strangely, I always get just one line. I am very sure,
> the fault is with me: "I am not seeing the forest because of all the
> trees in my eyesight". Means, I am looking at the scene code, and just
> can't discover the error in thinking/writing. Can you help?
> #declare ThisLine = 0;
> #while(ThisLine<AmountLines)
You never have a line that increments ThisLine.
Add
#declare ThisLine = ThisLine + 1;
or use a
#for (ThisLine, 1, 3)
....
#end
loop.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 11.10.2017 um 15:32 schrieb Bald Eagle:
> Sven Littkowski <I### [at] SvenLittkowskiname> wrote:
>> Okay, here is the latest problem and also the scene code.
>>
>> The value "AmountLines" allows me to set the amount of oar lines above
>> each other, but strangely, I always get just one line. I am very sure,
>> the fault is with me: "I am not seeing the forest because of all the
>> trees in my eyesight". Means, I am looking at the scene code, and just
>> can't discover the error in thinking/writing. Can you help?
>
>
>> #declare ThisLine = 0;
>> #while(ThisLine<AmountLines)
>
> You never have a line that increments ThisLine.
Actually he does.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
grrr.
Sorry, I was in the middle of handling a few thousand pounds of stuff and
clicked before I triple-read your code.
Now that I have a proper break:
Of course you had to have that increment, otherwise you'd have an infinite
loop...
But I do notice you're translating based on that value times 0.5. Is that
supposed to be 0.5 times --- some absolute height value? Maybe your vertical
translation is too small.
What if you create an array for your oar texture, and have each successive line
of oars be a different color - then it might be easier to see what's going on /
going wrong.
maybe output the location of the bounding boxes to the #debug stream as well...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 11.10.2017 um 14:41 schrieb Sven Littkowski:
> The value "AmountLines" allows me to set the amount of oar lines above
> each other, but strangely, I always get just one line. I am very sure,
> the fault is with me: "I am not seeing the forest because of all the
> trees in my eyesight". Means, I am looking at the scene code, and just
> can't discover the error in thinking/writing. Can you help?
[...]
> #declare MyNumber = 0;
>
>
> #macro MyOarLine(AmountOarsInLine,MyHeightMoreThis)
> union
> {
> #while(MyNumber<AmountOarsInLine)
>
> #declare MyAngleWater = (rand(R1)*MyVariance)+GeneralAngle;
> #declare MyAngleHands = (rand(R2)*MyVariance)+BladeAngle;
> #declare MyAngleDirection = (rand(R3)*MyVariance)+ForwardAngle;
> object
> {
> MyOar(MyHeightMoreThis)
> rotate < 0.0, MyAngleHands, 0.0 >
> rotate < MyAngleWater, 0.0, 0.0 >
> rotate < 0.0, 0.0, MyAngleDirection >
> translate < (MyNumber*0.925), 0.0, 0.0 >
> }
> #declare MyNumber = MyNumber+1;
> #end
> }
> #end
You need to set `MyNumber = 0` each time you're running the macro (i.e.
the `#declare` should be inside the macro. Also, I'd suggest using
`#local` instead; it's good practice for macros, unless you want to pass
values out of the macro via global variables.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
