LDraw.org Discussion Forums - Official File Specifications/Standards

Proposed change to !CATEGORY

Fri, 03 Apr 2026 16:03:51 +0000

What are the thoughts on abandoning the first word convention for !CATEGORY and have every part have an explicit !CATEGORY statement?

Simple procedural geometry proposal

Mon, 16 Mar 2026 09:50:01 +0000

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   

0 !:

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 and top circle with transform matrix , it would be doable with the following META:

Code:
!DRAW FILL 16

!: 1 24  4-4edge.dat

!: 1 24  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   

0 !:

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

Complex Figures (Duplo/Technic/Fabuland)

Sun, 01 Feb 2026 00:20:47 +0000

I came across this while trying to look for colour errors in the Fabuland Figures.

How shall complex figures be handled in the library?
Note that this is not something exclusive to a much older age, since the Duplo figures are still current. Also I am aware that many examples have not yet been done (and are unlikely to appear soon), but we do have examples already.

To explain what I mean with "complex figure", here's a (probably incomplete) list:
-in general, not meant to be disassembled; more than 5 (?) subparts
-Fabuland figures (1979-1989; including those 1986 Basic odd ones)
-Technic figures (1986-2000)
-Duplo Figures (2004-now)
-Duplo Figures (1983-2003)
-Belville, Scala etc.

Technically, these are "assemblies" yet not "true shortcuts", since they come as one single piece outside a sealed box.

A few issues here:

File Number - usually this should be the Element Number, but not all of the older ones are known. The xxc0y format likely shouldnt apply here
Base Colour - which to pick? This is often not that easy to determine, since some have every part coloured differently and an "official" version is not known
Assemblies not always the same - Duplo hats/Fabuland heads - should these get the same "Shortcut Link", so you see all Duplo figures listed there?
Some Fabuland figures are currently listed as "Physical Colour Shortcut" which feels wrong
A few issues with the Duplo figures seem present as well

Any thoughts on this?

Holographic Materials

Mon, 19 Jan 2026 21:50:16 +0000

There are some stickers, cloths and possibly other things, that have an holographic effect.
One such example would be the invisibility cloak from Harry Potter. How are these cases handled currently?

Discussion - proposal to extend !TEXMAP specification

Mon, 19 Jan 2026 19:08:53 +0000

I'd like to formally invite discussion on the idea outlined below, some background conversation on which can be found here:
https://forums.ldraw.org/thread-29160-po...l#pid59106
https://forums.ldraw.org/thread-29246.html

The summary here brings together many of the issues already considered, in the hope that it can lead us to the next steps forward.

Abstract

This is a proposal to extend the current !TEXMAP specification to include LDRAW and SVG formats, along with the existing support for PNG.

Background

The !TEXMAP language extension allows LDraw tools to map a bitmap image, in .png format, onto a part surface or other LDraw geometry as a texture. The !TEXMAP meta-statement specifies the scope of the texture application, as well as a projection method and its associated parameters, and a source .png file.

The associated !: meta-statement provides, in LDraw code, the geometry on which the texture is to be applied. This can be followed by an optional FALLBACK statement, providing the geometry to be used by LDraw tools that do not recognize the !TEXMAP language extension. (Those that do will ignore this geometry.)

The source .png file can be located in the textures/ folder (or elsewhere) within the active LDraw directory tree, or it can be embedded as base64-encoded binary data within a multi-part LDraw document, using the !DATA language extension.

!TEXMAP is most often used to apply a pattern (representing a printed image on real-world parts) to an LDraw part (or sticker). It is intended as an alternative to the traditional method of creating patterns, in which standard LDraw geometry (triangles, quads, lines, primitives, etc.) is used to draw the pattern and assign its colors. !TEXMAP is considered appropriate when the pattern is highly detailed or intricate, has a photographic quality, or is otherwise unsuitable for the traditional method, which is otherwise generally preferred.

As a result, while easier to implement, the !TEXMAP method is often discouraged by parts authors and reviewers, and as a result is found only in a relatively small number of official library parts.

