Using JSON as HL library export

[Roland Melkert]

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:

Yes, as some people think the LDraw format is somewhat old-fashioned I was thinking to introduce a part level HL library which are basically preprocessed cache files.

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.

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. For example it is now like:

Code:

vertex: [px, py, pz, nx, ny, nz, ......],
index: [i, i, i, i, ......],
mesh: [{
color: 16,
kind: 'triangle'.
ofs: 0,
cnt: 12
}]

but we could also do something like:

Code:

pos: [px, py, pz, ......],
nor: [nx, ny, nz, .......],
tex: [tu, tv, .......],
mesh: [{
color: 16,
kind: 'triangle'.
cnt: 12,
posIndex: [i, i, i, i, ......],
norIndex: [i, i, i, i, ......],
texIndex: [i, i, i, i, ......]
}]

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.

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

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 On a side note I find it kinda weird OpenGL is dropping quads all together as there are many (animation) tools relaying on quads.

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.

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.