Hello,

POV-Ray 3.7.0 64bit, Windows 8.1

I noticed that if a material has SSLT enabled and its pigment has a 
strong gradient, such as a dark line or black area the anti-aliasing 
breaks at the edge of the two colors. This is more noticeable if the 
image is high resolution.

See images below. The scene is a mesh sphere with an image map pigment. 
It was rendered with radiosity, anti-aliasing (+am2 +a0.01 +r3). The 
SSLT mm per units is 24.5.

no SSLT:
http://imgur.com/t2Oqqhm
Notice the anti-aliased transition between the colors on the sphere.

With SSLT (marble):
http://imgur.com/MoGWfDq
The edges between the colors are strongly aliased. Almost looks as if AA 
is switched off but the edge of the sphere shows that AA is active.

This happens with any AA and SSLT setting I use. Also image 
interpolation does not eliminate this effect. Only way to avoid it is 
not using SSLT.

You can download the scene, with SSLT enabled, from this Google drive link:
https://drive.google.com/file/d/0B0MYeki9vLYYRGtVRnZOZ0NMMG8/edit?usp=sharing

file->download to get the entire archive.



FlyerX

Post a reply to this message

FlyerX <fly### [at] yahoocom> wrote:
> Hello,
>
> POV-Ray 3.7.0 64bit, Windows 8.1
> file->download to get the entire archive.
> FlyerX

==== [Parsing...] ==========================================================
povray: backend/render/trace.cpp:3535: void
pov::Trace::ComputeDiffuseContribution(const pov::Intersection&,
const pov::Vector3d&, const pov::Vector3d&, const pov::Vector3d&,
const pov::Vector3d&, double&, double, double, double): Assertion `(sd >= 0.0)
&& (sd <= double(1.79769313486231570815e+308L))' failed.

Emergency stop

POV-Ray 3.7.0 64bit, Linux Mageia 3

Post a reply to this message

Am 29.11.2013 12:42, schrieb FlyerX:

> With SSLT (marble):
> http://imgur.com/MoGWfDq
> The edges between the colors are strongly aliased. Almost looks as if AA
> is switched off but the edge of the sphere shows that AA is active.

Try to avoid zero color components; for instance, you could use an 
"average" pigment with a small bit of white mixed in. Something like 
0.001 shoud already be sufficient.

What happens is that currently the SSLT code cannot yet cope with zero 
color components, belches out a "Not a Number" (NaN) value for that 
particular color channel, and the AA step is unable to handle that, 
computing the average of NaN and any other valid number as NaN. The 
image encoding algorithm then happens to encode the NaN as 0.

Post a reply to this message

On 11/29/2013 10:08 AM, clipka wrote:
> Am 29.11.2013 12:42, schrieb FlyerX:
>
>> With SSLT (marble):
>> http://imgur.com/MoGWfDq
>> The edges between the colors are strongly aliased. Almost looks as if AA
>> is switched off but the edge of the sphere shows that AA is active.
>
> Try to avoid zero color components; for instance, you could use an
> "average" pigment with a small bit of white mixed in. Something like
> 0.001 shoud already be sufficient.
>
> What happens is that currently the SSLT code cannot yet cope with zero
> color components, belches out a "Not a Number" (NaN) value for that
> particular color channel, and the AA step is unable to handle that,
> computing the average of NaN and any other valid number as NaN. The
> image encoding algorithm then happens to encode the NaN as 0.
>
Clipka,

Thank you very much for the tip. No wonder the red area in the render 
was completely noisy.

I added the following to the material:

#declare pave=pigment{average pigment_map{
     [1 p_map1]
     [1 color rgb 0.001]
   }
   }

and called pave in the material{} instead of p_map1 and the AA is back. 
There is a very small render time penalty (6%) but at least it works 
better now.

I will put this workaround in PoseRay tonight.

later,

FlyerX

Post a reply to this message

Am 29.11.2013 22:12, schrieb FlyerX:
> On 11/29/2013 10:08 AM, clipka wrote:
>> Am 29.11.2013 12:42, schrieb FlyerX:
>>
>>> With SSLT (marble):
>>> http://imgur.com/MoGWfDq
>>> The edges between the colors are strongly aliased. Almost looks as if AA
>>> is switched off but the edge of the sphere shows that AA is active.
>>
>> Try to avoid zero color components; for instance, you could use an
>> "average" pigment with a small bit of white mixed in. Something like
>> 0.001 shoud already be sufficient.
>>
>> What happens is that currently the SSLT code cannot yet cope with zero
>> color components, belches out a "Not a Number" (NaN) value for that
>> particular color channel, and the AA step is unable to handle that,
>> computing the average of NaN and any other valid number as NaN. The
>> image encoding algorithm then happens to encode the NaN as 0.
>>
> Clipka,
>
> Thank you very much for the tip. No wonder the red area in the render
> was completely noisy.
>
> I added the following to the material:
>
> #declare pave=pigment{average pigment_map{
>      [1 p_map1]
>      [1 color rgb 0.001]
>    }
>    }

I would instead suggest

   #declare pave=pigment{average pigment_map{
      [1 p_map1]
      [0.001 color rgb 1]
    }}

as this leaves the resulting color almost unchanged, whereas your 
solution gives any non-black color a significant blackshift.

Post a reply to this message

On 11/29/2013 4:04 PM, clipka wrote:
> Am 29.11.2013 22:12, schrieb FlyerX:
>> On 11/29/2013 10:08 AM, clipka wrote:
>>> Am 29.11.2013 12:42, schrieb FlyerX:
>>>
>>>> With SSLT (marble):
>>>> http://imgur.com/MoGWfDq
>>>> The edges between the colors are strongly aliased. Almost looks as
>>>> if AA
>>>> is switched off but the edge of the sphere shows that AA is active.
>>>
>>> Try to avoid zero color components; for instance, you could use an
>>> "average" pigment with a small bit of white mixed in. Something like
>>> 0.001 shoud already be sufficient.
>>>
>>> What happens is that currently the SSLT code cannot yet cope with zero
>>> color components, belches out a "Not a Number" (NaN) value for that
>>> particular color channel, and the AA step is unable to handle that,
>>> computing the average of NaN and any other valid number as NaN. The
>>> image encoding algorithm then happens to encode the NaN as 0.
>>>
>> Clipka,
>>
>> Thank you very much for the tip. No wonder the red area in the render
>> was completely noisy.
>>
>> I added the following to the material:
>>
>> #declare pave=pigment{average pigment_map{
>>      [1 p_map1]
>>      [1 color rgb 0.001]
>>    }
>>    }
>
> I would instead suggest
>
>    #declare pave=pigment{average pigment_map{
>       [1 p_map1]
>       [0.001 color rgb 1]
>     }}
>
> as this leaves the resulting color almost unchanged, whereas your
> solution gives any non-black color a significant blackshift.
>
That makes sense. I noticed the darkening but I though I would have to 
live with that. Now I just see that I was averaging black with the 
original. Using the weight makes the render look as expected.

Thanks again,

FlyerX

Post a reply to this message