Proposal

The proposed extension to the !TEXMAP specification would add support for vector-based geometry formats, by allowing patterns in LDRAW and SVG format, as well as bitmap images via PNG, to be mapped onto LDraw geometry. This would involve a minimal change to the existing specification, by enabling or as alternatives to the current argument (and by inserting any restrictions or requirements for LDraw or .svg files). Theoretically, the specification could be left open to the addition of possible future formats that may one day be supported.

Implementation, as always, is left to the developers of LDraw tools. Presumably, LDraw geometry would be prepared for rendering as usual, but before being finalized (and after applying any applicable primitive substitution), the rendered data would first be mapped onto the target geometry according to the selected projection method. SVG data could likewise be rendered and mapped, by use of various SVG-to-LDRAW conversion utilities that may from time to time be in development.

A related extension may be necessary to the !DATA specification, to allow embedding of SVG code into a multi-part document. Because SVG code is human-readable and not binary data, a new !CODE meta-statement could be created to allow this kind of data to be embedded. (LDraw code can, of course, already be embedded by using the FILE meta-statement, but the !CODE meta might also allow the insertion of LDraw code as a snippet, thus not requiring full headers and other LDraw file requirements.)

Rationale

The traditional method of creating patterns already involves using LDraw geometry. However, the ability to map LDraw code onto an existing surface using !TEXMAP would have several advantages:

