Automatic generation of higher resolution meshes
2025-02-09, 15:58 (This post was last modified: 2025-02-09, 16:00 by Christoph Kubisch.)
2025-02-09, 15:58 (This post was last modified: 2025-02-09, 16:00 by 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?
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?