waggy wrote:
> The only issue I see immediately is with very complicated objects such as those
> based on fractals, noise, or some odd mathematical formula.  Some fractal
> objects, for example, may have an infinite number of intersections along a test
> ray and should, at the very least, increase the calculation time a great deal.
True. I picked the 'orientation' of what direction to shoot the rays as 
somewhat arbitrary. For most objects it should work fine, but I am aware 
specifically that an image-based heightfield (since it normally rises up 
from the x-z plane) will create a large number of intersections, and 
would be more efficient to shoot along y. Considering the likelihood of 
this sort of comparison, I may actually switch it to shooting along y, 
since for 'normal' object it wouldn't make much of a difference.

> I hope you don't mind if I make a companion macro based on your code to
> calculate the CoM and volume using a more naive approach specifically for such
> pathological objects.  If I can get it to work, the approach I'm thinking of
> would be less accurate for a given number of subdivisions, but would always
> finish in n^3 iterations.
I did have in mind a few different ways of shooting rays, specifically 
doing a sort of spherical shoot where theta and phi are the control 
variables, but evenly distributing the rays around the surface (and 
finding the volume of each 'chunk') would be a little more complicated. 
At least this method works in k*n^2, where k is something like the 
number of voids in the object, which is slightly more optimized than n^3 
in the case of most simpler objects (CSG, etc). I thought about trying 
to use an adaptive sampling method, but the extra code would be 
significant (and I don't have a good handle on how to do it yet, so it 
would involve more research too).
It could be helpful to do a sort of basic test if the object is a 
primitive, and then use the appropriate mathematical formula, but the 
amount of time you'd run into that 'in the wild' would be nearly 0.

> Would you mind posting your test scenes, or include some when you post this to
> the object database submission?  It would be helpful for comparison.
#declare BoxObj = box{-1,1}
#declare SphereObj = sphere{0,1}
#declare CSGObj = difference{object{BoxObj} object{SphereObj}}
#declare TorusObj = torus{2,0.2}
#declare Torus2 = union{object{TorusObj} object{TorusObj rotate 90*x 
translate 1*x}}

Run the macro for each, send the calculated values to debug, and compare 
to hand calculations for the exact volume (for the primitives). That's 
basically what I did.

My intended use is with a lot of toruses in a chain, hopefully making it 
possible to apply gravity to the chain and then drape it over arbitrary 
fixed objects. That's why I used this formulation, as I don't anticipate 
using fractal-based surfaces. If you can come up with something that 
would handle *any* object and still be somewhat efficient, that would be 
great!

Thanks for the input!
Chris

Post a reply to this message