Cage opened this issue on Dec 20, 2006 · 1232 posts
Spanki posted Thu, 03 April 2008 at 3:36 PM
New toys...
Update: 04/03/08 (search on: "04/03/08" to see changes)
While it might not have been apparent or stated clearly in previous releases, the lists being returned by the various MeshType methods were pointers (by reference) to the actual lists being tracked (and used) internally by the MeshType class. This was implemented as such for two reasons...
...the potential problem with this is/was that there was no 'Clone()' method for the Python Lists being returned (you'd either have to roll your own or Clone() the entire MeshType). So, while it was consistent in behavior (returning pointer/references for complex data types), it was inconsistent in functionality (not providing a way to easily get 'new' lists to play with).
As of this release - and at least for the time-being - I have changed the MeshType methods to always return fresh copies/clones of the lists that it's working with internally. This also has the side-effect that if you modify the vertex positions, you need to tell the Mesh class about it, so it knows to fetch/generate fresh data the next time it's needed (ie. face normals and vertex normals likely need to be re-computed and distances, positions and intersection locations would also be off). You can accomplish this with the new mesh.VertPositionsChanged() call.
If you actually make structural changes (ie. change which vertex indices are used by Ngons and TriPolys, the winding order used to create them or add/remove any polygons or vertices or tex vertices, etc.) then you need to call mesh.StructureChanged() instead. This one basically invalidates all internal lists, so any data will get re-computed when next needed.
The other new features of this release are an attempt to address the self-collision/correlation issue. For the purpose of discussion, assume we have a flattened spherical mesh (like seat-cushion). And that you wanted to write a script that flattened it out even more, but not so much that one side of it penetrated the other side... in this case (and most other self-collision cases), you need to correlate the vertices of the mesh with the tripolys of the same mesh - typically with tripolys on the other side of the mesh - but not necessarily. This poses a couple different problems for our current/original Correlate() routines...
correlating a mesh with itself would always get 'hits' on the tripolys that the vertices lived in (one of them, more or less randomly, since the intersection would be AT the vertex).
the current routine doesn't bother testing for collisions with any tripolys that face the opposite direction as the faces that use the vertices being tested (you might have to read that a few times for it to make sense :) ).
...so, to address these issues, there are two new Mesh class methods...
CorrelateToSelf()
CorrelateByIndexToSelf()
...see the documentation below for details, but for the record, neither has been tested :) and/so, I'm not even sure that the backface culling (or lack thereof) is working as it should (and, if it does produce the proper hits, what happens to or how to interpret the sign of HitDist, etc. [but I don't think that changes, actually - it should still give the same indication of direction to the intersection, in a positive or negative increment along the tested normal, so the only real difference is that the tripoly it intersects may be back-facing]).
Trial and Error is the order of the day - have fun! :)
Additions:
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.