POV-Ray : Newsgroups : povray.general : isosurface and max_gradient Server Time19 Jul 2024 22:37:35 EDT (-0400)
 isosurface and max_gradient (Message 1 to 10 of 22)
 From: kurtz le pirate Subject: isosurface and max_gradient Date: 4 May 2024 13:13:15 Message: <66366cab@news.povray.org>
Hello.

First of all, there's no torus in this picture !

I spent a lot of time trying to figure out why my isosurface wasn't
Each time I tried, POV told me that the max_gradient found was too low.

I had to set *3e10* for it to be ok.

Ouch!!! What justifies such a gigantic max_gradient?

The function is :
function {
(sq(sqrt(x*x + y*y) - 3) + z*z - 0.4 ) *
(sq(sqrt((x - 4.5)*(x - 4.5) + z*z) - 3) + y*y - 0.4) *
(sq(sqrt((x + 4.5)*(x + 4.5) + z*z) - 3) + y*y - 0.4) *
(sq(sqrt((y + 4.5)*(y + 4.5) + z*z) - 3) + x*x - 0.4) *
(sq(sqrt((y - 4.5)*(y - 4.5) + z*z) - 3) + x*x - 0.4) *
(sq(sqrt(x*x + y*y) - 5) + z*z - 0.4 )
}

--
Kurtz le pirate
Compagnie de la Banquise

Attachments:

Preview of image 'chain.png'

 From: Bald Eagle Subject: Re: isosurface and max_gradient Date: 4 May 2024 15:00:00 Message:
kurtz le pirate <kur### [at] gmailcom> wrote:

> Ouch!!! What justifies such a gigantic max_gradient?

I would would speculate that since you have 6 terms that define 6 separate and
distinct surfaces, that you have a lot of discontinuity in that equation.

And this is why we can't use the object pattern as a function for an isosurface
very well, because it has an "infinite" gradient right where the object stops
and nothing begins.

I'll bet that if you made graphs of the x, y, and z directions you'd see what I
mean.  Do central differences to calculate a slope.

I would also imagine that if you broke that equation up into 6 separate
isosurfaces, they would all behave a lot better.

- BE
 From: William F Pokorny Subject: Re: isosurface and max_gradient Date: 4 May 2024 18:48:36 Message: <6636bb44\$1@news.povray.org>
On 5/4/24 13:13, kurtz le pirate wrote:
> What justifies such a gigantic max_gradient?

Multiplication in an isosurface function tends to be a bad choice(*).

Even with linear functions you have values larger than 1.0 some distance
away from the surface roots. You are multiplying six torus equations and
suppose at a distance a few units away from the cluster they all have a
value of 10. So the equation's values are as high as 10^6 - at distance.

Now think about what happens at each root. The values for one of the six
tori rapidly approaches zero and at zero the entire equation winks to
zero before climbing rapidly again out of the negative value region.
Though the values near the roots will be < 1.0, the change from very
large values to and from the root as the ray travels, will be rapid.

min(
(sq(sqrt(x*x + y*y) - 3) + z*z - 0.4 ),
(sq(sqrt((x - 4.5)*(x - 4.5) + z*z) - 3) + y*y - 0.4),
(sq(sqrt((x + 4.5)*(x + 4.5) + z*z) - 3) + y*y - 0.4),
(sq(sqrt((y + 4.5)*(y + 4.5) + z*z) - 3) + x*x - 0.4),
(sq(sqrt((y - 4.5)*(y - 4.5) + z*z) - 3) + x*x - 0.4),
(sq(sqrt(x*x + y*y) - 5) + z*z - 0.4 )
)

And the gradients will be much lower. Note, however, the value fields
now overlap each other so there will minor-ish discontinuities due this.
It's often the case you can cheat lower than the reported max gradient
when using min() or max(). These sorts of value "discontinuities" are
more like seams (inflections in values) away from the roots - and they
don't matter that much so long as you set the gradient (sampling rate)
high enough to not miss any roots(**) as the solver runs.

(*) - The yuqk fork implemented an f_cbrt() inbuilt function wrapping
C++'s std::cbrt(). This can wrap functions with high gradients in one or
more cube roots which lowers the effective gradient as seen by the
solver. (Sometimes, using multiplication is handy. Yes, I lie all the
time... :-) )

