(Yesterday, 14:18)N. W. Perry Wrote: This sounds like LDraw 2.0 territory.
Such methods would certainly solve a few issues I've had. Moreover, code for such processes must already exist, as there are tools to do similar things in LDPE and elsewhere.
What would a fallback option look like for this meta?
Fallback I think can be handled in a way similar to the TEXTMAP meta.
About code for such processes already existing - well, it really doesn't and that's why I'm bringing this up. In it's current form, some of the things this enables for either couldn't be done, or have to be done in a very clunky way. Found a pretty good example of a case where this could be helpful without the need to spawn a billion new primitives, or without spamming a billion primitives for a very simple shape - 41665:
As you can see, what is essentially a very simple shape - a half of a ring, because of it's non-typical r/R ratio, the way it has to be done is just unnecessarily complex. Even doing it in a more "sane" way using just 2 primitives and 8 quads, this is still bit more than what it could be
I do think it could be considered outside of the realm of "1.0 LDraw", but offloading kinds of geometry that is best done procedurally, such as rings, cones and toruses to a proper tool, instead of having to either do more of the same in form of small primitives that take more space on a disk than their actual size is (most primitives are under 4KiB) - current design of the primitive infrastructure just feels unnecessarily wasteful. I could be nitpicking at things that don't really matter in the grand scheme of things, but, if things can be made better, why not do them better?