Fileformat for 3D web applications
I just thought it would be great to talk about fileformats for 3D web applications. As you should know, the new FlashPlayer will be able to display and handle a lot more triangles/faces than the current one. At the moment you may be using your 3DS- or Collada-Files; I prefer OBJ.
As a matter of fact, these formats were developed for offline-usage only. Does anyone know a 3D-Format that’s built for web applications? I don’t know anyone.
In our office we’ve got an internet-connection of 16MBit/s – that’s far enough for everything and I don’t have to wait a long time for any content. But at home, I only have 1MBit/s, what’s not that much. In Germany there’re still a lot of people that don’t even have 1MBit/s, no they still have those modems (biip biip) with not more than 56KBit/s. As you can image, it takes a looooong time to download 2 or 3 MB with such a connection.
I downloaded a tree as OBJ-file with about 61K triangles. That’s much you think? Well, for the current available engines it may be much. I want to try this on our own engine noob3D, but the engine does not yet support colored triangles (only textured), so I’ll have to wait til this is supported and I also have to make my parser working asynchronous.
With FP 11 (that one which will hopefully support Molehill), we shall be able to have a lot more triangles in our 3D-Scenes, like Thibault Imbert told us “hundreds of thousands”.
Well, I’m able to handle that much, but how do I load it? My tree, mentioned above, is approx. 8.31MBs as OBJ-File. Let’s consider a Scene with about 250K triangles – how big will that file be? 20MBs perhaps… WITHOUT TEXTURES! Most of the current engines will even crash on parsing a file with about 60K tris.
Is there a solution to reduce that file size? Of course there is! Otherwise I wouldn’t have written this down
About 3 or 4 weeks ago, I developed a fileformat especially designed for web-usage. At the moment it includes meshes, vertices, faces, materials, as well as textures(if you want them to be included).
I did try it with the Tree, but my parser also fails because of timeout and I can’t set it to a higher value than 15 seconds?! But I did the test with a small object of about 230 triangles. That OBJ-file was 22KB, then I converted it to my format N3D and got 7KB out of it. Finally I compressed that file with zlib and got 3KB – that’s a reduction of about 86%!
If I have this Tree now and would convert it to N3D and we predict it’s reduced by 86%, the final N3D-File will be just 8.31MBs * .14(ratio) = 1.16MBs.
That’s not everything. By including the textures into that file, we also save the http-request as well as some additional bytes. To get the textures into N3D, I convert the bitmapData into PNG, using a custom PNGEncoder I hacked together from different sources. My default test-picture was 256KB. Then I saved it using a professional graphics program with save for web-functionality and got 252KB. That’s fine, but there’s more ![]()
I tried converting the BitmapData by using the PNGEncoder provided by adobe (found that class somewhere on google code) and I got about 362KB – w00t? That’s 100KB more than the default image! The reason for this was that the default adobe-encoder didn’t use optimization-algorithms at all. After a short research I found those algorithms on wonderfl, but I wasn’t able to use them all at once, just one by time. That got me to point “do it yourself, daniel”. So I did it myself and combined all those algorithms to be used in one file and got finally a size of: 245KB. That’s less than the professional graphics software gave me
I will provide that class soon to the public community.
Let’s compare the results:
The OBJ+MTL-Files + PNG-Texture were 277KB and 3 http-requests.
N3D is 248KB and one http-request.
I will include support for Bone/Skeleton-animation. Who’s interested in this? ^^

