Le 30/11/2009 17:05, Jorge Stolfi nous fit lire :
> Since the value of N is the *only* difference between the current blob
> and the proposed one, I do not think that it justifies creating a separate
> primitive. That would be confusing to users, too ("which kind of
> blob is best for my needs?") and would be cosiderably harder to
> maintain and document.  Also, locking the future evolution of the
> two primitives seems a good thing, precisely to reduce user confusion.

Please note: I'm only a user, no real authority.
But looks at the current syntaxes (yes, *es!) of the current blob.
There is the old syntax, and the new one...
I strongly believe that a new clean syntax (single) for that new
'object' would be simpler, both now and later.

A bit like quadric & quartic: similar but different (order is
different). And all might be done with poly (which might be good...
sometimes).

The point I'm still considering: would we mix both kind of blob elements ?
So far, I believe it might be possible, but I'm afraid of consequences:
your modifier would need to be repeated at the element level...

blob {
  sphere { ... order 4 ...}
  sphere { ... order 4 ...}
  sphere { ... order 4 ...}
  cylinder { ... order 4 ... }
  cylinder { ... /* order 2 */ ... }
  /* also, beware of the older blob syntax */
  component ...
  component ... order 4
  threshold ...
  order 2 /* a generic/default order ? ! ? */

}

A bit painful for my taste...
and might be ambiguous with support of component (that's why I first
preferred a new object, easier to be non-ambiguous when you can get ride
of the bogus history)

btw, do you envision of making the order generic (a bit like the
superellipsoid ?)
(I did not look at the blob to see if the mixing is easy or
unrealisting, at the math level of the solver)

Post a reply to this message