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.

Post a reply to this message

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

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> On 4-1-2017 14:30, omniverse wrote:
> >
> > I couldn't find any way to prevent the specks by changing media parameters. > >
>
> 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.

Thanks Thomas but Alain had suggested the same and in trying that I found it
only helped a little by removing those intersecting surfaces, yet still remained
a few specks elsewhere; I suppose on edges still in or on the boxes.

For this particular scene the entire box shape, and other shapes not done here,
is required for each of them. I thought the media itself would keep the box
shape, didn't appear so.

The solution is apparently to scale the scene larger, as Clipka suggested. In
this case scale 100 was a sure fix.

Bob

Post a reply to this message

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

/* test boxed pattern media bright specks */


#version 3.7;

camera {
 location -x*4 look_at 0
 up y
 right image_width/image_height*z /* x ????, never understood this */
 //angle 30
}

// try with and without this scene container (camera inside)
//box{-9,9 hollow pigment{rgb 0.1}} // specks much more apparent


#declare Media_Cont = merge {

   #for(It,0,1,1) // create multiple boxes

      box { -1,1
         rotate <30,30,30>*It
         translate -<1,1,1>*It/2+<1,1,1>*It/2
      }
   #end

   hollow on
}
object { Media_Cont
   pigment {
      rgbt 1
   }
   interior {
      media {
         //method 1
         //intervals 30
         //confidence 0.99
         //variance 1/10000
         //ratio 0.5
         //jitter 0.9
         //aa_threshold 0.1
         //aa_level 3
         //samples 33
         emission <0.1,0.1,0.8>
         //absorption 1
         #for(It,0,1,1) // create multiple densities according to the boxes
            density {
               boxed
               density_map {
                  [0 rgb 1] [0.1 rgb 0] [1 rgb 0]
               }
               rotate <30,30,30>*It /* same transforms as for the merged boxes
above */
               translate -<1,1,1>*It/2+<1,1,1>*It/2
            }
         #end
      }
   }
}

Post a reply to this message

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

Am 06.01.2017 um 04:48 schrieb David Buck:

> 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.

Actually it's pretty much the opposite: These media speckles are
essentially a side effect of the very mechanism by which those dark
pixels are avoided.

Post a reply to this message

On 2017-01-05 11:58 PM, clipka wrote:
> Am 06.01.2017 um 04:48 schrieb David Buck:
>
>> 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.
>
> Actually it's pretty much the opposite: These media speckles are
> essentially a side effect of the very mechanism by which those dark
> pixels are avoided.
>

Interesting.  Ray tracing is always more tricky than it first appears.

David

Post a reply to this message

"MichaelJF" <mi-### [at] t-onlinede> wrote:

>
> 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.
>

I ran MichaelJF's code example with one of the latest 64-bit 3.7.1 dev builds
(v3.7.1-alpha.8927145+av352), with and without the enclosing hollow box.

Without the box, I see NO speckles at all, even during an animation with the
camear moving around. *With* the enclosing box, the speckles appear, as noted.
But I tried something else-- eliminating that hollow box, and substituting a
simple thin background box *behind* the scene instead-- just as a large
background object. With that box in the scene, the speckles are still there. But
*without* the box, no speckles. (I actually animated the box to get smaller--
and as the edges of the box 'pass' the individual speckles (from the camera's
view), they disappear one by one.)

From this simple test, it *seems* that the speckles only appear when there is
some kind of background surface behind the scene's media containers. I don't
know if this helps with the problem, but it's interesting.

By the way: In one of the code examples in this post, the camera is like this:

camera {
 location -4*x look_at 0
 up y
 right image_width/image_height*z // z instead of x
}

I assumed this was just another way of expressing 'handed-ness' in POV-Ray; but
the results (compared to *x) are not what I expected; it actually creates a
flipped mirror-image of the scene, left-to-right. (I tried this with a 'text'
object, and the text is 'backwards.') I've never used *z there before, so I
really don't know the reason for this.

