On 08/07/2015 06:14 PM, Samuel Benge wrote:
> scott<sco### [at] scottcom>  wrote:
>>> The attached shows artifacts present at various accuracies for the function
>>> sqrt(x*x+y*y+z*z)-1.>
>>
>> Assuming you've got no pattern displacement in any of those images, it
>> looks to me like it's something to do with the shadow ray being started
>> too close to the surface (and hence the tracer immediately thinks the
>> shadow ray has been blocked by the isosurface itself).
>
> I should have guessed that, since I ran into shadow ray problems last summer
> with the raymarching stuff. The shadow ray's origin had to be spaced from the
> initial hit point (by backing it up toward the camera or outward from the
> surface), or else artifacts would appear.

Question: Does the problem go away if you make the spheres bigger? Like, 
say, 10 units across instead of just 1?

As I recall, POV-Ray tends to dislike rendering either very tiny or very 
large objects. Floating-point precision issues and all.

(Most particularly, I believe the minimum distance for a shadow ray to 
travel is a hard-coded constant, which might be too small if the 
isosurface itself is very tiny.)

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >> When thinking about optimising distance field renderers I always get a
> >> feeling that you should be able to do something clever with voronoi
> >> diagrams but I have never worked out what yet...
> >
> > Hmm. Are you talking about breaking up the DE into separate regions, so that no
> > particular region will have too many components (shape operations)? If so, what
> > happens when a shadow or reflection ray needs to travel between regions?
>
> Yes, I'm thinking that with complex scenes I am still always computing
> the distance field for every single object. What I think would speed
> things up is if you could group objects together and create a kind of
> much simpler conservative "group" distance function. I guess a kind of
> n-tree structure where you only need to do a relatively cheap check at
> each level to rule out certain nodes that you don't need to go down and
> evaluate any further. I guess POV does something similar.
>
> You would do this for every distance field evaluation, so it wouldn't
> matter if a ray jumped from one region to another.

Right. I was either working off an incomplete thought from last year, or another
problem altogether :/

> I'm also not sure if such a scheme would actually make much improvement
> on a GPU.

Maybe voronoi diagrams aren't needed. Perhaps a simple 'buckets' system would
suffice, where space is divided into cubic cells, with each cell containing just
a few objects. Of course, any object overlapping cell boundaries will have to be
held in more than one bucket...

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> On 08/07/2015 06:14 PM, Samuel Benge wrote:
> > scott<sco### [at] scottcom>  wrote:
> >>> The attached shows artifacts present at various accuracies for the function
> >>> sqrt(x*x+y*y+z*z)-1.>
> >>
> >> Assuming you've got no pattern displacement in any of those images, it
> >> looks to me like it's something to do with the shadow ray being started
> >> too close to the surface (and hence the tracer immediately thinks the
> >> shadow ray has been blocked by the isosurface itself).
> >
> > I should have guessed that, since I ran into shadow ray problems last summer
> > with the raymarching stuff. The shadow ray's origin had to be spaced from the
> > initial hit point (by backing it up toward the camera or outward from the
> > surface), or else artifacts would appear.
>
> Question: Does the problem go away if you make the spheres bigger? Like,
> say, 10 units across instead of just 1?

I just ran some tests. Scaled the isosurface and zoomed the camera; adjusted the
function radius and scaled the object; multiplied/divided the function to change
the gradient's falloff rate... all at values between .01 and 100. No change. You
end up just needing to adjust the accuracy and max_gradient, but the end result
is always the same.

> As I recall, POV-Ray tends to dislike rendering either very tiny or very
> large objects. Floating-point precision issues and all.

I was hoping that with 64 bit would come a more precise epsilon value, but it
didn't turn out that way :( Was it a misunderstanding on my part, or to keep
POV-Ray rendering the same on different architectures, I wonder?

Post a reply to this message

