POV-Ray : Newsgroups : povray.general : FEATURE REQUEST: meta blobs : Re: FEATURE REQUEST: meta blobs Server Time
14 Nov 2024 21:13:51 EST (-0500)
  Re: FEATURE REQUEST: meta blobs  
From: Ron Parker
Date: 27 Apr 1999 12:08:09
Message: <3725d2d9.0@news.povray.org>
On Tue, 27 Apr 1999 09:34:44 -0400, Greg M. Johnson wrote:
>Where [list_of_subblobs]  is a list of ordinal numbers,  say [1,3,4], where each
>number corresponds to a different area on the big blob to blob with.
>
>Each blob component would have a list of subblobs that it would choose to blob
>with.  For example, the blob components for the right leg would blob with each
>other and the but but not the left leg. The buttock collection or the whole torso
>could be sub-blob #1, the right leg sub-blob #2, the left leg sub-blob #3, etc.

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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.