Automatic generation of higher resolution meshes

[Christoph Kubisch]

Hello,

a bit of a rambling post

curious if other people have attempted to improve the quality of the ldraw meshes through mesh processing.

Several meshes suffer from these:
* non-manifold edges & vertices (triangle edges share more than one neighbor)

* self-intersection
* disjoint surfaces. Sometimes triangles/quads are not sharing the same positions along edges, when they should. Often when triangle segments were stitched together to appear to be curved.
* t-junctions (because there is no proper ngon support)

As the tools back in the day weren't exactly great and hardware was limited by other means, it's understandable that the basic definition of the content today feels a bit dated. One alternative is to "properly" create the models through CAD or subdivision-surfaces as true solids. 

Which some people have done see https://grabcad.com/dk/models 
However that doesn't play nice with the ldraw ecosystem and accessibility. Mecabricks exported parts are not allowed to be redistributed, which also doesn't make them a solution.

It seems the typical approach in some ldraw apps and importers is to detect a few primitives and replace them with higher resolutions (cylinders, discs, etc.). However that may not always work well with adjoint surfaces that share spatial edges, but are not a primitive. Furthermore it doesn't cover other smooth surfaces.

Fixing things up in blender or other 3d tools after something has been converted to 3d meshes, seems like some key information is lost. Furthermore, 3d packages generalized solutions may not be the best fit to address the mesh problems.


My thinking is that one nice thing about ldraw is that it's fairly low-resolution, meaning on todays hardware one can brute force certain things to clean up the meshes. And tessellation algorithms can make use of the "edges" etc. to detect the intent. Some fixes could be done on the .ldr directly, like certain vertices snapped to other positions etc.

Compared to past
* there are robust open-source (no GPL etc.) mesh processing (booleans etc.), polygon triangulation... algorithms out there today
* due to 3d printing in general also more research in mesh cleanup for solids
* rendering hardware is a lot more capable
* much more CPU cores for processing... (and this has to happen only once).


so my question: has this been attempted before? how do others see the future of ldraw's mesh quality for rendering (maybe what I am describing isn't perceived as that desirable)? Is there interest among the programmers of importers/exporters/tools in the ldraw community to go in such a direction?

There seem to have been some threads on "modernizing" the spec and such, but they seem like decades ago, so I guess we can assume things stay as is and so the kind of automated processing is the only realistic option?

[N. W. Perry]

To me, the antiquity of the LDraw spec can actually be a benefit. It makes it more accessible for new users with limited programming experience, like me. It's simple enough to be comprehensible, and the files human-readable, but extensible enough that you can get (perhaps surprisingly) sophisticated results.

At the same time, this means that a core operational principle of LDraw is actually the opposite of what you envision—there is a focus (perhaps excessively so, given modern software capabilities) on minimizing mesh complexity, and relying instead on external processes within the LDraw applications to provide runtime enhancement.

In my view this is a sensible goal, but at the same time a limitation, as it depends on the extended community to provide tools for a "fit and finish" to an LDraw creation. Many of these tools do exist, like primitive substitution, but some gaps remain—both figuratively and literally. (My go-to example is the mis-match between flat quad and triangle geometries on the patterned section of a minifig head, and the adjacent round primitives of the base head part.)

So, I do think there is room for some kind of enhancement to the core spec to allow for a more refined result "out of the box"—i.e., a properly crafted LDraw model will give a satisfactory result, at resolutions common to modern tools, in any complaint software without the need for excessive external processing. At the moment, this is already largely the case, but as I say, there are a few gaps.

This is the kind of thing that I imagine as part of a future "LDraw 2.0" protocol—something that exists alongside and on top of the current core spec, which it should never deprecate or replace, but only enhance. Perhaps there could be new methods to identify flat-plane geometries as representing curved surfaces (like the patterned minifig face), and thus needing to be smoothed. Or perhaps it would be better to encase the whole of of a minifig head in some kind of geometric shell—something that isn't rendered itself, but onto which the component geometries are projected uniformly.

Anyway, the best way forward might be a middle ground between the status quo and a full exploitation of all modern possibilities, but that sounds very much in the LDraw spirit to me!