CShake wrote:

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

It might be a good idea to do that.  It may be worthwhile putting into the usage
notes that the following construction works fine to rotate the object just for
use with this macro.  (I checked it.)

FindObjectCenter(object{BoxObj rotate<1,2,3>})

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

Initially I thought it might be worthwhile to keep track of how many times the
#while(more_sections... loop is iterated for each ray, then give up and use
another method if the number of iterations exceeds 10 or 100 times the number
of divisions.  But I agree, it would probably be better to just post a
different method and let the scene designer choose which one to use.  Yours is
likely to be superior for 99 out of a hundred uses, but it didn't look too
difficult to provide an alternative for that poor slob with the oddball case.

The main reason I considered writing an alternative is that I like to use noise
functions to make rock-shaped isosurface objects.  Although the ones I usually
need are simple bumpy rocks (so I'll end up using your macro), I seem to
remember getting the idea after seeing rather complex asteroid-like or volcanic
ejecta-shaped objects and thought someone may need to be able to determine their
masses for some kind of animation...

I got this alternative version working, and as expected it is much slower and
less accurate than yours for simple shapes (with a given number of x and y
divisions, and a similar number of z divisions for my version).  I'll test it
with more gnarly objects, see if I can find some cases where the alternative
gives better performance, and post the results and the finished code here.

Thanks for providing your test objects.  Since I make so many mistakes, I always
prefer to verify known working cases.  :)

Also, thank you for letting me start with your nice, clean code.  It really
helped to get it working quickly.  (Proper attribution is given in the code
comments, of course.)

~David

Post a reply to this message