"clipka" <nomail@nomail> wrote in message 
news:web.49b92730d4fd5b28f708085d0@news.povray.org...
> As a matter of fact, I'd partially blame it on POV. With a few changes to
> interior design, I guess it should be possible to copy CSG objects, too,
> without copying each and every of its components.

Yup, and those interior design changes would be really nice. I haven't any 
idea how difficult that would be to code, because I've never tried to write 
a raytracer before, but I'm guessing that since no patches fix this, and 
that this has persisted across pov versions...that it ain't so easy. ;-)

> At the moment however, it seems to me that the design of the bounding box
> mechanism prohibits this (requiring a dedicated bounding box per 
> primitive, and
> each box in turn referencing a dedicated primitive object), so changes 
> would
> have to be made there.

Maybe in POV 4 then. :-)

> If I understand you correctly, you'd loop in 3D.

That is what I was thinking.

> 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?

> 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?

> 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)?

> 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.

> 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

> If you want to place a bucketload of identical objects, you may want to 
> use the
> former approach, but shoot the rays at the "unplaced" object and store 
> them in
> an array. When you then try to place a copy, you loop through the array,
> transform the points according to the intended placement, and do the 
> inside
> test for each transformed point. You'd then add the transformed object 
> only if
> you're confident that it doesn't intersect. This spares you both a lot of
> trace() invocations and some unnecessary instantiating of objects that 
> turn out
> to intersect.

A bucket load of objects is to be expected.
Ok, so I perform the spherical trace/intersection test once, then 
reorient_trans() the object, test inside() against object B?

Gah! I hate word problems! ;-D

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!

ian

Post a reply to this message