It would greatly simplify the authoring process for patterns appearing on non-planar surfaces, especially in parts with complex or highly organic forms (such as animals) since the pattern geometry would only need to be created in a 2D version.
It would allow the projection of LDraw geometry onto curved surfaces without interrupting the visual appearance of these curvatures (the so-called "crumpled paper" effect).
- This could also have applications in situations involving non-patterned geometry, such as when curved primitives are juxtaposed with non-primitive geometry that represents a curved surface (but where applicable primitives don't exist), resulting in visible seams or undesirable flat spots (for example, the lower edges of 3941.dat).
It would encourage more participation by parts authors by enabling the more user-friendly, less labor-intensive !TEXMAP process to be used, without the perceived disadvantages of .png textures (see referenced discussion above).
It would allow for a pattern to be mapped onto any base part, rather than needing to create a separate library part for each patterned version. Library entries for patterned parts could consist simply of an LDraw code snippet and an associated !TEXMAP statement, referenced to an existing base part in the library.
Besides the geometry, it could also allow for other LDraw information, such as color, to be mapped. This could permit the creation of different-colored versions of a single pattern file, by using either inherited colors or direct color replacement.

The proposal also includes SVG support, which offers these additional advantages:

SVG format is fully scalable, allowing for essentially unlimited resolution of pattern images, whereas LDraw vector geometry is necessarily limited in resolution (even allowing for techniques such as primitive substitution). In theory, with support for SVG combined with texture mapping projection methods, the SVG format could conceivably supplant the need for LDraw-coded pattern geometry altogether.
Vectorization of bitmap images is already a process step for many authors of LDraw patterns, with FOSS tools for SVG, such as Inkscape, readily available. Direct application of SVG graphics to an LDraw part would thus save many additional process steps.
- A similar case exists with img4dat, for conversion of bitmap images directly to LDraw code.
There are already multiple tools, at varying levels of development, for converting SVG to LDRAW format (the most complete probably being Lasse Deleuran's svg2ldraw), which could presumably be incorporated into LDraw editors without starting from scratch.

Potential Issues / Questions

Generating stickers: One potential enhancement to this system would be to project the texture so that it stands 0.25 LDU proud of the target geometry. A process would then be applied to generate the remaining geometry necessary to complete a sticker back, thus obviating the need to create individual sticker parts (and thus simplifying library entries, similar to direct-patterned parts as outlined above).
- Inclusion of this functionality is ideal, as it would complete the simplification of the authoring process for all patterns, whether as printed parts or stickers. However, it adds considerable complexity to the implementation.
- Nevertheless, such functionality is not unheard of; for example, adding sticker thickness is already an available option in svg2ldraw, above.
- Third-party tools, such as Blender, can also be used to extrude a mesh in this fashion.
Additional projection methods: The three existing methods (planar, cylindrical and spherical) may or may not be appropriate for mapping textures generated from LDraw or .svg code. Would it be necessary to explore additional projection methods?
- Lasse's Pattern Folder utility may offer other approaches to projecting LDraw geometry onto a variety of surfaces.
Primitive substitution: This is a complicating factor in mapping LDraw geometry. It would be desirable to retain such functionality, or else the texture mapping loses much of its advantage as far as image resolution. Any implementation of LDraw code mapping should allow for the inclusion of primitive substitution.
- However, full adoption of SVG format would provide the wanted image resolution without the need for prim sub.

All feedback is welcome. This seems like a promising idea to me, since it requires minimal alteration to the spec while providing a number of advantages to patterned parts authoring (and beyond), while also offering some potential streamlining of the parts library. (There is no doubt that patterned parts will continue to be among the fastest-growing category.)
It also seems to draw upon ideas already shared by many LDraw users, and can benefit from functionalities already fairly well-developed both within and outside the LDraw universe. As always, I am by no means a programmer, so there will be considerations I haven't thought of. But it does seem that this is much more a question of combining and refining existing capabilities, than it is of creating new ones.
Thanks for reading!

Some issues with current Colours

Sat, 03 Jan 2026 18:57:38 +0000

I did a quick recap of all the Opal colours so far (a total of 8) and noticed a few issues with older existing Opals, but also a few other colours:

Our Opal_Trans_Green (ID 367) is using the wrong Base Colour; Trans_Green instead of Trans_Bright_Green. This is likely caused by the official name being just "Transparent Green with Opalescence" for some reason. Opal Trans-(Dark-)Green parts do exist, but those are purely unofficial at the moment. I intend to change the current one to match Trans_Bright_Green.
Should 363 Opal_Trans_Black be renamed to Opal_Trans_Brown? This Opal colour is based on the old 1999-2022 Trans-Brown and it's not entirely unlikely we will eventually see parts in "real" Opal-Trans-Black.
None of the 3 variants of Trans-Purple (52 Regular, 129 Glitter, 365 Opal) currently match. Those are all based on the same plastic colour, just with a different amount of the glitter additive, so should be very close for the real parts. Is this something that should stay this way?
For Trans_Clear (47) and Glitter_Trans_Clear (117) the same Mis-Match applies as with Trans_Purple.
Colour 294 Glow_In_Dark_Trans currently uses the same Alpha value as the other 2 Glow-in-the-Dark colours 21 and 329, despite being noticably more translucent on real parts. Should it's Alpha be lowered?
The colour 342 Conductive Black (only ever used for part 15411, the App-Bricks in Ultra Agents) would probably look more realistic if it got changed to a type of Glitter colour, likely with dark grey particles instead of silvery ones used for real Glitter colours.
Colour 77 Light_Pink seems to use a wrong Hex (#FECCCF). The Lego Colour this is based upon (223 Light Pink) uses #F17880 officially and looks much darker/saturated than the current one. This is an odd colour anyways, since it's one of the few in LDraw that never was released officially. It was supposed to replace 101 Medium Red (12 Salmon) in 2004, but got eventually cut.

Any objections/comments?

New 2026 Colours

Sat, 03 Jan 2026 05:19:27 +0000

As many of you probably noticed, we got 2 new colours in 2026 sets: Warm Pink and Blue Violet.

Both are now addedto LDConfig as:
430 Warm_Pink (Warm Pink)
431 Bright_Blue_Violet (Blue Violet)

The official name for Blue Violet was unfortunately already taken for a quite a while now, so I had to come up with a different name. Our "Blue_Violet" is Lego's "195 Royal Blue" - a retired, yet still not that rare of a colour (used primarily in Knights' Kingdom II around 2004-2006).

For the moment I opted not to rename the older colour to avoid confusion, but it still feels not optimal all things considered

I also noticed Bricklink recently changed their name for the old "Blue Violet" to "Royal Blue (Old Blue-Violet)". Maybe it's better to do something similar?

Any opinions on this?

Missing Opal Trans Yellow

Fri, 26 Dec 2025 12:53:41 +0000

Hi,

For this hair https://www.bricklink.com/v2/catalog/cat...P=1987pb03 I would need Opal Trans Yellow which is not in the color list.

Kind regards,

Lisa

About size of flattened sticker and formed sticker

Tue, 16 Dec 2025 00:23:14 +0000

Hello,
do the dimensions of the flattendd stickers and formed stickers have to be the same?

Until a few weeks ago this seemed like a useless question especially for cylindrical stickers, but lately this is no longer the case!

in the regulation to create the stickers there is talk of measuring them in LDU, but it is not required that they are exactly the dimensions indicated in the description.
And this has been interpreted as such by me, by the auditors and by the administrators until recently.

For a few weeks I have seen that they are trying to make the stickers the exact size shown in the description.
They say: the difference is minimal, a few hundredths of a millimeter, you can't see it.
Agreed, perhaps, but the opposite is also true.
It depends on how you deal with the problem of creating a new set of stickers and how you want to act on the ones already made.

When I have to create a new set of stickers I do this: I check which pieces should be attached, I check if there are already any stickers with the same shape (the stickers help in this), I make the flat version in various subparts and then the formed one is born accordingly. This means that reviewers have until 6 or12 subparts to check for a single sticker, but once the subparts are OK you know that the two mainparts are perfect and you don't have to check that they match. The explanation that has been given, however, is not to reduce the number of subparts.

With what is being done now, however, it becomes practically mandatory to look for a flattened stickerback that is compatible and the formed one. Then you have to create the flattened and formed version which are not exactly the same, so the game of subparts cannot be done. Drawing the sticker formed in this way will cause a lot of imperfections due to rounding that will require additional condlines. Or do you decide not to consider them a priori?

The way you are trying to edit the official stickers is somewhat questionable. Add slices of a few tenths of LDU to the ends of the flattened version, leaving the formed sticker unchanged, when it would be enough to change once and for all the stickerback formed and the two subparts at the ends to have everything consistent as it has been done so far.
It's a lot of work that we didn't feel the need for until a couple of weeks ago, but if you really want to do it, do it well.
Also because otherwise a new sticker how should I do it? If I do it as I have done so far, you will surely tell me that those slices are too thin and do not fit.

So I repeat the questions.
Do flattened and formed stickers have to be the same length?
For me: Yes
Do you need to round the stickerbacks to the nominal size of the description?
For me: No

Rather, if you think that the flattened version can have reusable dimensions from a flat only sticker with nominal size, then let's create a second version (a, b, c...) in which in the description we say what to use that stickerback for stickerback020x038a.

Massimo

Sticker Box or Sticker Back

Fri, 21 Nov 2025 20:10:01 +0000

The official Sticker Box standard specify the file naming rule as "stickerback...".
Consequently all sticker backs have "Sticker Back" in their descriptions.
Is this the way it was supposed to be or should they have "Sticker Box" in the description?

LDConfig.ldr problem with colour 11019 Trans_Tan?

Fri, 07 Nov 2025 20:59:25 +0000

I have a problem with LPub3D rendering LDView with Enable Highlight Steps.

Parts with tan colour now appear transparent instead of just highlighting the edge colour.
https://photos.app.goo.gl/JfhVyvE7CVQzUPqE7

The root cause seems to be in LDConfig.ldr with this change:

0 !LDRAW_ORG Configuration UPDATE 2025-09-18
0 // Last update: Added 11015 Trans_White and 11019 Trans_Tan

LPub3D uses the prefix 110 to show the highlighted parts with a defined edge colour:

# File: LEGOFadeStepColorParts.lst Generated on: 11-07-2025 19:53:40

# This space-delimited list captures the LDraw static color parts (and their subfiles) to support
# step fade and step highlight. Parts on this list are identified in the LDraw library and copied to
# their respective custom directory. Copied files are modified as described in the following
# lines. If fade step is enabled, color codes are replaced with a custom code using the standard
# color code prefixed with [100].

# If using a single fade step color, color codes are replaced with main material color
# code 16 using the fade color set in Preferences. If part highlight is enabled, edge
# color values are replaced with the color value set in Preferences. If part highlight is
# enabled, color codes are replaced with a custom code using the standard color code
# prefixed with [110].

# When fade step is enabled, custom generated files are appended with '-fade',
# for example, ...\custom\parts\99499-fade.dat

# When highlight step is enabled, custom generated files are appended with '-highlight',
# for example, ...\custom\parts\99499-highlight.dat

So LDView now finds the new colour 11019 in LDConfig.ldr to be Trans_Tan, instead of the local definition of LPub3D in the temporary file 42143 - 1.1.1.1-highlight.ldr:

0 !COLOUR LPub3D_Orange CODE 11025 VALUE #D67923 EDGE #C000FF00 ALPHA 255
0 !COLOUR LPub3D_Dark_Azure CODE 110321 VALUE #469BC3 EDGE #C000FF00 ALPHA 255
0 !COLOUR LPub3D_Yellow CODE 11014 VALUE #FAC80A EDGE #C000FF00 ALPHA 255
0 !COLOUR LPub3D_Tan CODE 11019 VALUE #D7BA8C EDGE #C000FF00 ALPHA 255
0 !COLOUR LPub3D_Light_Bluish_Grey CODE 11071 VALUE #969696 EDGE #C000FF00 ALPHA 255
0 !SILHOUETTE 1 #C000FF00
1 11071 0 0 0 -1 0 0 0 -1 0 0 0 1 64179.dat
1 11019 0 0 50 0 0 1 0 1 0 -1 0 0 3749.dat
1 11014 0 0 40 1 0 0 0 1 0 0 0 1 69762.dat
1 11014 0 0 -40 1 0 0 0 -1 0 0 0 -1 69762.dat
1 11019 0 0 -70 0 0 -1 0 1 0 1 0 0 99008.dat
1 110321 0 0 -80 1 0 0 0 -1 0 0 0 -1 69779.dat
1 11014 0 0 0 0 0 -1 0 1 0 1 0 0 42143 - 1.1.1.1.1-highlight.ldr
1 11014 -40 0 0 1 0 0 0 1 0 0 0 1 4519.dat
1 11014 -70 0 0 0 0 1 0 1 0 -1 0 0 59443.dat
1 11014 40 0 0 -1 0 0 0 1 0 0 0 -1 4519.dat
1 11014 70 0 0 0 0 -1 0 1 0 1 0 0 59443.dat
1 11025 40 0 -60 0 0 -1 1 0 0 0 -1 0 65304.dat
1 11025 -40 0 -60 0 0 -1 1 0 0 0 -1 0 65304.dat
0 !SILHOUETTE

How to solve this conflict?
Why has the colour 11019 been included in LDConfig.ldr ?
If I remove it there, the problem is solved.

Vertex precision

Thu, 09 Oct 2025 15:14:23 +0000

For free-form stand-alone vertexes, one decimal is usually enough. However, when a vertex is defined by a circular primitive, rotated subparts or the intersection of slanted surfaces, then more decimals are needed. I've tried working with three decimals, but tools like Edger2 will not always recognize the presence of a cond line rounded to three decimals. Similar results with overlap- and gap-finding tools.

The official parts library specifications state "In general, three decimal places are sufficient for parts, subparts, and primitives representing portions of parts that are not intended to be scaled (for example, studs, pegs, peg-holes, clips, hinge ends, etc.). Four decimal places should be used for high-res primitives and any primitives designed to be scaled (for example, cylinder sections, boxes, rectangles, discs, edges, etc.) as this allows such primitives to be scaled by a factor of ten while still preserving three decimal places of accuracy.".

I'd like to amend this by allowing 4 decimal places to be used for

vertexes on a rotational plane of symmetry (e.g. 30, 45, and 72 degree planes),
intersections calculated by isecalc,
any vertex that is defined by a scaled primitive.

The first one because this will avoid gaps/overlap when multiple similar subfiles are put together in a larger assembly.
The second one to have an accurate edge line where two surfaces intersect each other.
The third one to avoid gaps/overlap next to any scaled primitive. This is also needed for all cond lines that have a point or a control point on such a vertex.

If we all agree, can this be made official?

Cylindrical polygons

Wed, 08 Oct 2025 06:33:11 +0000

Currently, we have cylindrical polygons with 8, 16, and 48 sides. So, if a part needs a 1-6 sweep, we are forced to use the 48-sided polygon. For very large radii, even 48 sides is not enough. We have 84-sided polygons on the tracker. When we need a cylinder with the number of faces divisible by 5, a custom 50-sided polygon becomes used. What if 16 points are too coarse and 48 points are too dense?

I'd like to solve these by introducing 12, 24, 60, and 84-sided cylinders. The 12-sided is a nice replacement for the 8-sided because three segments make much nicer corners than 2 segments. The 24-sided is perfect when 48 is too much and 16 too little. Both allow 1-6 sweeps. The 60-sided cylinder is more usable than the 50-sided cylinder in that it is divisible by both 3 and 4. The point of the 84-sided cylinder is that the vertexes are distributed differently (divisible by 4, but not by 8) than any multiple of 48, thus allowing vertex optimization at large radii.

The 60-sided cylinder would be used at radii above 36.
The 84-sided cylinder would be used at radii from 80 to 120.

Here's a table showing the segment length for different radii and polygons. Below are recommendations for minima and maxima (radii and segment length) for each polygon optimized for segment length.

radii_table.png (Size: 302.67 KB / Downloads: 0)

The polygon "4" is just a corner made out of one quad at a 45 degree angle.

move to history

Sun, 28 Sep 2025 14:33:13 +0000

The specifications for a move to file is brief and doesn't state explicitly whether one should include part or all of the history and in which file. In an earlier thread Magnus Forsberg instructed:

Quote:XXXXX.dat
Description = "~Moved to XXXXXb"
Author = Me
Content = "1 16 0 0 0 {rotation matrix} XXXXXb.dat" (the rotation matrix restores the old orientation)

XXXXXb.dat
Description = Same as before
Author = Same as before
History line = "corrected orientation by creating b replacement file" + any minor corrections
Content = all previous content + any minor corrections

If I understand correctly, the "b" file should contain all of the previous history. What history goes into the file I authored?

Stud groups

Thu, 18 Sep 2025 20:04:56 +0000

The code
1 16 0 0 10 1 0 0 0 1 0 0 0 1 stug-1x4.dat
1 16 0 0 0 1 0 0 0 1 0 0 0 1 stug-1x3.dat
1 16 0 0 -10 1 0 0 0 1 0 0 0 1 stug-1x2.dat
produces this:

stugs.png (Size: 34.49 KB / Downloads: 29)
Based on the description below, I would have expected that the number of studs in the Z-direction would have changed. To my surprise, the number of studs in the x-axis increased. I suspect the official reference guide is wrong about stud groups. I'm also unhappy that the reference guide doesn't tell me from which direction the logos are readable (they're actually sideways).

Stud groups are provided to reduce the size of part files with many regularly spaced studs. The naming convention is stugN-XxZ.dat, where:

N = type of stud (regular stud, hollow stud, underside stud, etc.)
X = number of studs on the x axis
Z = number of studs on the z axis

To prevent an overload of the library with excessive combinations, the numbers on the x and z axis are limited to:

1xZ stugs
Xx1 stugs (Due to stud orientation you cannot rotate a 1xZ stud group by 90 degrees to get a Xx1 stud group)
XxZ stugs where X = Z