On 2017-01-05 1:07 PM, MichaelJF wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> On 4-1-2017 14:30, omniverse wrote:
>>> Version 3.7.
>>>
>>> Wondering if this might be a bug in media or something else.
>>>
>>> Posted picture showing two boxes with a boxed pattern for the media.
>>>
>>> http://news.povray.org/web.586ceedd76c376849c5d6c810%40news.povray.org
>>>
>>> The bright specks show conspicuously where the box surfaces intersect, but not
>>> all places. Picture is post-processed to combine them. Test scene given in
>>> message there.
>>>
>>> Another hollow box contains the scene and camera, no media itself, and that
>>> dramatically increases the visibility of the specks. They are there without it
>>> too.
>>>
>>> I couldn't find any way to prevent the specks by changing media parameters. Even
>>> tried version changes to 3.5 and 3.6, but not those actual programs.
>>>
>>>
>>>
>>
>> The result will probably different from what you intent to do, but how
>> about merging the boxes? In your example it is a kind of union{} and
>> there may be the problem. merge{} might be a solution.
>>
>> --
>> Thomas
>
> Despite the fact that omniverse has found a solution by scaling, merging the
> boxes does not suffice. The results I found were annoying. White faces instead
> of white dots. IIRC the issue is very old and is e.g. mentioned in the
> documentation of the makecloud macros by Gilles Tran. Overlapping of containers
> with media seems to cause artifacts since the introduction of media in POV.
>
> My first thought was to have a bigger container and multiple translated
> densities within the media-statement, but the result was annoying too. A close
> container seems to be necessary. I then merged the Containers and put multiple
> densities inside (translated alike the containing boxes). May be more to the
> intent of omniverse - and no scaling needed.
>
> Best regards,
> Michael
>

It may not be related (media was after my time with the product), but in 
the early days of POVRay we'd often get "speckles" on objects.  They 
were usually black pixels.  The problem was floating point precision and 
was corrected by adjusting the epsilon factor to determine how far away 
from one intersection point counts as a separate hit versus the same 
hit. For example, if a ray hits a sphere, and we trace another ray back 
to the light source to determine if we're in a shadow, it's possible 
that the first ray's intersection point was slightly inside the sphere 
and the ray back to the light source hits the same sphere on the way 
out.  This would count as a shadow and would make a dark pixel.

This bug in media feels very much the same to me.  I wouldn't be 
surprised if it's a problem with precision - especially seeing that 
scaling the scene eliminates the problem.

David Buck

Post a reply to this message