But here's the test scene, re-done, to show the speckles problem. Either run a
150-frame animation (clock 0 to 1), or just eliminate the background box, to see
the difference.

-----------
#version 3.7; // or 3.71

camera {
 location -4*x look_at 0
 up y
 right image_width/image_height*z // should be *x
}

// background box
box{<0,-12 + 11.5*clock,-12 + 11.5*clock>,<.1,12 - 11.5*clock,12 -11.5*clock>
    translate 20*x
    texture{pigment{rgb .03} finish{ambient 1 diffuse 0}}}

#declare Media_Cont = merge {
   #for(It,0,1,1) // create multiple boxes
      box { -1,1
         rotate <30,30,30>*It
         translate -<1,1,1>*It/2+<1,1,1>*It/2
      }
   #end

   hollow on
}
object { Media_Cont
   pigment {
      rgbt 1
   }
   interior {
      media {
         emission <0.1,0.1,0.8>
         #for(It,0,1,1) // create multiple densities according to the boxes
            density {
               boxed
               density_map {
                  [0 rgb 1] [0.1 rgb 0] [1 rgb 0]
               }
               rotate <30,30,30>*It // same transforms as for the
               // merged boxes above
               translate -<1,1,1>*It/2+<1,1,1>*It/2
            }
         #end
      }
   }
}

// text objects to show the 'mirror-image' behavior of the
// camera as-is
text {
  ttf "timrom.ttf" "POV-Ray" .01, 0
  texture{pigment {rgb <.4,1,.4>} finish{ambient 1 diffuse 0}}
  rotate 90*x
  translate -1.8*y
  }

text {
  ttf "timrom.ttf" "POV-Ray" .01, 0
  texture{pigment {rgb <1,.4,.4>} finish{ambient 1 diffuse 0}}
  rotate 90*x
  translate -1.8*y
  translate 1.5*z
  }

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "MichaelJF" <mi-### [at] t-onlinede> wrote:
>
> >
> > 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.
> >
>
> I ran MichaelJF's code example with one of the latest 64-bit 3.7.1 dev builds
> (v3.7.1-alpha.8927145+av352), with and without the enclosing hollow box.
>
> Without the box, I see NO speckles at all, even during an animation with the
> camear moving around. *With* the enclosing box, the speckles appear, as noted.
> But I tried something else-- eliminating that hollow box, and substituting a
> simple thin background box *behind* the scene instead-- just as a large
> background object. With that box in the scene, the speckles are still there. But
> *without* the box, no speckles. (I actually animated the box to get smaller--
> and as the edges of the box 'pass' the individual speckles (from the camera's
> view), they disappear one by one.)
>
> From this simple test, it *seems* that the speckles only appear when there is
> some kind of background surface behind the scene's media containers. I don't
> know if this helps with the problem, but it's interesting.
>
> By the way: In one of the code examples in this post, the camera is like this:
>
> camera {
>  location -4*x look_at 0
>  up y
>  right image_width/image_height*z // z instead of x
> }
>
> I assumed this was just another way of expressing 'handed-ness' in POV-Ray; but
> the results (compared to *x) are not what I expected; it actually creates a
> flipped mirror-image of the scene, left-to-right. (I tried this with a 'text'
> object, and the text is 'backwards.') I've never used *z there before, so I
> really don't know the reason for this.
>
> But here's the test scene, re-done, to show the speckles problem. Either run a
> 150-frame animation (clock 0 to 1), or just eliminate the background box, to see
> the difference.
>
> -----------
> #version 3.7; // or 3.71
>
> camera {
>  location -4*x look_at 0
>  up y
>  right image_width/image_height*z // should be *x
> }
>
> // background box
> box{<0,-12 + 11.5*clock,-12 + 11.5*clock>,<.1,12 - 11.5*clock,12 -11.5*clock>
>     translate 20*x
>     texture{pigment{rgb .03} finish{ambient 1 diffuse 0}}}
>
> #declare Media_Cont = merge {
>    #for(It,0,1,1) // create multiple boxes
>       box { -1,1
>          rotate <30,30,30>*It
>          translate -<1,1,1>*It/2+<1,1,1>*It/2
>       }
>    #end
>
>    hollow on
> }
> object { Media_Cont
>    pigment {
>       rgbt 1
>    }
>    interior {
>       media {
>          emission <0.1,0.1,0.8>
>          #for(It,0,1,1) // create multiple densities according to the boxes
>             density {
>                boxed
>                density_map {
>                   [0 rgb 1] [0.1 rgb 0] [1 rgb 0]
>                }
>                rotate <30,30,30>*It // same transforms as for the
>                // merged boxes above
>                translate -<1,1,1>*It/2+<1,1,1>*It/2
>             }
>          #end
>       }
>    }
> }
>
> // text objects to show the 'mirror-image' behavior of the
> // camera as-is
> text {
>   ttf "timrom.ttf" "POV-Ray" .01, 0
>   texture{pigment {rgb <.4,1,.4>} finish{ambient 1 diffuse 0}}
>   rotate 90*x
>   translate -1.8*y
>   }
>
> text {
>   ttf "timrom.ttf" "POV-Ray" .01, 0
>   texture{pigment {rgb <1,.4,.4>} finish{ambient 1 diffuse 0}}
>   rotate 90*x
>   translate -1.8*y
>   translate 1.5*z
>   }