(**) - This why the yuqk fork added the 'report on|off' keyword to the
isosurface{}. The gradient warnings can be turned off for particular
isosurfaces, if the isosurface is otherwise rendering fine with a

Bill P.

Aside: I've been thinking some about the isosurface{} feature of late.
Maybe adding options to return only the containing shape's clipped roots
- it would be the opposite of 'open'(***). Further, perhaps an option to
return only a range of all the roots found. This would let us break
apart the surfaces in a way would allow flexible texturing and offer a
way to gradually see isosurface{}s layer by layer, so to speak.

(***) - Having a complement keyword to 'open', I suppose, could apply to
all shapes supporting 'open' today? It would make texturing clipped
parts in ways completely different than the sides of those shapes much
easier.
 From: kurtz le pirate Subject: Re: isosurface and max_gradient Date: 5 May 2024 06:07:07 Message: <66375a4b\$1@news.povray.org>
On 05/05/2024 00:48, William F Pokorny wrote:
> On 5/4/24 13:13, kurtz le pirate wrote:
>> What justifies such a gigantic max_gradient?
>
> Multiplication in an isosurface function tends to be a bad choice(*).
>
> Even with linear functions you have values larger than 1.0 some distance
> away from the surface roots. You are multiplying six torus equations and
> suppose at a distance a few units away from the cluster they all have a
> value of 10. So the equation's values are as high as 10^6 - at distance.
>
> Now think about what happens at each root. The values for one of the six
> tori rapidly approaches zero and at zero the entire equation winks to
> zero before climbing rapidly again out of the negative value region.
> Though the values near the roots will be < 1.0, the change from very
> large values to and from the root as the ray travels, will be rapid.
>
>
> min(
>    (sq(sqrt(x*x + y*y) - 3) + z*z - 0.4 ),
>    (sq(sqrt((x - 4.5)*(x - 4.5) + z*z) - 3) + y*y - 0.4),
>    (sq(sqrt((x + 4.5)*(x + 4.5) + z*z) - 3) + y*y - 0.4),
>    (sq(sqrt((y + 4.5)*(y + 4.5) + z*z) - 3) + x*x - 0.4),
>    (sq(sqrt((y - 4.5)*(y - 4.5) + z*z) - 3) + x*x - 0.4),
>    (sq(sqrt(x*x + y*y) - 5) + z*z - 0.4 )
> )
>
> And the gradients will be much lower. Note, however, the value fields
> now overlap each other so there will minor-ish discontinuities due this.
> It's often the case you can cheat lower than the reported max gradient
> when using min() or max(). These sorts of value "discontinuities" are
> more like seams (inflections in values) away from the roots - and they
> don't matter that much so long as you set the gradient (sampling rate)
> high enough to not miss any roots(**) as the solver runs.
>
> (*) - The yuqk fork implemented an f_cbrt() inbuilt function wrapping
> C++'s std::cbrt(). This can wrap functions with high gradients in one or
> more cube roots which lowers the effective gradient as seen by the
> solver. (Sometimes, using multiplication is handy. Yes, I lie all the
> time... :-) )
>
> (**) - This why the yuqk fork added the 'report on|off' keyword to the
> isosurface{}. The gradient warnings can be turned off for particular
> isosurfaces, if the isosurface is otherwise rendering fine with a
>
> Bill P.
>
>
> Aside: I've been thinking some about the isosurface{} feature of late.
> Maybe adding options to return only the containing shape's clipped roots
> - it would be the opposite of 'open'(***). Further, perhaps an option to
> return only a range of all the roots found. This would let us break
> apart the surfaces in a way would allow flexible texturing and offer a
> way to gradually see isosurface{}s layer by layer, so to speak.
>
> (***) - Having a complement keyword to 'open', I suppose, could apply to
> all shapes supporting 'open' today? It would make texturing clipped
> parts in ways completely different than the sides of those shapes much
> easier.
>

Your explanation is clear. Well done.

Well, it's true that this kind of equation is rather special and
contains a lot of "empty space".

Multiplying isosurfaces is generally used to make blobs. No need here.
On the other hand, the min() function is the equivalent of union{} and

Without changing the value of max_gradient (3e10) and just by adding the
min() in my function, POV finds say : "The maximum gradient found was
4235539.500, but max_gradient of the isosurface was set to
30000001024.000...".

Thanks
--
Kurtz le pirate
Compagnie de la Banquise
 From: William F Pokorny Subject: Re: isosurface and max_gradient Date: 5 May 2024 14:48:01 Message: <6637d461\$1@news.povray.org>
