I'm working with a hobbyist group (www.niftools.org) trying to develop tools to work with the NIF file format used by many games including Oblivion & Fallout 3. Havok was introduced into the format in Oblivion and other team members figured out most of the data, but MOPPs were still opaque to us until the hk550 release. Thanks to that we were able to generate MOPPified collision that greatly helped in developing custom meshes. One thing we have yet to puzzle out are MOPP trees with multiple materials; in Oblivion, there are about 20-30 Havok material constants defined. My guess is that those constants index into a table somewhere; they control game behavior like sound when struck, particles generated, etc. The trick here is that when only one such material is involved, it's easy to tell where that constant lives in the NIF mesh, but when there are multiple materials involved, there is no obvious list of material IDs corresponding to the sub-meshes, which are obvious. There is a MOPP Data member that clearly corresponds to the MOPP Code in the SDK. I've seen in the docs that the shapes in the collection used to generate the MOPP code can include material indices; is that info also stored in the code or is the shape collection still expected to be available in the data? I can post screens of what has been figured out so far if that might help; I know this explanation is pretty poor.
On another note, is it worthwhile to redo our MOPP C++ code with release 6.0?