"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
> > Here's a way to reduce this to 2D at least:
> >
> > Loop over (or pick random points on) a sphere surface big enough to
> > contain all
> > of your object A. (make sure you get a roughly homogenous distribution,
> > and
> > don't waste too much time near the poles)
>
> Thats still 3d though right?

Yeah, what I meant was that I only have to loop over 2 variables (latitude and
longitude instead of 3 (X, Y and Z).

> > trace() a ray from each point to the object's bounding box center.
>
> Ok, so a macro fills an array once with random positions on a sphere, then
> uses that array in a looped call to trace.
> I thought trace() accepted only a point and an object? It can accept two
> points?

Um... sorry if I confused you. To be precise, I should have written "trace() a
ray from each point in the direction of the center" - whatever direction that
is for the particular point. It's easy to compute that direction from the point
P and the center C as (C-P).


> > If you get an intersection point, test whether it is inside the other
> > object B.
>
> I'm a little fuzzy here...
> Assuming I had you right in my sentence above, what result from that trace
> would go within the #if block that would initiate the call to
> inside(myPoint,objectB)?

You mean how to test whether trace() did find an intersection at all? Pass an
(initialized!) normal vector variable to the macro, and afterwards check
whether it is non-zero (i.e. check for vlength(myNormal) > 0).

> > Repeat until you're confident that you've covered enough of object A's
> > surface.
> >
> > Note that this way you may miss surface areas in hollows; however, if the
> > other
> > object is "convex enough", this should not be a problem. It will be a real
> > issue only if both objects have significant hollows.
>
> It is likely that in real world use hollows are to be expected. I'm trying
> to write this macro suite for use in any scene.

Sure, it's a trade-off between speed and quality. But in situations like your
vine macro, chances are the "entangled" object's walls are much thicker than a
leaf's total size, so this should be a non-issue for most cases, and in any
case better than not testing at all (and faster than an exhaustive test).

> > Another approach - which should be able to cope with arbitrary hollows -
> > would
> > be to actually test whether intersection{A B} contains anything. Note
> > however
> > that this will again create another object. (Mental note for myself: Test
> > whether #undef frees the memory occupied by the assigned object.)
>
> So I would take the sphere position trace data and test that against the
> points in an intersection of every object A (the leaf for instance) with
> object B (column)?
> Oh man...this is starting to sound like people won't be able to use these
> macros unless they have a spare Cray XT4 laying around... O_O

For POV, generating an intersection object isn't really such a big deal. The
only *possible* issue is that it requires memory that *might* not be freed when
no longer needed - I didn't test yet.

After all, behind the scenes, POV just basically creates a CSG container object
with references to the elements, and only performs any calculations on it when
trace() is called (or the object is rendered on the screen). And as it happens,
for CSG intersections POV actually uses an algorithm very similar to the one I
outlined before: It simply computes the itersections of the ray with each
component object, tests which of these are inside all other components, and
ultimately picks the closest of all these.

In a way, POV never really creates the intersection object - it just performs a
smart combination of ray-intersection- and inside-tests for all the primitives
involved.

> Ok, so I perform the spherical trace/intersection test once, then
> reorient_trans() the object, test inside() against object B?

Well, almost but not quite, so let's try get this more precise:

- You perform the spherical trace/intersection test once for object A (the one
you intend to place copies of)
- For each candidate placement...
-- you compute the transform { reorient_trans(...) translate ... } you intend to
use for the placement
-- you inside()-test the respective vtransform() of the points against object B
(the one near to which you intend to place the object A copies)
-- if you find that none of them is inside, you do the actual placement using
the transform {...} of the object to be placed.

> You watch...just as soon as I get all comfortable with SDL v3.7 (or v4) will
> drop and I'll have to relearn everything. lol!

Hopefully that one will be easier then ;)

Post a reply to this message