+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: General (https://forums.ldraw.org/forum-12.html)
+--- Forum: Official File Specifications/Standards (https://forums.ldraw.org/forum-32.html)
+--- Thread: Using JSON as HL library export (/thread-15870.html)
Using JSON as HL library export - Roland Melkert - 2015-03-15
I've been playing with a simple JSON export in LDCad 1.5 alpha to see if its worth the effort in regards to the introducing a second HL library topic.
It resulted in this extremely light weight welGL renderer. This is far from a full featured LDraw renderer but it demonstrates the ease of doing so when using a new HL LDraw library format.
The JSON structure is readable in the test's javascript source. For now the format only includes polygons (excluding textures).
The test also raised some questions we need to awnser if we ever want to setup some official JSON LDraw format, My main concerns / discussion points I would like to throw into the group are:
How to split the geometry data
In the example I basically dumped the LDCad OpenGL vertex data into a single array (made out of continues pos/nor pairs). Alternative could be to first list all unique positions, normals and tex coords individually and also setup separate index arrays for them per mesh. The enduser software can then construct any kind of buffer they need. Optionally ignoring normals and / or texture coordinates etc.
Webgl (one of the main end users of the format) has no QUAD support, should we therefore drop quads in the fileformat to?
For now I converted the quad indices to triangle indices while keeping them separated. That way you can transform them back when needed.
How to handle non BFC parts
Non bfc parts are handled with dual lighting inside LDCad so these export tests will cause problems for non bfc parts. So how do we handle non bfc parts in the JSON files? Ether by duplicating all data or by setting some flag so the enduser handles it with a different shader or by drawing everything twice (CW and CCW) or something.
Re: Using JSON as HL library export - Ben Supnik - 2015-03-16
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. :-(
Re: Using JSON as HL library export - Roland Melkert - 2015-03-16
Ben Supnik Wrote: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.
Ben Supnik Wrote: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
}]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.
Ben Supnik Wrote: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.Ben Supnik Wrote: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.
Re: Using JSON as HL library export - Ben Supnik - 2015-03-17
Hi Roland,
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
Re: Using JSON as HL library export - Roland Melkert - 2015-03-17
I agree, the one index and unified vertex data is the best option for today. But who says what future hardware is going to need. Although I doubt it going to change anytime soon.
The one thing I admire the most of the LDraw format is its effectiveness in regards of its age, I would like the same for a supplement format.
Although I consider this format a cache I don't mean it to be literally just that. I would like to setup a more more modern container for the original LDraw data. Doing this on the part level seemed to make sense to me in regards of normals etc, not for the pure caching value.
Hope this explains my thoughts better, anyone else interested in such a approach or am I the only one?
Re: Using JSON as HL library export - Rolf Osterthun - 2015-03-17
Roland Melkert Wrote:The one thing I admire the most of the LDraw format is its effectiveness in regards of its age, I would like the same for a supplement format.Progress becomes faster and faster ;-).
Roland Melkert Wrote:Hope this explains my thoughts better, anyone else interested in such a approach or am I the only one?Yes I am interested. But I am really out of time currently...
Rolf
Re: Using JSON as HL library export - Ben Supnik - 2015-03-18
Roland Melkert Wrote:I agree, the one index and unified vertex data is the best option for today. But who says what future hardware is going to need. Although I doubt it going to change anytime soon.
True - but you have two options:
1. Make something that is general purpose but works particularly well for today's hardware - with tomorrow's hardware maybe it is useful or maybe not.
2. Make something that is general purpose but does not work particularly well for today's hardware - with tomorrow's hardware maybe it is useful, maybe it is not. :-)
Lacking any reasonable ability for us to predict what comes after "indexed meshes" you might as well take the win today you can get - the future's a craps-shoot no matter what.
(And for what it's worth, today's indexed meshes work well because they work within the constraints of memory access patterns - those aren't going to change that fast.)
cheers
Ben