The game utilizes HAVOK™ physics and uses native Havok *.hkx binary files. Since this file format is a data component aggregation pack, there is no strict rules on it's content parsing. Any addon or extension to the physics that game developers utilize, can create and write it's own specific data into *.hkx file. The file is somehow alike to 3dsMax *.max file that declares component class names and let the runtime to locate respective class to let it read required data from the file. Have you seen any widely used *.max files convertors or any tools that can create *.max files? May be just few, and probably these will be a tightly version-bounded compilations that requires a very specific version of *.max file to load. The *.hkx is about the same, it includes a version mark, so even native data types serialization (like collision volume vertices/faces) might differ from one version to another.
So, what was that above all about? I'm leading you to a notion that *.hkx logically requires it's own plugin for ZModeler3 to be something like "HAVOK binary import/export" plugin. But this plugin will not know what to load and what to expect from each *.hkx file you feed it with. One file comes with a set of collision boxes, another files comes with a hierarchy of bones, ragdoll and animation constrains on it, the third file has no scene at all, but is equipped with animation tracks.
In short: the game physics and collision files are not moddable.
Spotting for solution.
The perfect case would be to have a native HAVOK tool for managing *.hkx files, as these are still a major obstacle on our way to full game modding. However, I haven't found any yet. There could be the case to deal with fragments of *.hkx files, so some known data is extracted, updated, and the file is repacked on export. As this is a pretty comprehensive task, I haven't chosen this as a solution yet. However, we will certainly need something to fight the *.hkx files.
Game physics modding and related tasks.
1 post • Page 1 of 1