Rethinking LDraw for modern hardware and software

[Jonathan N]

From my own point of view with the little experience of working with LDraw as a software developer I have, I can say that, mostly, I don't see much things in the approach.

On the point about quads - with the way spec allows using them them, not much ambiguity can really arise. 

About normals - mostly, they can be easily calculated using the outlines, using them to either separate (normal outline) or merge normals (condline). One thing tho is really bothering me, and that is how heavily LDraw relies on geometry color for making the printed parts. It really is not a problem for flat parts, or when you are not using any lighting aside the ambient light. But in pretty much all other cases it causes very ugly calculated normals, so, the way parts like minifigure heads are done should be preferably rethinked

In the same bin go, by the way, marbled parts. For them I think the textures can be applied - by defining a META command that uses a black/white texture as a map for where to put the color being mixed in

There are applications that define normals by marking edges as sharp or smooth. It's important to only use a single attribute for smooth vs sharp edges to avoid ambiguities where an edge is both sharp and smooth or unspecified. This still doesn't solve the issue of indexing the vertices.

In order to average face normals across edges, you need to know which faces are adjacent. Comparing vertices currently requires floating point comparisons that may not be exact. This is especially problematic on patterned parts. Calculating normals given the correct adjacency information isn't hard like you mentioned. It becomes difficult when you have neither normals nor vertex adjacency information.

It's possible to use textures as an integer "ID map" and resolve the texture colors in a shader. 32 bits per pixel is more than enough to encode all current and future ldraw colors. This would require writing custom shaders and using the appropriate texture fetch functions to avoid any filtering or unwanted conversions to floating point. If resolution is an issue, the source ID maps could be defined as SVG and rendered to some desired resolution.

Another approach is to use the RGBA color channels as masks or weights for up to 4 defined ldraw colors. More than 4 colors would require additional RGBA mask textures. Separate grayscale mask textures for each color would also work. This assumes the mask values add up to 1.0 for all pixels.

The easiest for applications is for patterned parts to use UV coordinates and RGBA images for the colors. If parts have UV coordinates defined, it's possible to bake vertex colors to a texture. Thankfully, both the ID map and the mask textures can be easily preprocessed by applications to regular RGB textures for easier rendering. Baking vertex colors or calculating UV coordinates at runtime would be non trivial and potentially error prone.