Simple procedural geometry proposal

[Max Murtazin]

So, this is a thing I've thought about for a while. In a lot of cases, the way LDraw handles the geometry is, to put it simply, inefficient for the task it is trying to achieve. Parts that rely on circular geometry, such as covered by edge and disc series of primitives, a lot of the time, have to rely on some sort of, for lack of a better word, hacks to achieve the desired geometry. Probably, most basic case of that would be a disc with a circular cutout (while achievable by both a primitive series of a honestly horrendous size - n-fringr.dat, or, in some cases, by a simple, yet polygonally very inefficient combinations of chrd and ndis primitives), or, a case where a simple trick is incapable of achieving the goal, requiring either a combination, or creation of new primitives (a primitive series of similarly horrendous size that is n-fconr.dat).

Solution to that I want to propose is deceivingly simple - a new meta command, let's for now just call it "draw", as the name is not that important. Use of it would be fairly simple:

Code:

0 !DRAW <method> <generated geometry color> <additional parameters>
0 !: <input geometry information>

First method I'll propose is called "FILL". FILL would take in 2 lines of planar edge geometry, and fill them with a consequent line of quads, adding the required optional lines between them in the process, if the input edges don't lie on the same plane. In that case, if we need to draw a cone with top circle specified by a line with transform matrix <parameters a> and top circle with transform matrix <parameters b>, it would be doable with the following META:

Code:

0 !DRAW FILL 16
0 !: 1 24 <parameters a> 4-4edge.dat
0 !: 1 24 <parameters b> 4-4edge.dat

An obvious input limitation arises of input geometries having to match in amount of lines, and the input lines to be connected having to be in the correct order, but at least as far I can see, the input geometry would likely never have to be anything other than same circular shape before transformation, maybe in some variations of edge/no edge. If that is the case, meta could be simplified to only pass the matrices as the parameters, and geometry could be specified as a unified parameter
Second method I'd like to propose is called "REVOLVE". As the name implies, method's intent is to create a solid of revolution from the input geometries, placing optional lines accordingly. While this one does have a lot of potential, best case for this one my mind could conjure is making a truncated cylinder of an arc that isn't a multiple of 16 without having to compromise by filling the rest of it with a plane that would likely not have the best appearance with primitive substitution enabled. Use case is as following:

Code:

0 !DRAW REVOLVE <generated geometry color> <angle> <revolution axis>
0 !: <input geometry information>

Angle is specified in radians (arc length)
Revolution axis is specified by a set of 2 points - x1 y1 z1 x2 y2 z2
Input geometry information is specified by a line type 1

Most likely, some other methods of generating geometry could also be used, but, as far as I can see, only these two are worth considering, as they cover the most important points of possible improvement, while not being computationally expensive or difficult to implement

[N. W. Perry]

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?

[Max Murtazin]

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?