I did a low rez 320X240 animation first time and missed the speckles that way,
however 640X480 shows them then disappear as you described.

That scene "container" box was for the potential purpose of adding a color
pattern later, and just to reduce the chances of infinite rays causing problems
(gee, I was wrong about that!); but I think I was seeing some bright specks when
using background{} instead. That could have been from other shapes (torus,
sphere) and not boxes, I forget now.

Maybe Michael is in a mirror world?  :)
I never thought of z as being anything other than near or far, and up or down.
Hadn't considered it for left or 'right'.

Bob

Post a reply to this message

> "MichaelJF" <mi-### [at] t-onlinede> wrote:
>
>>
>> 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.
>>
>
> I ran MichaelJF's code example with one of the latest 64-bit 3.7.1 dev builds
> (v3.7.1-alpha.8927145+av352), with and without the enclosing hollow box.
>
> Without the box, I see NO speckles at all, even during an animation with the
> camear moving around. *With* the enclosing box, the speckles appear, as noted.
> But I tried something else-- eliminating that hollow box, and substituting a
> simple thin background box *behind* the scene instead-- just as a large
> background object. With that box in the scene, the speckles are still there. But
> *without* the box, no speckles. (I actually animated the box to get smaller--
> and as the edges of the box 'pass' the individual speckles (from the camera's
> view), they disappear one by one.)
>
> From this simple test, it *seems* that the speckles only appear when there is
> some kind of background surface behind the scene's media containers. I don't
> know if this helps with the problem, but it's interesting.
>
> By the way: In one of the code examples in this post, the camera is like this:
>
> camera {
>  location -4*x look_at 0
>  up y
>  right image_width/image_height*z // z instead of x
> }
>
> I assumed this was just another way of expressing 'handed-ness' in POV-Ray; but
> the results (compared to *x) are not what I expected; it actually creates a
> flipped mirror-image of the scene, left-to-right. (I tried this with a 'text'
> object, and the text is 'backwards.') I've never used *z there before, so I
> really don't know the reason for this.
>
> But here's the test scene, re-done, to show the speckles problem. Either run a
> 150-frame animation (clock 0 to 1), or just eliminate the background box, to see
> the difference.
>
> -----------
> #version 3.7; // or 3.71
>
> camera {
>  location -4*x look_at 0
>  up y
>  right image_width/image_height*z // should be *x
> }
>

What really mather is that the right vector to be perpendicular to the 
up vector, and it's relative length. Also, it should be perpendicular to 
the direction vector. Normally, those are right toward x, up toward y 
and direction toward z.
In the sample camera, direction and right are in the SAME direction, and 
it cause some problem.

Post a reply to this message