I created a lite version of qoob with only essential commands for creating abstract objects as a first experiment. An example of the objects can be seen at the end of this article.
Above is a snapshot of a crinkler compression report. Using crinkler to examine abstract qoob objects reveals two things.
1. Objects are typically between 20 and 30 bytes after compression.
2. Suprisingly there are no really small objects (10 bytes or less), even though one of these objects is a simple chamfered cube.
Its safe to assume an average of 22 bytes for abstract objects - it may be possible to hit 20 on average. That would mean at 4k it would be possible to have 10-20 objects. Not bad, but it will be necessary to do better...
Qoob lite is also too large but this is OpenGL and does not use D3DX functions yet.
Two people have asked me this and if two asked, many more are thinking about this. I'll be honest I didn't start this project with that idea in mind so I've given it some thought - like the cat - and concluded its unlikely to be possible (in the same way that teleporting the earth 3 feet to the left is unlikely to be possible).
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!
Well ok it was never buggy - worked as intended but beta testers complained and complained. So, its fixed, undo now undoes as you all expect, one modelling command at a time. Its thoroughly tested too.
Watch out for release of 1.0.2 real soon now which will include this fix.
Thanks to beta testers we have found some ugly bugs in Qoob. I'm working on fixing these before releasing the final version of the library. Most bugs relate to not loading saved objects correctly.
For now use a workaround : do not use the function restart but instead restart the modeller by exitin it completely.