Le_Forgeron <jgr### [at] freefr> wrote:

> > But, the properties of sphere {} and isosurface {} should be the same --- no?

> From the point of view of the code, no.

Yes, the code is always different.  I just wondered _how_ different.


> isosurface defines a "potential", a value for every point of space.

> sphere {} is only a surface that delimit the separation between inside
> and outside. there is no "potential" for every point of space. At best,
> you can know if it is inside or outside.

Mmmmmmmmm..... I will take a look at the source when I have some time to find
it, but I would have to guess that if a sphere is a "mathematical primitive",
then it is based on an equation that defines the surface, and the ray-object
intersection equation uses >, =, and < to determine inside or outside or
right-on.

does the "potential" exist only because of the way the code evaluates an
isosurface, and the "potential" for a sphere, while extant, and mathematically
identical is simply inaccessible due to the specialized structure of the code
for rendering primitives?

> why do I have a feeling of another return of the blob ?
> (blob have sphere & cylinder, and they have nothing in common with the
> code of native sphere and cylinder)

I've never looked at the blob / metaball code or have any knowledge of the
history of its development.  Sounds like a messy story.  ;D


> Can you use macro to combine the various surfaces ?
> With optional argument such as a transformation matrix.
>
> SPHERE( center, radius )
> GLUE()
> SPHERE( center, radius, transform )
>
> or something along ?
>
> And the scary details are handled inside the macro ?


I did some thinking about this post-coffee and pre-heavy lifting.  My thoughts
(for proof of concept) were similar - use a macro to define the various
transformation matrices and then multiply them together, and then define
functions for the final x, y, and z transformations before plugging them into
the function for the shape.
So, your idea to do it in a similar way is encouraging.  :)



And that's fine for making my head hurt, flexing the mental muscles, and playing
around with the idea to illustrate what may be possible...

But really, the end goal would be to have different types of customizable
Boolean operators in the source code.

Then, it would be a simple matter of something like
smoothunion {box{} sphere {} method 1 strength 0.1}

Post a reply to this message