On 5/5/24 06:07, kurtz le pirate wrote:
> Without changing the value of max_gradient (3e10) and just by adding the
> min() in my function, POV finds say : "The maximum gradient found was
>   4235539.500, but max_gradient of the isosurface was set to
> 30000001024.000...".

Alright. Though, that feels to me like too large a max gradient for the
min() approach! Let me try quickly here.

A truth with isosurface{}s, is that setting higher gradients tends to
find higher gradients. A reason is often rays glancing off, or just
catching, the far edges of shapes.

Another truth is that max gradients seen are not constant with respect
to incoming rays.

---
At 10 (Which for me looks OK. See attached image) I see:

isosurface was set to 10.000. ...

---
At 1e5 (I don't have the patience for more on my little i3) I see:

isosurface was set to 100000.000. ...

I'm unsure what's happening with your version of the scene to see the
much larger max gradient with min(). Maybe your bounding box is much
larger than it need be? I don't know.

I'm attaching my version of the scene. I used yuqk, but I don't think
I've changed anything in the solver which would account for difference

Do you see differences between your scene and mine which might account
for the difference in max gradients? I'm willing to do the digging, if
you'll post your version of the scene. I'd like to understand what I'm
missing.

Bill P.

Attachments:

Preview of image 'tmp.png'

 From: kurtz le pirate Subject: Re: isosurface and max_gradient Date: 6 May 2024 10:27:42 Message: <6638e8de\$1@news.povray.org>
On 05/05/2024 20:48, William F Pokorny wrote:

> I'm attaching my version of the scene. I used yuqk, but I don't think
> I've changed anything in the solver which would account for difference
>
> Do you see differences between your scene and mine which might account
> for the difference in max gradients? I'm willing to do the digging, if
> you'll post your version of the scene. I'd like to understand what I'm
> missing.

Render time about 6 seconds. I don't think you missed a thing.

My scene (attached) is always bad with with delirious values for

- My container is a sphere : contained_by { sphere { <0,0,0>, 9 } }
- Function is inside isosurface {}
- I have no "threshold" and no "accuracy".
- I remove sky_sphere
- I remove finish{}
Nothing really decisive  :(

Lower (normal) value for max_gradient don't render object

Last thing, my version :
Persistence of Vision(tm) Ray Tracer Version
3.8.0-alpha.9945627.unofficial (
Compiler: 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.11.45.5))

Might be buggy ?

--
Kurtz le pirate
Compagnie de la Banquise

Attachments:

 From: Cousin Ricky Subject: Re: isosurface and max_gradient Date: 6 May 2024 11:25:00 Message:
kurtz le pirate <kur### [at] gmailcom> wrote:
> Hello.
>
> First of all, there's no torus in this picture !

Is there a reason you are avoiding f_torus()?
 From: jr Subject: Re: isosurface and max_gradient Date: 6 May 2024 12:00:00 Message:
hi,

kurtz le pirate <kur### [at] gmailcom> wrote:
> ...
> Lower (normal) value for max_gradient don't render object

yes, no object with value '100'.  run with the scene as posted finds a max of
'29882873856'.

> Last thing, my version :
> Persistence of Vision(tm) Ray Tracer Version
> 3.8.0-alpha.9945627.unofficial (
> Compiler: 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.11.45.5))
> Might be buggy ?

I used the 'beta.2' version.

regards, jr.
 From: Bald Eagle Subject: Re: isosurface and max_gradient Date: 6 May 2024 12:20:00 Message:
No mention of the evaluate keyword yet?

https://wiki.povray.org/content/Documentation:Tutorial_Section_4.1#Isosurface_not_rendering_properly.3F

https://wiki.povray.org/content/Reference:Isosurface

- BW
 From: William F Pokorny Subject: Re: isosurface and max_gradient Date: 6 May 2024 14:27:50 Message: <66392126\$1@news.povray.org>
On 5/6/24 10:27, kurtz le pirate wrote:
> Lower (normal) value for max_gradient don't render object
>
> Last thing, my version :
> Persistence of Vision(tm) Ray Tracer Version
> 3.8.0-alpha.9945627.unofficial (
> Compiler: 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.11.45.5))
>
>
> Might be buggy ?

Thank you for the information and scene SDL. I'll let you know what I find.

Bill P.