On 08/07/2015 21:00, Samuel Benge wrote:
> Orchid Win7 v1 <voi### [at] devnull> wrote:
>> On 08/07/2015 06:14 PM, Samuel Benge wrote:
>>> scott<sco### [at] scottcom>  wrote:
>>>>> The attached shows artifacts present at various accuracies for the function
>>>>> sqrt(x*x+y*y+z*z)-1.>
>>>>
>>>> Assuming you've got no pattern displacement in any of those images, it
>>>> looks to me like it's something to do with the shadow ray being started
>>>> too close to the surface (and hence the tracer immediately thinks the
>>>> shadow ray has been blocked by the isosurface itself).
>>>
>>> I should have guessed that, since I ran into shadow ray problems last summer
>>> with the raymarching stuff. The shadow ray's origin had to be spaced from the
>>> initial hit point (by backing it up toward the camera or outward from the
>>> surface), or else artifacts would appear.
>>
>> Question: Does the problem go away if you make the spheres bigger? Like,
>> say, 10 units across instead of just 1?
>
> I just ran some tests. Scaled the isosurface and zoomed the camera; adjusted the
> function radius and scaled the object; multiplied/divided the function to change
> the gradient's falloff rate... all at values between .01 and 100. No change. You
> end up just needing to adjust the accuracy and max_gradient, but the end result
> is always the same.
>
>> As I recall, POV-Ray tends to dislike rendering either very tiny or very
>> large objects. Floating-point precision issues and all.
>
> I was hoping that with 64 bit would come a more precise epsilon value, but it
> didn't turn out that way :( Was it a misunderstanding on my part, or to keep
> POV-Ray rendering the same on different architectures, I wonder?

This is completely off-topic!

If you start the shadow ray a little further out, you'll just get the 
same artifacts but in a slightly different place. With a point light 
casting a hard shadow-line on a curved surface like that it's always 
going to amplify any numerical precision issues, as all the pixels 
around the shadow-line will have very similar shadow ray direction 
(which are very close to tangent to the surface).

A realistic solution is to use a very small area light, to average out 
the area around the shadow-line.

Post a reply to this message

>> I'm also not sure if such a scheme would actually make much improvement
>> on a GPU.
>
> Maybe voronoi diagrams aren't needed. Perhaps a simple 'buckets' system would
> suffice, where space is divided into cubic cells, with each cell containing just
> a few objects. Of course, any object overlapping cell boundaries will have to be
> held in more than one bucket...

I think the tricky part would be deciding which cells an object goes 
into, without either limiting yourself to very simple objects or having 
to manually figure it out.

But assuming you can get around that problem, then yes either into cubic 
cells, or I was initially thinking of non-uniform "groups" that could 
just have bounding spheres. With either method you could go down an 
arbitrary depth depending of cells-within-cells on scene complexity.

Post a reply to this message

On 8-7-2015 22:00, Samuel Benge wrote:
> I was hoping that with 64 bit would come a more precise epsilon value, but it
> didn't turn out that way :( Was it a misunderstanding on my part, or to keep
> POV-Ray rendering the same on different architectures, I wonder?
>

Somehow, and I am no expert, I get the impression that epsilon issues 
have gotten worse with 3.7.

