Your Thoughts On A Binary "3D Object" Format


chris_c

Member
Joined
Jun 25, 2010
Messages
393
Age
56
While looking at dismay at the "performance" of sscanf the obvious conclusion dawned on me that (for other reasons too) no finished product should really be parsing text files (namely wavefront OBJ)....

OBJ format is great because almost every 3d editor can output it and it contains all the basic information needed - namely vertices, texture coordinates and vertex normals, and its easy to access and write a parser for.

But its not so great for data density and could contribute significantly to level loading times and in any case coding a parser in c isn't my idea of fun!

In addition I'd like to be able to turn triangle soups into a minimal number of strips with a minimal amount of degeneration
(there are a number of libs that will do this) nvstripify and even part of java3d! so it should be possible to end up with something that you can feed different parameters to either have fewer strips or fewer degenerations for example.

I'd also like this data interleaved to further help out not only the 3d hardware but the cpu, often one read to memory by the gpu can be done rather than three according to the powervr end user guides and anything that can generally help reduce memory bandwidth is welcome.

I'd propose that the obj to bin script would be written in python if only because it could be used as a blender plugin - however being as blender is like marmite it should work stand alone.

I'm happy to both write and release a tool like this and at very least will be initially making an obj to binary interleaved triangles list.

What I'd really appreciate is peoples thoughts on how the final binary ready to render format should be structured. There will need to be for example some kind of header (struct) so we know how may strips they are and what sizes etc

On a slightly different topic I was very pleasantly surprised to learn that the gpu can cope with 2048x2048 :eek: sized textures - thats 64 256x256 textures!!! being that even 256x256 on a small screen is generous I think I'll be using just one texture for all my different objects to completely avoid having to change textures states
 
I think, obj is not a good idea for games because it only supports one uv-set. So, no baked lightmaps or other multitexture-tricks.
Maybe there is another easy format for binary files. Otherwise: Write your own format. Take the blender obj-Exporter(python script) and extend/modify it to your needs.

coding a parser in c isn't my idea of fun!
Reading a plain obj is really easy. I posted useful code here.

level loading times
Obj is not a bottleneck, texture loading should be much slower (just a guess). In my case, the pandora loaded more geometry in 3 seconds than it can render with acceptable framerates.

Just my thoughts.
 
Last edited by a moderator:
obj is not a bottleneck,
you'd think, but my experiments parsing with sscanf have taken noticeable time even small terrains of 4,000 or so vert

I'm not so sure multiple normals are really that useful even for multi texturing... can you give a concrete example of were they are useful even light mapped bsp's don't need multiple sets of normals afaik...
 
chris_c said:
obj is not a bottleneck,
you'd think, but my experiments parsing with sscanf have taken noticeable time even small terrains of 4,000 or so vert
Hmm, I build my terrain by loading a grayscale bitmap and calculate geometry from that. Depends on what exactly you want to do. I think its nice to have that heightmap in Ram so I can do collision tests with it and not with the terrain geometry data blob.

chris_c said:
I'm not so sure multiple normals are really that useful even for multi texturing... can you give a concrete example of were they are useful even light mapped bsp's don't need multiple sets of normals afaik...
Hmm, i did not mean multiple normals but multiple texture coodinate sets. For example one set for the color texture and one set with different tex coords for a prebaked lightmap. I don't know if you use some libraries that compute the lightmaps and the according coordinates on the fly (are there any?) - I thought of doing the lightmaps and all the texturing work in Blender and just use it. My problems atm are: Limitations of the obj-Format, hehe...

btw. I'm looking forward to your results, whatever you are doing ;)
 
Last edited by a moderator:
Back
Top