scott <sco### [at] scottcom> wrote:
> > One type of AO from Fragmentarium requires 6
> > samples to be taken from the DE. Because the DE is smooth, it makes for a nice,
> > fast (not quite free) solution (also works with POV isosurfaces), but I wouldn't
> > call it AO. It's a proximity pattern :)
>
> Yes it depends how many rays and how far you want to step. You can also
> re-use the last primary ray DE value before intersection (and the
> initial shadow ray values) as an even cruder approximation.

It all depends on what you want, but personally I don't like the idea. Even if
that sample was added to three others (forming a camera-oriented tetrahedron),
there's still a likelihood that those last DE samples will have been taken at
different relative distances to the surface across the render. Does that make
sense?

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

Post a reply to this message

Am 07.07.2015 um 19:55 schrieb Orchid Win7 v1:

> I wonder if a piece-wise linear curve would be any faster... (Not that
> POV-Ray can do that.)

Not? Well, you'd be surprised...

Even if POV-Ray didn't have its "select()" function, I guess some 
creative use of "abs()" could get you there.

Post a reply to this message

>> I have literally no idea what you're talking about. Are you using a
>> different release version to me or something? I have no problems here.
>
> 3.7 official.
>
> The attached shows artifacts present at various accuracies for the function
> sqrt(x*x+y*y+z*z)-1. max_gradient set to 100 for all spheres, which is more than
> enough.
>
> The first might look acceptable... but just try adding a pattern displacement,
> and it'll become obvious that the accuracy is set too high.

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

Post a reply to this message

> It all depends on what you want, but personally I don't like the idea. Even if
> that sample was added to three others (forming a camera-oriented tetrahedron),
> there's still a likelihood that those last DE samples will have been taken at
> different relative distances to the surface across the render. Does that make
> sense?

Indeed, my personal goal is to rather keep the scene moving at a decent 
frame rate (whilst adding more complexity) rather than towards a more 
realistic render.

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

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

Post a reply to this message

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.

Attached is the same scene, this time with no_shadow applied to the isosurfaces.
Making the light_source shadowless also works.

I vote for a new keyword addressing this issue! Not only are the artifacts ugly,
but I would imagine they also slow down render times when aa is used.

Post a reply to this message

Attachments:
Download 'isospheres-ns.png' (69 KB)

Preview of image 'isospheres-ns.png'

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