10/3/10

Qoob (OpenGL version) final results


















Qoob library for 3d modelling and uncompression of 3d models is compiled in two ways. One includes all the loading and saving etc used for modelling. The other mode is an intro mode. After making a basic test intro with qoob, I discovered speed was a factor and had to rewrite a few routines. This forced me to add a few bytes but not too many. Now finding normals and smoothing are much much faster and models typically load in sub-second time.This is important if we are using 50+ models in an intro - compo rules usually enforce a total run time that includes loading/unpacking.

The final size using crinkler 1.1 with settings :
/CRINKLER /COMPMODE:SLOW  /ORDERTRIES:3000 /UNSAFEIMPORT /REPORT:report.html /TRANSFORM:CALLS
is 2165 bytes.

This includes, selection handling and recording specific polygons used in modelling, 3d maths lib, catmull clarke smoothing with holes, subdivision, insertion and deletion, unpack routine, extrusion, tapering, bulging, rotations, translations and scaling on polygons and model level, making a cage and making rounded holes, basic cube geometry, vertex and face normals.

Models vary in size. The largest I've done so far is around 350 bytes which was a unicorn head. The compression of models is better than I predicted as picking polygons early in modelling is inexpensive as polygon ids fit within one byte and crinkler does a good job with them. Most abstract models come in around 30-70 bytes and most real world ones 100-200. Better than expected.

If you want to play with the qoob modeller (opengl), send me an email on my gmail account chris thornborrow and I'll release it to you. Especially if you are a 3d modeller used to wings3d - I'd like feedback.

6 comments:

  1. Anonymous3/10/10

    Great project, well done, I've been following it from your first post. And Wings3d is the bomb, by the way.

    ReplyDelete
  2. Anonymous4/10/10

    Impressive bestiary for this tiny amount of bytes! ;)
    2165 bytes minus 440 bytes for crinkler, with how many models in your testcase?
    Although, the thing is for a 4k, as you said, you still need some place to move/transform objects/cameras + some nice rendering/postprocess effects... Not sure It will fit with a good synth under the 4k and reach the wow level factor that qoob could deserve...

    ReplyDelete
  3. code4k: right so good questions. The test was a done like this: a= Create a 4k using crinkler that loads one model. b= Remove the line that loads a model. Bytes = a-b. So the result is a single model loaded in - the model can be considered near as dammit zero bytes. Now the load function for an object, any object, in effect loads every function from qoob lib. This is ok design as qoob assumes you will want many many objects, not one - otherwise store a mesh.. So the LIB is 2165 bytes give or take a few bytes.

    So, as you say, for 4k this is hopeless. Maybe a 4k procedural (no synth) but nothing else. However if you read the blog, I've said that from the start. This is not a solution for 4k. 8k, 16k, 64k yes. So now the dilemma - focus on making this a 4k lib or go for bust and make it useable at 64k? I have ideas for both.

    qoob is only a start. I'm enjoying this world of 3d models so much, I'm going further. Watch out for the next project...

    ReplyDelete
  4. I've made qoob its own web pages to save my blog being dominated by it:

    http://qoob.weebly.com/

    ReplyDelete
  5. I've tried it, it's quice nice. It's really a promising tool!
    I might consider using it at some point. :)

    ReplyDelete
  6. jimmi11/1/11

    I mentioned Qoob in my thesis about procedural content generation. Thanks! :)

    ReplyDelete