Qoob: Tiny 3d modeller and Library
 
Picture
Geexlab is a quick prototyping laboratory tool for 3d graphics. It supports python scripting and now Qoob 1.0.2 ) models. It is free and created by the same person (JeGX) who runs Geeks3d website and Ozone3d. So if you want to try out Qoob without writing C/C++ code, now you can use GeexLab.

Qoob in GeeXLab
Cool demo of Qoob model and Pixellation Shader
http://www.geeks3d.com/geexlab/

Thanks JeGX - great job.

You can follow GeexLab on twitter.
 
 
Picture
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.
Picture
 
 
Picture
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!
 
 
Picture
Ville Krumlinde has added Qoob 1.0.2 support to ZGE: ZGameEditor . ZGE is a rapid development environment for 64K games.This enables users of ZGE to create models with the Qoob modeller, save them as .qob files and then load them into ZGE and create games with them. Already one intro has been produced by JPH Wacheski.
Picture
 
 
To accompany the release of Qoob libs , a new version of the qoob modeller is released : qoob 1.0.2. It is available in the download section. New features including moving the object with the mouse and a better organised menu are included but what makes 1.0.2 better is all known bugs have been removed, including models failing to load, undo not working as expected and
 
 
Qoob download now has libs for creating intros with qoob models. Its now possible to model objects, save them, load them into an intro and display them!

Cod for loading and displaying is supplied in the README along with .h and .obj files needed to make an intro. Compression is left to you but hints are provided in the README.
 
 
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.
 
 
Qoob 2 work has begun, even before version 1 is fully out. Qoob 2 will be aimed directly at 64k and will include new features:
  • handling of models in parts, including ability to smooth parts of the model, not the whole model
  • animation of parts
  • new ways to model and pick
  • better stats and size estimation
  • ability to load .qob files directly
  • much faster functions for higher polygon count handling
  • backward compatible with qoob 1.X
Qoob 2 is expected in Q1 2011. The goal is to add only 500-750 bytes to the qoob lib but introduce much more power including animation whilst making qoob much faster when handling high polygon count models.
 
 
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.