I think I understand your mathematical objection.  The book Digital Character
Animation suggests that there are packages that can do this.
Are they based on some other algorithm?  Are they merely based on the union method you
are describing?  Could a version of POV work out this union method "automatically"
using the syntax I proposed?  Is it worthwhile?

Ron Parker wrote:

> This doesn't make any sense when you think about a blob as a mathematical
> construct.  Remember, a blob is just the isosurface of a scalar field gotten
> by adding the strengths due to each blob component at the point in question.
>
> If you're at a point somewhere between two "non-interacting" blob elements,
> how are you supposed to determine which blob elements to consider in the
> calculation and which to not consider?  I can see a way to do it if you had
> disjoint sets of non-interacting blob elements, but you're saying you want
> A to interact with B, and B to interact with C, but you don't want A to
> interact with C.  Well, it doesn't work that way.  If it did, you'd have a
> big problem in the vicinity of B, because there are multiple choices for
> the equation and none of them are "right." (A+B, B+C, or A+B+C?)
>
> When it comes down to it, this is a modeler problem rather than a renderer
> problem.  To model what you want, you just have to do this:
>
> union {
>   blob {
>     (element-collection A)
>     (element-collection B)
>   }
>   blob {
>     (element-collection B)
>     (element-collection C)
>   }
> }
>
> Yes, there's some duplication there.  If you have a lot of duplicated elements,
> I would suggest using a macro until POV allows you to include a blob into
> another blob by reference.
>
> Okay, I hear the whining about the possiblity of a visible seam between the A-B
> blob and the B-C blob already.  Well, what did you expect?  The seam is a direct
> consequence of the multiplicity of solutions near point B.  The only way to get
> rid of that seam is to allow A and C to interact!

Post a reply to this message