Hi Roland,
I strongly recommend a single index table. It's what the hardware wants, it's what most 3-d modeler output formats and game engine input formats use, it's simpler, and it's probably a storage win most of the time.
I'm not sure what you mean here - if the data is separate, it needs to be merged for renderers that want a unified mesh; for apps that don't need all of the data, a unified mesh means filtering. But of those two choices, the messier by far is -merging- data sources that have separate index buffers - it basically means re-indexing the mesh, which is the operation I think we want to avoid.
The one "gotcha" I can think of is: if you're going to decompose triangles you need to weight normals for smoothing by the angle of the incident vertex - otherwise the "split" corners of the quad end up getting double weight.
The hardware only does triangles; it's a question of whether to make that the app's problem or not. :-) OpenGL ES went "lower level" than OpenGL and made it the apps problem to lighten the load on the driver and parts of the GPU. Animations tools rely on quads, but there's a huge difference between a "source" format meant for editing, modeling, and high level transformations and a "rendering" format whose destination is GPU hardware. That gap goes well beyond quads. :-)
Right. In the long term we want the amount of non-BFC material to go to zero, so better to pick a file format assumption that is long-term optimal. :-)
cheers
Ben
Roland Melkert Wrote:My test version has indices, what I wondering about is do we have a single index and vertex array or do we split it per type.
I strongly recommend a single index table. It's what the hardware wants, it's what most 3-d modeler output formats and game engine input formats use, it's simpler, and it's probably a storage win most of the time.
Quote:Advantage of the second one will be renderers can construct any buffer they need from that information, but unlike the current format it can't be used 1 on 1 to setup OpenGL buffers.
I'm not sure what you mean here - if the data is separate, it needs to be merged for renderers that want a unified mesh; for apps that don't need all of the data, a unified mesh means filtering. But of those two choices, the messier by far is -merging- data sources that have separate index buffers - it basically means re-indexing the mesh, which is the operation I think we want to avoid.
Quote:It's kinda weird LDCad used to be all triangles but I ran into problems while adding smoothing, problems which were resolved by preserving the LDraw quads
The one "gotcha" I can think of is: if you're going to decompose triangles you need to weight normals for smoothing by the angle of the incident vertex - otherwise the "split" corners of the quad end up getting double weight.
Quote:On a side note I find it kinda weird OpenGL is dropping quads all together as there are many (animation) tools relaying on quads.
The hardware only does triangles; it's a question of whether to make that the app's problem or not. :-) OpenGL ES went "lower level" than OpenGL and made it the apps problem to lighten the load on the driver and parts of the GPU. Animations tools rely on quads, but there's a huge difference between a "source" format meant for editing, modeling, and high level transformations and a "rendering" format whose destination is GPU hardware. That gap goes well beyond quads. :-)
Quote:It's probably best to add a bfc status field and leave the non bfc ones to the shader / render implementation. Non bfc files are loosing ground anyway.
Right. In the long term we want the amount of non-BFC material to go to zero, so better to pick a file format assumption that is long-term optimal. :-)
cheers
Ben