+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: General (https://forums.ldraw.org/forum-12.html)
+--- Forum: Official File Specifications/Standards (https://forums.ldraw.org/forum-32.html)
+--- Thread: Simple procedural geometry proposal (/thread-29441.html)
Simple procedural geometry proposal - Max Murtazin - 2026-03-16
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.datAn 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