-- 
Thomas

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> On 08/07/2015 21:00, Samuel Benge wrote:
> > Orchid Win7 v1 <voi### [at] devnull> wrote:
> >> On 08/07/2015 06:14 PM, Samuel Benge wrote:
> >>> scott<sco### [at] scottcom>  wrote:
> >>>>> The attached shows artifacts present at various accuracies for the function
> >>>>> sqrt(x*x+y*y+z*z)-1.>
> >>>>
> >>>> Assuming you've got no pattern displacement in any of those images, it
> >>>> looks to me like it's something to do with the shadow ray being started
> >>>> too close to the surface (and hence the tracer immediately thinks the
> >>>> shadow ray has been blocked by the isosurface itself).
> >>>
> >>> I should have guessed that, since I ran into shadow ray problems last summer
> >>> with the raymarching stuff. The shadow ray's origin had to be spaced from the
> >>> initial hit point (by backing it up toward the camera or outward from the
> >>> surface), or else artifacts would appear.
> >>
> >> Question: Does the problem go away if you make the spheres bigger? Like,
> >> say, 10 units across instead of just 1?
> >
> > I just ran some tests. Scaled the isosurface and zoomed the camera; adjusted the
> > function radius and scaled the object; multiplied/divided the function to change
> > the gradient's falloff rate... all at values between .01 and 100. No change. You
> > end up just needing to adjust the accuracy and max_gradient, but the end result
> > is always the same.
> >
> >> As I recall, POV-Ray tends to dislike rendering either very tiny or very
> >> large objects. Floating-point precision issues and all.
> >
> > I was hoping that with 64 bit would come a more precise epsilon value, but it
> > didn't turn out that way :( Was it a misunderstanding on my part, or to keep
> > POV-Ray rendering the same on different architectures, I wonder?
>
> This is completely off-topic!

Doh! It's happens too easily around here ;)

> If you start the shadow ray a little further out, you'll just get the
> same artifacts but in a slightly different place. With a point light
> casting a hard shadow-line on a curved surface like that it's always
> going to amplify any numerical precision issues, as all the pixels
> around the shadow-line will have very similar shadow ray direction
> (which are very close to tangent to the surface).
>
> A realistic solution is to use a very small area light, to average out
> the area around the shadow-line.

Well I was thinking that if it worked with straight raymarchers, it would help
with pov's isosurface as well. Editing/compiling pov's source is something I
intend to do... someday. But if somebody wants to beat me to the punch and come
up with an isosurface shadow ray fix (and maybe convince clipka to add it to
UberPOV), it won't hurt my feelings one bit :)

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >> I'm also not sure if such a scheme would actually make much improvement
> >> on a GPU.
> >
> > Maybe voronoi diagrams aren't needed. Perhaps a simple 'buckets' system would
> > suffice, where space is divided into cubic cells, with each cell containing just
> > a few objects. Of course, any object overlapping cell boundaries will have to be
> > held in more than one bucket...
>
> I think the tricky part would be deciding which cells an object goes
> into, without either limiting yourself to very simple objects or having
> to manually figure it out.
>
> But assuming you can get around that problem, then yes either into cubic
> cells, or I was initially thinking of non-uniform "groups" that could
> just have bounding spheres. With either method you could go down an
> arbitrary depth depending of cells-within-cells on scene complexity.

Sounds feasible, but I wonder if not being able to use multidimensional arrays
in GLSL will be a roadblock.

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> On 8-7-2015 22:00, Samuel Benge wrote:
> > I was hoping that with 64 bit would come a more precise epsilon value, but it
> > didn't turn out that way :( Was it a misunderstanding on my part, or to keep
> > POV-Ray rendering the same on different architectures, I wonder?
> >
>
> Somehow, and I am no expert, I get the impression that epsilon issues
> have gotten worse with 3.7.
>
I haven't noticed. What sorts of problems have been seen?

Post a reply to this message

Am 08.07.2015 um 22:00 schrieb Samuel Benge:

> I was hoping that with 64 bit would come a more precise epsilon value, but it
> didn't turn out that way :( Was it a misunderstanding on my part, or to keep
> POV-Ray rendering the same on different architectures, I wonder?

That's obviously a misunderstanding on your part: "64 bit" isn't about 
floating point values at all. It's /only/ about pointers: The 32-bit 
version of POV-Ray is limited to 3 GB of memory (theoretically 4 GB, but 
the operating system typically reserves 1 GB); with the 64-bit version, 
your system's physical memory is the limit (POV-Ray's performance on 
virtual memory is typically poor at best).

Floating-point values have always been 64 bit in POV-Ray.

Post a reply to this message