Hi Ken,

"Kenneth" <kdw### [at] gmailcom> wrote:
> It seems that the contained_by
> object-- a sphere for example-- cannot be larger than a radius of 1.0.
> Otherwise, an inverted(?) version  of the torus begins to appear, outside of the
> initial object.

Do keep in mind that f_torus is a continuous function "extending outwards" from
the origin infinitely.  To put it better, f_torus operates on any <x, y, z>
point fed to it, and so you may get values returned that equal the threshold
value that you set, in places where you might not expect them if you're just
thinking about f_torus as an "object", which it's not.

And POV-ray actually crashed several times which is difficult to
> reproduce, depending on... ?

Yeah, that's weird and concerning.
We have many phantoms lurking in the code.

> An isosurface made from  POV-ray's basic torus function itself does not produce
> these anomalies.
>
> (As an experiment, I substituted a different basic function shape for the torus,
> using f_comma instead, just to see if this behavior still occurs. It does.)

So that seems to indicate that the problem lies with the pattern {} wrapper.

> With the torus pattern, an interplay of various values causes the 'outside
> parts' to appear: It depends on the major and minor radii values (and the ratio
> between the two), and *especially* the isosurface contained_by size. And when
> the odd parts begin to come in, the isosurface's required max_gradient wildly
> increases.

In my extensive playing with isosurfaces, I have observed that seemingly
innocent changes can have crippling effects on the gradient and render speed.

I think in some of my explorations, I'm using bad equation results/threshold
values, and that sets up the solver for failure.  The solver has to zig-zag back
and forth along the curve, and how it does that depends greatly on the
user-defined starting point.

IIRC, I recently saw some papers on new methods of solving for roots which don't
suffer from these limitations.

>
> I tried various ways of re-writing my isosurface code block to eliminate the
> 'extra parts', but without success: negating the function; subtracting the
> function from 1.0; negating the threshold value; using 'open';  using v3.8's
> 'polarity' keyword.
>
> Do you have an idea as to what causes this function-to-pattern behavior?
> -----------------
> BTW: For the pattern use, the iso threshold value is a tricky one. It cannot be
> zero (as far as I can tell), but increasing it increases the torus's minor
> radius without affecting the major radius. So it does not seem possible to get
> an exact-size torus that matches the given minor radius.

I would first try comparing the pattern {} method to the color_map method.
Then I would render the functions as a pigment {function}} on a plane, so see
how the values behave outside of the little 1-unit box

Under the hood, (povray/source/vm/fnintern.cpp)

the torus equation is:

DBL f_torus(FPUContext *ctx, DBL *ptr, unsigned int) // 70
{
    PARAM_X = sqrt(PARAM_X * PARAM_X + PARAM_Z * PARAM_Z) - PARAM(0);

    return -PARAM(1) + sqrt(PARAM_X * PARAM_X + PARAM_Y * PARAM_Y);
}

in SDL, you invoke that with f_torus(x, y, z, major, minor)

so your minor radius is baked into your function result _as the surface where
the threshold is zero_

But since it's and ISOsurface, you have different levels - different thresholds
- and therefore different places in space where the surface gets rendered when
you change the threshold value.

If you read Inigo Quilez's articles on making rounded shapes from SDFs, you need
to shrink the shape so that when you set a higher threshold value to expand the
shape and make it rounded, the two things cancel out, and you get a rounded
shape of the desired size.

What happens when you use a threshold of 1 and a BIG box container?
(Use only half the box so that you render a more revealing cross-section)

I don't have my laptop here to test any of this because ... reasons ... so I'm
just speculating as to the underlying factors of what you're seeing, and trying
to give you more of an overhead view, rather than what you're seeing from your
perspective in the middle of the chaos.

If you write a user-defined torus equation from scratch
https://en.wikipedia.org/wiki/Torus#Geometry
and use
function {pattern{function{MyTorus (x, y, z)}}}
do things behave differently?

- BW

Post a reply to this message