Ron Parker wrote:
> Another idea, and one that might be better able to leverage the blob code:
> add an isosurface component to the existing blob syntax.  Then you can use
> the existing blob algorithms when the only components in range are the usual
> spherical and cylindrical ones, and kick it into repeated-subdivision mode
> only when there's a complex component in range, passing the existing
> isosurface code a custom-made function that is the sum of the functions for
> the relevant components.  Ideally, you'd find some way to cache the
> custom-made function for a while in case the same set of components gets hit
> again soon, but that's just an implementation detail.

That's quite true; that could work. Only then there's the problem of
isosurfaces with different bounding shapes, etc. Also, I suspect that
including mixed element syntax could slow things down when only one form
or the other was needed.
For most cases, I think a simple isoblob might make more sense. Any
shape that would use that many functions together would likely be meant
to look rather different from the artificial shape types in a blob;
isoblobs would probably be used only for organic shapes, like trees, or
else for shapes that use toruses and other unsupported blob components.

Lummox JR

Post a reply to this message