Quote - Do you have any thoughts on using a series of Vertex and Polygon class instances for Geom data organization, rather than comprehensive lists covering the entire actor geometry?  I plan to test this soon.  My thought is that it might make mapping verts and polys between actors (virtually merging geometries) easier, as well as mapping between normal polys and triangulated polys.  But what I don't know is whether it would actually be worse for memory usage or slower (or more involved) in terms of loop structure.  As far as I can tell, however, that would be moving toward ADP's idea of a more object-oriented structure.  (Or would it?)

This new vector 'type' is essentially a vector/vertex 'class', in that it knows about the format of and has methods for operating on data in that format (3 doubles, which includes vertices, normals, rgb triplets, uvw triplets, weight triplets or whatever else has similar functionality).  My intention is to also develop a tri-poly class that will be somewhat specific to our implementation (it just holds  the triangle vertex indices, but also a reference index to the parent 'polygon' it came from, as well as some other data like a normal and plane equation value).

There are a few other classes / types / extensions that can help as well - for example, my current C++ plugin has a 'PolyHitList' class / structure that consolidates and tracks things like our ixpolys, windex and weights arrays.

With all of the above in place, lots and lots of the current code functionality can be moved over into the .pyd extension (computing normals, plane equations, point-in-triangle tests, the entire linecast_loop(), weight and windex calcs, etc).

Cinema4D Plugins (Home of Riptide, Riptide Pro, Undertow, Morph Mill, KyamaSlide and I/Ogre plugins) Poser products Freelance Modelling, Poser Rigging, UV-mapping work for hire.