Hi Roland,
Assuming your goal here is still to make a "cached" export of the library to (1) simplify rendering/parsing code and (2) improve performance (load time or draw) I would say:
1. _Do_ index your geometry. The renderer might want index buffers or it might not, but it is significantly more expensive to index the geometry than to "flatten" it if indices are not required, and there are a lot of GPUs for which index buffers are a performance win (sometimes a significant one). This is particularly true of LDraw, where we can be vertex bound due to the lack of a LOD scheme.
2. _Do_ decompose quads to triangles - if you are trying to make it easier for renderers; the increased cost in indices for desktop renderers is pretty affordable, but mobile GPUs can't (or don't expose) quads at all (hence WebGL's decision).
3. I don't think there's a clear win for BFC. If a renderer is going to ignore BFC entirely (E.g. do two-sided lighting always, a la LDCad and BrickSmith) then duplicating the geometry is an unnecessary cost that increases vertex count.* At least some kind of tag "this is not BFC" can be stripped out.
On the other hand, if a program is really going to render one-sided (e.g. to try to make translucency look good) then duplicating the data is quite possibly cheaper than the state change of going between a BFC and a two-sided mode. (My intention with BrickSmith is to do data duplication, but I suppose if I find enough data bloat I may have to back off.) If you're indexed, then having the client do the data duplication/flipping makes a hash of your nice pre-computed index buffers. :-(
cheers
Ben
* We can't just dupe the indices - the normals need flipping. :-(
Assuming your goal here is still to make a "cached" export of the library to (1) simplify rendering/parsing code and (2) improve performance (load time or draw) I would say:
1. _Do_ index your geometry. The renderer might want index buffers or it might not, but it is significantly more expensive to index the geometry than to "flatten" it if indices are not required, and there are a lot of GPUs for which index buffers are a performance win (sometimes a significant one). This is particularly true of LDraw, where we can be vertex bound due to the lack of a LOD scheme.
2. _Do_ decompose quads to triangles - if you are trying to make it easier for renderers; the increased cost in indices for desktop renderers is pretty affordable, but mobile GPUs can't (or don't expose) quads at all (hence WebGL's decision).
3. I don't think there's a clear win for BFC. If a renderer is going to ignore BFC entirely (E.g. do two-sided lighting always, a la LDCad and BrickSmith) then duplicating the geometry is an unnecessary cost that increases vertex count.* At least some kind of tag "this is not BFC" can be stripped out.
On the other hand, if a program is really going to render one-sided (e.g. to try to make translucency look good) then duplicating the data is quite possibly cheaper than the state change of going between a BFC and a two-sided mode. (My intention with BrickSmith is to do data duplication, but I suppose if I find enough data bloat I may have to back off.) If you're indexed, then having the client do the data duplication/flipping makes a hash of your nice pre-computed index buffers. :-(
cheers
Ben
* We can't just dupe the indices - the normals need flipping. :-(