Le_Forgeron <lef### [at] freefr> wrote:
> > Distance Fields are similar to isosurfaces, but the isosurface value is
> > used to store the minimum possible distance to any surface. Then it
> > makes your raymarcher algorithm very simple:
> >
> > do{
> >  point = rayStart + rayDirection * distance
> >  stepSize = EvaluateDistanceField(point)
> >  distance += stepSize
> > }
> > while( stepSize > someVerySmallAmount)
> >
> > The functions and methods are very similar to isosurfaces:
> >
> > http://www.iquilezles.org/www/articles/distfunctions/distfunctions.htm
> >
> > There are also some clever tricks you can do to get soft shadows and
> > ambient occlusion for free.
> >
> ahem...
>
> The described distance fields are exactly povray isosurface :
> first vector (vec p) is the position, and the other optional parameters
> are the formula's specific constants if any. (the threshold parameter of
> povray is a bonus to adjust the surface, but you can keep it at 0 and
> change the formula instead).

So why do POV's isosurfaces render with so many artifacts? Take a simple sphere
function. Should turn out almost flawless, but it doesn't! POV's isosurfaces
look all sliced up, even with an ideal max_gradient. Lower accuracy values only

raymarching code I've used looks a lot better. Why?

Post a reply to this message

>> There are also some clever tricks you can do to get soft shadows and
>> ambient occlusion for free.
>>
> Free ambient occlusion? How free?

Depends how accurate you want your AO :-)

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

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

Post a reply to this message

On 06/07/2015 10:57 PM, Samuel Benge wrote:
> Le_Forgeron<lef### [at] freefr>  wrote:
>> ahem...
>>
>> The described distance fields are exactly povray isosurface :
>
> So why do POV's isosurfaces render with so many artifacts? Take a simple sphere
> function. Should turn out almost flawless, but it doesn't! POV's isosurfaces
> look all sliced up, even with an ideal max_gradient. Lower accuracy values only

> raymarching code I've used looks a lot better. Why?

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.

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> On 06/07/2015 10:57 PM, Samuel Benge wrote:
> > Le_Forgeron<lef### [at] freefr>  wrote:
> >> ahem...
> >>
> >> The described distance fields are exactly povray isosurface :
> >
> > So why do POV's isosurfaces render with so many artifacts? Take a simple sphere
> > function. Should turn out almost flawless, but it doesn't! POV's isosurfaces
> > look all sliced up, even with an ideal max_gradient. Lower accuracy values only

> > raymarching code I've used looks a lot better. Why?
>
> 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.

I'd say that earlier versions simply had a high default accuracy or something,
but I remember getting sharp results along with fewer artifacts. IDK. I brought
it up a long time ago, and for a response I got crickets chirping. Oh well, it
was never enough to keep me from using POV-Ray :)

BTW, about that C++ compiling stuff I was going on about yesterday... I was
*mostly* joking. While I /have/ found myself compiling/recompiling SFML for
hours on end while making modifications to its source, there's no way I could be
replied upon to do such things as an occupation. My abilities in that field
exist within a very narrow range. Not sure what you do exactly, but I'm willing
to bet that if I had your job, I'd be as bald as Yoda due to all the hair
pulling, and much less wise :/

Post a reply to this message

Attachments:
Download 'isospheres.png' (73 KB)

Preview of image 'isospheres.png'

>> This of course is thwarted by functions that are extremely steep at the
>> edges, yet quite shallow near where the solutions are. [*cough*
>> Mandelbrot set *cough*] You end up needing an insanely high
>> max_gradient, yet in the vicinity of the solutions you could actually
>> afford to take much bigger steps.
>
> One thing that helps is to use log log smoothing for the exterior. It helps, but
> it's slow. And I could never find a successful way to multiply or divide a
> fractal's gradient in order to speed things up.

Yeah, simply dividing the function by a constant makes the maximum 
gradient smaller, but also makes all the sample values smaller as well, 
resulting in identical performance. Whereas taking the log (or even log 
log) makes the steep parts less steep, while not affecting the shallow 
parts very much. But, as you say, the log function itself is quite slow. 
I wonder if a piece-wise linear curve would be any faster... (Not that 
POV-Ray can do that.)

Post a reply to this message

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'