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.

Post a reply to this message

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

Alain Martel <kua### [at] videotronca> wrote:

> > 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>} }

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 ray-container 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

"Chris R" <car### [at] comcastnet> wrote:
> Alain Martel <kua### [at] videotronca> wrote:
>
> > > 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>} }
>
> 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.

Any chance you can give a sample Radius/Height where the problem happens, and
what the contained_by is? I ran some quick tests and wasn't able to reproduce
what you are seeing (used Radius/Height of 0.5 and a contained_by { box { -1.2,
1.2 } }

Post a reply to this message