

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/POVRay/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 SDLcoded 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 raymarching to "get close to" the result, with the
raytracing being the finetuning 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. ;)
Predefining squareroots 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 POVRay 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 raysurface shape. CSG would perhaps always
> be some isosurface where the raysurface intersections are only giving
> us the collection of shapefunctions 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

