William F Pokorny <ano### [at] anonymousorg> wrote:

> 1) Today with isosurfaces we have the contained_by shape. I had the
> thought long ago it would be really helpful to be able to specify any
> standard shape as that container. See github issue:
>
> https://github.com/POV-Ray/povray/issues/228

Well, this leads me to ask several questions which I've brought up before:

How exactly is an isosurface evaluated?
In my SDL-coded emulation, I iterated over a nested x,y,z loop, evaluated the
function for those elements, and if the result was less than a certain
threshold, I plotted a sphere.

I largely get the gist of the "raytracing equation" but I wonder if there isn't
some advantage of using ray-marching to "get close to" the result, with the
ray-tracing being the fine-tuning part.  Perhaps there are things that we do now
that are simply legacy code, which might be better implemented with different
approaches or at least different equations or algorithms.

When I'm coding isosurface equations or pigment pattern functions, first I just
try to get it "right"/working, and then I look a bit at optimizing the sludge
that I've defiled the editor with.  ;)
Pre-defining square-roots so that I only evaluate that one time rather than
eight...
and something that Inigo Quilez and Martijn Steinrucken teach - finding
symmetries in the objects so that you might only have to "evaluate" 1/4 or 1/8
of the shape.  (I admit that I don't quite fully understand how that works in
terms of number of calculations).  Even orientation can help simply the
functions so that the number of terms is drastically reduced.
But I don't have a firm enough grasp on how POV-Ray currently handles all of
that vs ray marching and Signed Distance Functions (SDF's).
I never see anyone talking about gradients - they just go ahead and start piling
equations up and running at an unbelievable 60 FPS.
At which point I can't help but think - we must be doing something wrong.


> 2) .... A wild thought I've been
> carrying around is to implement always an implicit form of the shape
> ..... I think of this as my always has
> isosurface shapes inside the ray-surface shape. CSG would perhaps always
> be some isosurface where the ray-surface intersections are only giving
> us the collection of shape-functions on which to work. But, yeah the
> implementation here not easy...

Having tried to code a full set of isosurface equivalents of a lot of basic
shapes, and manage their orientations and CSG permutations....  no, it quickly
becomes pretty crazy.   But then again, maybe I was just going about it the
wrong way.


> Your idea and/or a mix of those above there is a key component for
> usefulness - some way to fade the isosurface function(s) at the hard
> surface boundaries. Otherwise, we have gradient issues there - unless OK
> with the container shape cutting or clipping the resultant shape.

OK, but I still don't understand the gradient issue.  We have CSG and flat
planes and abrupt discontinuities in shapes all the time that the raytracer
handles just fine.   Why are the raymarching algorithms not struggling with this
gradient thing, whereas we find it to be positively crippling in certain
instances?

Post a reply to this message