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
showing. So I added the "max_gradient" parameter. I started with 10.
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

Post a reply to this message

Attachments:
Download 'chain.png' (51 KB)

Preview of image 'chain.png'

kurtz le pirate <kur### [at] gmailcom> wrote:

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

What is a 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

Post a reply to this message

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.

Change your equation to:

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 
gradient lower than the actual max gradient.

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.

Post a reply to this message

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.
> 
> Change your equation to:
> 
> 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 
> gradient lower than the actual max gradient.
> 
> 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
is much better adapted.

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

Post a reply to this message

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:

The maximum gradient found was 13.001, but max_gradient of the 
isosurface was set to 10.000. ...

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

The maximum gradient found was 18.814, but max_gradient of the 
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 
in max gradients seen.

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.

Post a reply to this message

Attachments:
Download 'tmp.png' (42 KB) Download 'tmp.pov.txt' (2 KB)

Preview of image 'tmp.png'

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 
> in max gradients seen.
> 
> 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.


Your scene works perfectly. Same image as in your post.
Render time about 6 seconds. I don't think you missed a thing.


My scene (attached) is always bad with with delirious values for
max_gradient. Differences are :

- 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

Post a reply to this message

Attachments:
Download 'notorus.pov.txt' (3 KB)

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()?

Post a reply to this 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.

Post a reply to this 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

Post a reply to this message

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.

Post a reply to this message