"clipka" <nomail@nomail> wrote:
> What good would that do? I mean, stuff that trace() and inside() cannot do for
> you yet?

The problem is that you can't do trace() or inside() on an object that has not
yet been placed, but when it has been placed, it is a permanent placement.
Conversely, if you place an object, and then as a result of trace(), decide you
don't want that object to be placed, you can't then remove it. OO would solve
this, in that the object would be referencable after placement, and deleted (or
modified).

Currently, I suppose there's always the option of creating Clear objects, which
trace() would pick up, but they'd slow the final render down. Another
alternative would be to use animation frames, starting with a new frame if an
object needs removing.

Most of my existing 'smart object placement' has used arrays to store existing
object positions, and then subsequent items are placed only where they're
sufficiently distant from all existing objects. Spheres are trivial to place
among other spheres, but once the objects become complicated, or are oriented,
this approach becomes near-impossible.

Some typical examples might be: trees in a forest canopy (or other organic
space-fillers), chains, interlocking toys, sprawling architecture, placement of
objects at rest.

> POV simply cannot really compute overlapping, for reasons of its very basic
> design.

I knew it was difficult, if not impossible on complicated objects (without some
serious mesh work) so I was throwing this hat in the ring to challenge the
existing design. Fair enough, I don't mind it being squashed if it's a no-goer.
I guess that's the nature of brainstorming. :o)

Post a reply to this message