For those of you who've gotten wind of my latest folly, the isoblob
primitive, I figured an update is in order.
Yes, it *can* be done. It'll be dog slow when huge numbers of components
interact (careful bounding will be critical), but I think it'll work.
The code is well underway.

The basic concept of the isoblob is to combine the best parts of the
blob and isosurface syntax (isosurfaces are probably best known to
Superpatch users like myself). Instead of blob components, each
component has a specific bounding shape (so far, just a sphere and a
cylinder), and within those bounds is a user-defined density function.
How I'm going to handle functions and parsing yet I don't know. Since
most isoblob shapes will probably use only a handful of functions, and
then transform them into place for each component, it'd be nice to
arrange the syntax as follows:

isoblob {
  function <function1> ...
  [accuracy <accuracy>]
  [max_trace <max_trace>]
  sphere {function <function number>
    <center> <radius>
    strength <strength>
    [transforms]
    }
  cylinder {
    function <function number>
    <end 1> <end 2> <radius>
    strength <strength>
    [transforms]
    }
  [misc. object mods]
  }

So far, the meat of the code is in place. I've adapted isosurface method
1 to (hopefully!) work with the isoblob concept, and most of the methods
for computing normals, field density, etc., are taken care of. Work
remains to be done--next week--on the initialization and destruction of
the different structures, and then on the parsing. That's also where a
bug is likeliest to surface, though, so it's a lot of work to check and
re-check.
Anyone who's looked at the blob and/or isosurface code knows that
altering either one in a meaningful way is a daunting task. Worse, both
primitives are more or less alien to each other in the way they
calculate things. And even worse than that, instead of calculating one
function, it's necessary to calculate several for each little interval.
But, all in all, I think it's coming along nicely.

Why this obsession with isoblobs? Because I want to make trees. The
isoblob will make realistic-looking trees truly possible, albeit not
nearly as fast as a blob would be.
I may yet modify f_func.c and its subsidiary files to allow some
"isoblob space awareness" to the components. (Each component's function
is relative to the component space, not to isoblob space.) I've already
modified those files to include several functions/values like ceil(),
pi, clock, atan2(), and the handy if() (an either-or sort of function),
so what's one more change? (BTW, the function additions are a simple
three-source-file patch if anybody wants it. If you have the latest copy
of the Superpatch source files, these should tack right onto
it--assuming Ron hasn't added them already.)

Lummox JR

Post a reply to this message