Yes I am aware that I should not directly import the intermediate formats to my engine, but it is a necessary step at the moment so I can learn how it works. I need to be able to parse these intermediate formats if I wish to convert the format to what my engine eventually uses.
I currently parse the ASCII model files directly to my engine. It is slow, but it is a necessary step for the engine at the moment because I know very little about how files like this are stored in the real world, and how graphics theory translates to practical use. I don't know what the best way to make my own format for use directly with the engine will be.
It is a better option for me to first load the models directly from human-readable formats so I can understand everything about them. Once I know exactly what's practical to have in a final format and what needs to be stored, or what's better to calculate in real-time instead, I will settle on a format.
.FBX is useless to me for this because I can't open the file and look at it.
Also, Collada is not working very well either. I can't figure out how to export a cube the way it should be exported.
With the ASCII format, 3DS Max would not generate duplicate vertices for non-smoothed faces. So my engine generates additional vertices for faces that are meant to be not smooth based on the smoothing groups.
Collada does not seem to support smoothing groups. Instead it just duplicates every vertex no matter what -- even if I set the entire object to all be in the same smoothing group. If I turn off the duplication, then the triangle list in the exported file still tries to use indices of vertices that weren't output by the exporter.
For example: this is the output of the collada exporter for a model with a cube with all faces set to the same smoothing group:
<triangles count="12"><input semantic="VERTEX" offset="0" source="#Box001-VERTEX"/><input semantic="NORMAL" offset="1" source="#Box001-Normal0"/><input semantic="TEXCOORD" offset="2" set="0" source="#Box001-UV0"/><p> 1 0 1 0 1 0 3 2 3 0 3 0 2 4 2 3 5 3 7 6 7 6 7 6 4 8 4 7 9 7 4 10 4 5 11 5 5 12 11 4 13 10 0 14 8 5 15 11 0 16 8 1 17 9 7 18 15 5 19 14 1 20 12 7 21 15 1 22 12 3 23 13 6 24 19 7 25 18 3 26 16 6 27 19 3 28 16 2 29 17 4 30 23 6 31 22 2 32 20 4 33 23 2 34 20 0 35 21</p></triangles>
The exporter still thinks there are 6 vertices per side of the cube (36 total) even though the output of the vertex list is just 8 vertices total. This is completely broken.
How do I get around this?
EDIT: I think I interpreted those lines wrong -- I think the offset tag means the that for each triangle three of those integers are part of a single vertex description, so every 3rd integer in that list is a vertex index, and the indices in that list that go higher than the number of vertices must refer to the normals.
But I still don't understand why there are more normals than vertices. If they are all smoothed together, why isn't it just exporting a single normal per vertex? Is it possible to correctly reconstruct the model if I use Collada? How can I know whether or not each triangle needs to have its own three distinct vertices whose normals aren't averaged with those of the surrounding faces?
