Can Mopp Code contain material IDs?

Can Mopp Code contain material IDs?

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?

Thanks,
Steve

2 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Quoting - sacarrow
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?

Thanks,
Steve

Hi Steve:

Sorry for the delay.

We'd like to ask you to repost the question independent of any game-specific mods you may be doing.

We respect that different games have different End-User License Agreements that allow for differing levels of modifications. We expect that you are honoring those in this case, but we'd prefer to answer your questions purely on the technical elements relating to Havok.

I think the gist of what you want is here, but if you can repost in a new/separate thread, it would be greatly appreciated.

Thanks very much,

Jeff

Leave a Comment

Please sign in to add a comment. Not a member? Join today