(2023-08-05, 20:38)Roland Melkert Wrote: I've always seen the library as data only, so no particular rendering target.
That said, I know first hand about the 'pain' some of these issues cause.
Especially the finding identical vertices issue (LDCad still has problems with that in high detail stickers etc).
But I don't see the format changing any time soon.
Especially as most of your issues need single file solutions instead of the highly recursive approach it uses now.
Your own text proves the raw LDraw data can be processed (in bulk) to convert them to something more suitable for modern render hardware.
In other words instead of reworking the entire library, it seems more practical to 'fork' these preprocessed libraries into a new/additional project.
That said I would be open to formalising meta extensions supplying hints to processing software in order to make some of these issues less ambiguous.
my 2cts.
LDraw wouldn't need to assume any rendering target like how gltf assumes OpenGL. You could inline all the geometry in the .dat files for parts. This would eliminate the need for any commands for winding or inverting. MPD can still be defined recursively as normal. Inlining entire MPD models into a single file would use too much memory and be harder to edit. This wouldn't solve any of the problems with indexing or normals, which is the main issue. I'm not sure how you would make normals and indexing floating point values less ambiguous without defining a reference implementation and testing it on the entire library.