Qoob works not by storing meshes but by storing sequences of commands and data for those commands. Qoob objects are read then an uncompressor loops over the model executing the command by calling a function which corresponds to the command in the qoob library.
OK so its not a matter of mesh compression. I can't save the model as a mesh then use qoob lib to uncompress it. But thats obvious. Can we somehow work with the modeller and commands instead?
Commercial modellers can provide to plugins, and export to file, the list of commands used to create the model. The first problem is the commands in qoob lib are very specific, chosen for and written for size. They do not correspond to the ones in commercial modellers. The commercial modeller has far more commands. So the first issue is restricting the user to only the commands that are the same as qoob commands. Hard. Either we ask the user to remember what can and cant be used or I write a whole plug-in or set of plug-ins that is in effect the whole qoob modeller.
It gets worse. Even when there is a correspondence, in command, the BEHAVIOUR of that command is different. For example smooth. Smooth in qoob is super-light and does not handle smooth on part of the model and only very specific style of holes work and even then not as any commercial modeller would do it. So, again, even if a command looks similar in a commercial tool it is highly unlikely to be the same and models rendered with qoob lib would be different from how they appeared - and they could be VERY different.
Then there is mathematical accuracy. Take Rotate about x axis. You might think it will produce the same in a commercial modeller as qoob but it wont. Qoob is on the fly compressing your rotate input and showing you what it will look like compressed which is different from the commercial modeller. This may not be significant with rotate or translate you may think until you realise the changes accumulate. Scaling really has a big effect.
So with qoob lib as it is, the only way to successfully use it would be to write the whole qoob modeller as a plug-in, not using the commercial modellers functions at all for modelling. It is not a simple matter of writing an exporter therefore. This would save some effort (save dialogues for example) but introduce other (sdk). So it doesnt save me effort but does it help the artist? Perhaps a little as the environment would be more familiar - but lets face it qoob modeller is hardly rocket science and already one modeller has told me that qoob is incredibly easy to learn and use and hes really enjoying it. The user would need to learn qoob modelling anyway.
One option is to start again and attempt to write a library that matches exactly the modelling commands in a commercial modeller. Well I tried to write a library to match exactly photoshop filters and got some of the way but I was working blind to the code and it proved to be much much harder to do it than to write my own simple filters which were good enough. Even if it can be done the code and models WILL be larger than qoob. Smooth alone will probably be 3-4x bigger. So I'm not going to do it but someone might. At 64k this might be acceptable, lets say 10-15k for the lib and models around 500bytes to 1k as a wild guess.
If you are still not convinced - I can send you FULL SOURCES of qoob libs and modeller for you to integrate with your favourite modeller and try. It would be very cool to have a 3ds version of qoob!