Le 2022-03-03 à 10:06, Chris R a écrit :
> For some recent modeling work, I have had a need to create various objects based
> on cylinder-based shapes, varying the radius of the cylinder based on the
> y-axis.
> 
> Examples:
> sqrt(x*x+z*z) - Radius // cylinder
> sqrt(x*x+z*z) - Radius*y/Height // inverted cone
> 
> These seem to render as isosurfaces pretty consistently without high
> max_gradients or the need for high accuracy.
> 
> However:
> sqrt(x*x+z*z) - Radius*(pow(y/Height,2)) // quadratic
> or
> sqrt(x*x+z*z) - Radius*sqrt(y/Height)
> 
> is causing the object to look semi-transparent, allowing light to pass through
> it in an almost even distribution.
> 
> In a fit of frustration, after trying very high accuracy and max_gradient
> values, I tried
> 
> sqrt(x*x+z*z) - Radius*sin(0.5*pi*y/Height)
> 
> and the object looks completely solid.
> 
> So, I'm wondering what in the isosurface code could cause this difference?
> 
> -- Chris R.
> 
> 

What do you consider high and very high max_gradient ?
Same for accuracy ?

For sqrt(x*x+z*z) - Radius, the gradient should be barely above 1.

For sqrt(x*x+z*z) - Radius*(pow(y/Height,2)), it tends to infinity 
around Height of zero. You are squaring a value that tent to infinity as 
it approach zero.
Same for Radius*sqrt(y/Height), as y/Height tends toward infinity as 
height get near zero. Taking the square root delays it only slightly.
Both will have at least some parts that go above max_gradient, even of 
you set it to 10000000 or more.

One thing that you can do is to split the object. Pieces for the Height 
values larger than 0.01 and smaller than -0.01, and a slice for the 
-0.01..0.01 range. You may want to not use that slice at all.

You may also hide the problem by using a container sized to not contain 
the problem area. contained_by{ sphere{0,5*Radius scale<1, 1000, 1>} }

Post a reply to this message