IQM Model Format Extension Info
I spread the message around the usual irc servers and boards and talked to people about some of the stuff we had been d
oing. to avoid any further confusion with the IQM model format and our extension (which IS entirely backwards compatible, you just can't use any of the new features such as geometry-sets and hitcontents).
During the development of The Wastes we had encountered severe problems with the IQM exporter so we forked it and fixed
it for our workflow with the help of Spike (who is working on FTE QuakeWorld).
I don't have to get into all of the new features here, but people seemed to be confused about the work we actually did.
Some people have, due to the very simple nature of the IQM format, gotten accustomed to exporters (like the Blender one) inside their modelling tool. They expected a new Blender exporter for the new features, but some of it just is not possible in that environment.
1) Geometry Sets. You can disable bodyparts individually and assign hitcontent IDs to them. I have _NO_ idea how you'd expect the Blender plugin to tell that.
2) Model events. You can now assign frame-by-frame events that trigger functions inside the game-logic. Again, _NO_ idea how one could make a UI that let's you integrate those things.
3) Hitmeshes. Like the geometry sets, I don't know how you'd seperate them from the reference mesh.
In the end, I have no idea how people expect to save these large configurations either. Our new exporter was built in mind with external files (that could be individually updated and maintained via our own script definitions that would NOT regress if something like Blender was to update to a new Python version)
Anyway, a Blender exporter is not going to happen from us. It wasn't good for our workflow and it probably isn't worth anyones time to figure out some sort of UI that could handle all the new stuff and gubbins we added.
Rant over, because of the issues mentioned above I was confronted with a few facts.
1) Calling it IQM, or IQM-EXT will confuse the hell out of people. Yes it's based on IQM, yes it's backwards compatible - but it works differently. The workflow is different. It still accepts the same input files (although we focus on SMD) but engine maintainers will probably not adopt it. It would mean that THEY would have incorporate some features that FTE QuakeWorld has. That's too much effort.
2) People will have a hard time differentiating between the original IQM and our new exporter. Besides I don't feel comfortable associating with IQM because some people might bother the inventor about OUR spec.
So we decided to change the name for the public eye. Me and the others would prefer if you refer to our extended spec as VVM (Vera Visions Model) from now on. We considered a few different names but decided not to dwell on anything too specific.
Other considerations:
1) FTM (Forethought Model - or FTE Model...) Failed because the model format will probably be used by us outside of FTEQW.
2) V3D (Vera 3D or something)
3) VMF (Vera Model Format - Failed because Valve has a material format called that)
There were some others, but those were just plain silly.
Since we designed the spec, we got to keep it. Spike already has too much on his hands, so the future home of the improved model format can be found here:
http://www.vera-visions.com/dev.html
It contains the sources and binaries, as well as documents for everything VVM related.
At this moment, only FTE QuakeWorld supports all of the features. Don't bother LadyHavoc (Darkplaces) about any bugs/problems with our extended features!
Feel free to use the exporter if you finally want to rotate/transform your model files though. :)
- Marco