The idea was to offload as much calculation/actions as we could from game engine to model export/creation suite to gain speed-speed-speed in-game.Per wrote: If you could just document a few of the things you did on WZM, then perhaps that work would not be wasted, and we can get WZM models into the game with just a tiny bit more work.
MINMAX_TSCEN - what does it mean, and what does its values mean in relation to the standard iIMDShape minmax values (ie are they interchangeable)?
MATERIALS - why was this put in the global section instead of under the MESH part? Shouldn't each mesh be able to have its own materials?
TEAMCOLOURS directive, is this needed anymore, when there is a separate TCMASK directive?
Whole MINMAX_TSCEN thingy is straight from iIMDShape min, max and "tight sphere center" values, see _imd_load_points function for actual code. I just moved that code to WMIT. Obviously that kind of stuff would slow down game loading on higher-poly models.
IIRC after a small debate on +s and -s we've decided to use a single material per model. While not flexible as it could be, that's more that good enough for RTS game in my view. And its better to design some separated material manager with simple IDs in every mesh if actually needed. Because of that, TEAMCOLOURS directive was born to give some flexibility - it tells us if actual single mesh actually uses TCMASK texture from current model, saving some useless texture fetches.
Oh.. i guess that would be a problem for net code: connectors are using floating-point values in my version... any chance of using fixed point .xx values for those? Its really annoying to have integers there...
Other important thing is: vertex-level access for PIE models aren't a good thing for VBOs. So i came to simple solution: using axis-aligned bbox as vertex source for construction lines. Maybe that's how SupCom style construction born?