+- 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: Discussion - proposal to extend !TEXMAP specification (/thread-29327.html)
Discussion - proposal to extend !TEXMAP specification - N. W. Perry - 2026-01-19
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-post-59106.html#pid59106
https://forums.ldraw.org/thread-29246.html
https://forums.ldraw.org/thread-29160-post-59106.html#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.
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 <ldraw> or <svgfile> as alternatives to the current <pngfile> 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).
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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!
RE: Discussion - proposal to extend !TEXMAP specification - Hageta - 2026-01-19
It may be usefull to include LDraw colour codes in the svg file. Maybe this could be done in custom tag or maybe through a mapping table outside the file?
RE: Discussion - proposal to extend !TEXMAP specification - N. W. Perry - 2026-01-19
(4 hours ago)Hageta Wrote: It may be usefull to include LDraw colour codes in the svg file. Maybe this could be done in custom tag or maybe through a mapping table outside the file?
Could that be handled by LDConfig?
RE: Discussion - proposal to extend !TEXMAP specification - Hageta - 2026-01-19
(4 hours ago)N. W. Perry Wrote: Could that be handled by LDConfig?
I am not quite sure how, since some colours use the same rgb values e.g. : Black[0], Chrome_Black[64]. It should also be possible to still use direct colours.
RE: Discussion - proposal to extend !TEXMAP specification - N. W. Perry - 2026-01-19
(3 hours ago)Hageta Wrote: I am not quite sure how, since some colours use the same rgb values e.g. : Black[0], Chrome_Black[64]. It should also be possible to still use direct colours.
Good point, I guess it's more about material/finish than the color (hue) itself. Still, I think a simple mapping table would suffice; perhaps it can be handled by embedded style sheets in the SVG. I know direct colors are not a problem.
RE: Discussion - proposal to extend !TEXMAP specification - Roland Melkert - 2026-01-19
I'm all for supporting LDraw code for use in texture generating because it's basically free inside a LDraw program.
All one needs is information about how to project it. Or alternatively we could restrict the source files to 2D on eg the zx plane.
SVG on the other hand is not that easy to implement, it might cause some problems support wise (meaning some programs do others not).