Le 06/07/2015 10:47, scott a écrit :
>> No.
>>
>> As you'll recall, you have to specify the max_gradient for a POV-Ray
>> isosurface. That means that if you evaluate the function at a specific
>> point, based on the maximum gradient you can compute a sphere of maximum
>> radius that cannot contain any solutions. And that's how far you move
>> along the ray. (Rather than having a constant step width.)
> 
> 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).

The difference is mainly syntax and the capability to have intermediate
computation within the definition of distance field, whereas for an
isosurface the formula must be provided at once (which might preclude
some optimisations such as factoring the same sub-computation-branch).

Very interesting page, including the nice smin() approaches (in another
page).

We could greatly enhance the documentation of povray's isosurfaces with
such examples/illustration (and providing alternative to the blob-like
smooth transits with translation of the various smin's alternatives)





-- 
Just because nobody complains does not mean all parachutes are perfect.

Post a reply to this message

Am 06.07.2015 um 13:58 schrieb Le_Forgeron:

> 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).
>
> The difference is mainly syntax and the capability to have intermediate
> computation within the definition of distance field, whereas for an
> isosurface the formula must be provided at once (which might preclude
> some optimisations such as factoring the same sub-computation-branch).

Nah; that's just syntax, not an inherent property of either isosurfaces 
or distance fields.

I've never used distance fields, but from the article it is pretty clear 
that indeed the key difference is one additional condition obeyed by 
distance fields:

     |f'(p)|=1

wherever an unambiguous solution for f'(p) exists. Or, to put it in 
other words, the gradient is 1 except for a few unavoidable kinks in the 
field.

This allows for a simpler algorithm, based on the presumption that 
max_gradient is always 1.


Yes, the page does contain functions where this is not the case - but it 
explicitly mentions that they're not true distance field functions 
anymore, and require the algorithm to be adapted accordingly. (And yes, 
the generalization of the algorithm does indeed seem to be the same as 
POV-Ray's isosurfaces.)

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:
> On 7/4/2015 8:29 PM, Samuel Benge wrote:
> > Stephen <mca### [at] aolcom> wrote:
> >> On 7/3/2015 8:32 PM, Samuel Benge wrote:
> >>>>> What is a like button btw?
> >>> A useless sentiment gauge.
> >>>
> >>
> >> I like that. :-)
> >>
> > You forgot something: http://tinyurl.com/nj6cgg5
> >
> > I think that's right...
> >
> >
> So that is where I went wrong.
> This is from a long-ago project.

Cool. Nice sword!

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > No.
> >
> > As you'll recall, you have to specify the max_gradient for a POV-Ray
> > isosurface. That means that if you evaluate the function at a specific
> > point, based on the maximum gradient you can compute a sphere of maximum
> > radius that cannot contain any solutions. And that's how far you move
> > along the ray. (Rather than having a constant step width.)
>
> 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)
>
/That/ is raymarching alright. Orchid's explanation made me wonder if I had been
over-simplifying things for myself ;)

> There are also some clever tricks you can do to get soft shadows and
> ambient occlusion for free.
>
Free ambient occlusion? How free? 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 :)

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> On 04/07/2015 07:43 PM, Samuel Benge wrote:
> > Orchid Win7 v1<voi### [at] devnull>  wrote:
> >> After spending a while Googling this, is appears that "ray marching" is
> >> simply another name for the sphere tracing technique that POV-Ray uses
> >> to render isosurfaces already.
> >
> > Sphere tracing? As a bounding shape for the distance estimate (shape) function,
> > or as the basis for all DEs?
>
> 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.

> > And something is broken with POV-Ray's isosurface. I remember a time when it
> > used to have fewer artifacts.
>
> It depends on the function you're trying to trace, and the configured
> max_gradient.
>
Well, flat-sided objects rendered more quickly and without artifacts once upon a
time (before 2003 or 2004).

> >> If only it wasn't so damned hard to program GPUs. This stuff sounds fun...
> >
> > Not hard but rather easy, if you have a graphics library at hand that supports
> > OpenGL. I use SFML (C++, other bindings might be available), which is geared
> > towards 2D graphics. I just use a simple sprite (quad) and use render textures
> > along with GLSL shaders. (It also helps to get a vector math library, as SFML's
> > transformation class is not good for 3D). Getting something set up is easy, you
> > just need to learn GLSL, which is really a fun language to use.
> >
> > Another good thing about SFML: it's open source, so you can compile it yourself.
> > (I had to do this to add support for 16 and 32 bit textures.)
>
> In my day job, I have trouble just making C++ *compile* and *link*
> successfully, never mind actually run without segfaulting. Kind of
> amazing I had paid for this...

Dude, I'm an amateur, and I can compile & link C++ programs and libs all day
long, no problem. OK, /some/ problems, sometimes :D Are you overthinking the
whole thing? That's usually what causes those sorts of issues for me :/

Post a reply to this message

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