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