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 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
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 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