> You can specify objects and object identifiers in SDL...there are ways to hook
> into the parser so that you can get an "object pointer" when an object
> definition of object identifier shows up in the scene. It may be that it's
> possible given the object pointer to figure out that the top level object is a
> mesh, and get the mesh data. I will definitely be looking into that at some
> point. (My priority at the moment is cleaning up the code and implementing an
> easy way to tweak calls to the minimum distance function easily in SDL).
>
> It is unclear whether that helps with performance of a minimum distance
> function, but one thing it *would* be useful for is testing, to evaluate how
> accurate various methods are. Of course, I can also evaluate that stuff using
> other methods, as well, since I know the mesh definition "offline" already.
>

So today, I verified that you can, indeed, get at the underlying Mesh data if
the object *is a* Mesh. So, in that case, given the Vertex/Triangle data in the
Mesh, along with the transformation matrix (also easy to get), you should be
able to implement a fast and accurate minimum-distance calculation by applying
the inverse of the object's transformation matrix to the test point (to get the
point in the same coordinates as the original mesh data...I THINK???), and then
doing some math.

Unfortunately the math required to do the calculation quickly is not all that
simple...it requires building a KD-Tree from the vertex data, doing some nearest
neighbor calculations, zeroing in on the nearest triangle, then calculating the
nearest point on that triangle.

The most exciting part of this is that I think that it may be possible to create
a fast and accurate minimum-distance function for each shape supported by pov
(with the possible exceptions of isosurface and blob), and then combine them
such that you can also calculate it for objects defined by CSG operations. (i.e.
for an intersection, calculate the minimum distance for each object in the
intersection first, then do a little logic based on whether the nearest point on
one object is inside the other, etc., to figure out which one to keep for the
intersected object). Been doing some drawings on napkins to suss it out.

Anyway...fun stuff.

My *specific* use case is for a simple Mesh object, maybe with some
transformations applied, so probably the next thing I will work on is pulling in
the necessary operations to support that (like a kdtree class, etc.)

Now need to figure out where in the code the classes fit...figuring out where to
put my code is the hardest part...

P.S. Last night/this morning I was dreaming up a plugin architecture that could
possibly allow developers to expose their own C++-backed functionality in
pov-ray without requiring them to actually learn to program pov source.

Post a reply to this message