





 
 




 
 


For some recent modeling work, I have had a need to create various objects based
on cylinderbased shapes, varying the radius of the cylinder based on the
yaxis.
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 semitransparent, 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.
Post a reply to this message


 
 




 
 


Le 20220303 à 10:06, Chris R a écrit :
> For some recent modeling work, I have had a need to create various objects based
> on cylinderbased shapes, varying the radius of the cylinder based on the
> yaxis.
>
> 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 semitransparent, 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


 
 




 
 


Alain Martel <kua### [at] videotronca> wrote:
> > For some recent modeling work, I have had a need to create various objects based
> > on cylinderbased shapes, varying the radius of the cylinder based on the
> > yaxis.
> >
> > 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 semitransparent, 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>} }
Sorry, I should have been clearer in labeling the variables. For any given
object, Radius and Height are fixed values, while x, y, and z vary over the
isosurface boundaries. So, pow(y/Height,2) and sqrt(y/Height) both range
between 0 at y=0 and 1 at y=Height.
 Chris R.
Post a reply to this message


 
 




 
 


"Chris R" <car### [at] comcastnet> wrote:
the problem area. contained_by{ sphere{0,5*Radius scale<1, 1000, 1>} }
>
> Sorry, I should have been clearer in labeling the variables. For any given
> object, Radius and Height are fixed values, while x, y, and z vary over the
> isosurface boundaries. So, pow(y/Height,2) and sqrt(y/Height) both range
> between 0 at y=0 and 1 at y=Height.
I'd say that it's likely a math problem rather than an isosurface problem.
Best bet is to post a sample scene so we can render it and play with the
equations.
Also, what I would do in debugging my own code would be to graph the values of
the terms and the overall expression in a spreadsheet, and see if anything is
revealed.
 Bill
Post a reply to this message


 
 




 
 


On 3/4/22 10:19, Chris R wrote:
> Sorry, I should have been clearer in labeling the variables. For any given
> object, Radius and Height are fixed values, while x, y, and z vary over the
> isosurface boundaries. So, pow(y/Height,2) and sqrt(y/Height) both range
> between 0 at y=0 and 1 at y=Height.
Adding to what others have said.
Especially with contained by box, I'd recommend not putting container
sides on any x,y or z plane at 0.0. There is often a small amount of
noise in the raycontainer intersection result. This means you might
well be getting small negative values internally though you specified a
0.0 container side value. Any negative 'y' values are a problem for the
sqrt() function for example.
I usually try and center my final 'shape' about 0,0,0 such that the
container ends up also centered at 0,0,0. You can also handle the
potential for near zero negative values other ways  ie abs(y).
Bill P.
Post a reply to this message


 
 




 

