A 3d scene in flash will have several MB to hundred MB (model, texture, skybox, xml, animation, sound….). For a commerical game we need to deal with hundres of scenes, characters and props. We also need to compress, encrypt, bluk loading these file too.

What is the best practice how to store and transfer 3d data?

(1) Embed them all into main swf.
Advantage: Simplest method
Disadvantage: main swf will be large and partly update is impossible

(2) Compress and encrypt each single file using bulk loading
Advantage: Also Simplest method
Disadvantage: Slow transfter and heavy web server loading. Model file like .obj have direct link to .mtl and texture.

(3) Put the whole scene data into one swf
Advantage: Easy manage, good compression for image/video, low web server loading.
Disadvantage: no encryption? Model file like .obj have direct link to .mtl and texture.

(4) Compress and Encryption the whole scene data into one zip
Advantage: Easy manage, have encryption, low web server loading.
Disadvantage: Model file like .obj have direct link to .mtl and texture. Image organization is wroser than method 3.

I know most 2D game use Method 3 but seems there is no support for 3D model (or I am wrong?)
For those who need encryption (like me), I think method 4 will be the best choice. But I still need to deal with .obj Loader (rewrite loader).
Am I right? Any more suggestion on this topic?

Its not just only a question of relying on compression methods or formats, even if of course they play a big role. It’s mainly in the way you build your project. Most dev/designer team use the “classical” way, which is a 3d editor such as Blender or max, make a bad ass model and then try to squeeze all this using smallest available formats. If you hang around game dev forums, you’ll often read that most try keep it under 10 megs with lots of pain. You also will notice that most stage3d projects, even small ones tend to reintroduce the flash famous loading bars.

I’am fan of low kb’s and use to work other ways, mainly combining dynamic generation and exports of dynamics. For geometries and textures.
Just to illustrate my point. Working atm on a project of an extended environment where if we do export the geometry to obj, the resulting file weights almost 70 megs. Not even counting the maps.

The actual size of the project swf with geometry, logic and maps as you can see on the attached pict is just under 1.9 meg, and we haven’t even started the finetuning which should probably get rid of a few hundred kb’s.
The other good point of working this way, is that you have full control of the geometry, which eases the port to mobile devices by simply modifying a few settings in both geometry and texture generation. Even if atm, there are several technical issues on mobiles, (they’ll fade away within the next few months or years), small files will always be better on these machine.

Of course for elements such as animated avatars, complex models etc, best way is to include them using best compression/formats available, such as our own awd format. You always need to find the right balance between timebudget/loading filesize/performance/look and feel

My point of all this is that the format is not the key factor, but the way you plan/think and finally build your project. A good format will only even make it better. Tho you have to realize that working as efficiently as possible when it comes to resources, is a process that will require more time than “regular” process, especially for the first time, because the entire team really needs to work and think this “recycled” way. But from my experience I can say that its very worth it, if you plan to build more 3d projects in the future or if your project is huge.

Thanks Fabrice.

But how you prefer store 3d data?
Zip it or put it into swf file?

Since there is no native ways to deserialize “zip” yet released. You rely on third party AS3 libs such as nochump. So sure if you use formats such as obj collada or any ascci formats you do save a massive amount of data. But you add extra load at init by having lots of tmp objects, marschalling, and of course extra init time.

While having something already small embedded into the swf file or part of the swf code, in the format that away needs, the gain is not only on size but also better on ram footprint and init time.

So my love goes to AS3 and awd2.

Add to this than once we have native LZMA in the player, awd2 is already having this option ready.

Doesn’t the bytearray deflating work to ‘unzip’ data?

http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/utils/ByteArray.html#deflate()

Update: Ah, according to nochump’s page, there is another lib that uses the native array decompress, http://nochump.com/blog/archives/15 links to http://codeazur.com.br/lab/fzip/

Sure embedding AWDs etc can be nice too, but possibly native unzipping also avoids the problems of heavier inits that nochump perhaps gave you?

Any sign of a pre-release version of Prefab, Fabrice?
Just being able to import assets (3DS, obj, etc.) and output to AWD2 would be awesome :O)

cheers!

Let’s just say you have waited way more than you still have to wait

There are a few copies out there already, and will soon ask a few more to test before I do release. Keep an eye on Prefab’s forum on this site.