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

Post a reply to this message

On Sat, 04 Jul 2015 14:23:58 -0400, Samuel Benge wrote:

> Jim Henderson <nos### [at] nospamcom> wrote:
>> On Fri, 03 Jul 2015 15:33:27 -0400, Samuel Benge wrote:
>>
>> > Jim Henderson <nos### [at] nospamcom> wrote:
>> >> On Thu, 02 Jul 2015 00:38:36 -0400, Samuel Benge wrote:
>> >>
>> >> > Anyway, that's all for now. I'll be around occasionally, and I
>> >> > might even start posing images again :)
>> >>
>> >> Welcome back - and cool, I always liked your images. :)
>> >>
>> >> Jim
>> >
>> > Likewise, Jim!
>>
>> What few I've done over the years, that is.  Nothing anywhere near as
>> interesting as yours. :)
>>
>> Jim
> 
> But at least you tend to bring your scenes to completion!

Eventually. ;)

Jim



-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

Post a reply to this message

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?

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

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.

You almost end up needing an estimate of the higher derivatives. Or 
perhaps you want a kind of "bounding function" which is simpler than the 
one you actually want to trace, just to estimate where to start tracing 
the slower function... [In the case of the Mandelbrot set, a lower-order 
iteration nicely fulfils that requirement. I wouldn't be surprised if 
that's how the built-in object type works.]

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

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

Post a reply to this message

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.



-- 

Regards
     Stephen

Post a reply to this message

Attachments:
Download 'a02b_12c1_0000.png' (416 KB)

Preview of image 'a02b_12c1_0000.png'

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

Post a reply to this message

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