Discussion - proposal to extend !TEXMAP specification

[N. W. Perry]

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 <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).
    
• 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!

[Hageta]

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?

[N. W. Perry]

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?

[Hageta]

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.

[N. W. Perry]

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.

[Roland Melkert]

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).

[N. W. Perry]

SVG on the other hand is not that easy to implement, it might cause some problems support wise (meaning some programs do others not).

I included SVG mainly because it seems multiple people have already created conversion tools, so perhaps these tools could be incorporated into other programs without too much difficulty.

Since I am curious, what are the challenges with SVG? In the past, I have converted it manually to Draw code and could probably create a script to automate the process—but of course, that leaves out some elements such as curves, colors, etc.

Or is it that we don't want to have to convert, but instead render SVG graphics directly? In which case, would it be enough just to have an import capability?

[Travis Cobbs]

I included SVG mainly because it seems multiple people have already created conversion tools, so perhaps these tools could be incorporated into other programs without too much difficulty.

Since I am curious, what are the challenges with SVG? In the past, I have converted it manually to Draw code and could probably create a script to automate the process—but of course, that leaves out some elements such as curves, colors, etc.

Or is it that we don't want to have to convert, but instead render SVG graphics directly? In which case, would it be enough just to have an import capability?

I think that the only way that SVG could reasonably be supported by LDraw programs would be via a 3rd-party library that renders the SVG to an in-memory bitmap image that could then be used as the texture. Creating custom SVG parsers in LDraw programs seems like the wrong solution.

I for one feel that supporting SVG for textures would be a bad idea, but I won't completely rule out the possibility of support in LDView if people push for it.

Note: I created SvgToDat 7 years ago, but as per its README: "Only works with a subset of SVG geometric primitives."

Also, I found this C++ library to render SVGs, but I have no idea how well it works:

https://github.com/sammycage/lunasvg

[Orion Pobursky]

I think that the only way that SVG could reasonably be supported by LDraw programs would be via a 3rd-party library that renders the SVG to an in-memory bitmap image that could then be used as the texture. Creating custom SVG parsers in LDraw programs seems like the wrong solution.

I for one feel that supporting SVG for textures would be a bad idea, but I won't completely rule out the possibility of support in LDView if people push for it.

Note: I created SvgToDat 7 years ago, but as per its README: "Only works with a subset of SVG geometric primitives."

Also, I found this C++ library to render SVGs, but I have no idea how well it works:

https://github.com/sammycage/lunasvg

I'll note that SVG textures will only be supported by the Library if LDView supports them. If we choose to allow a "Subset of SVG geometric primitives", then that subset will need to be very sharply defined so that the Library can validate the files.

I'll also note that the PHP SVG capabilies rely on ImageMagick which in turn relies on librsvg which, by thier own documentation, does not aim to "implement every single SVG feature that is in the spec".

[N. W. Perry]

I think that the only way that SVG could reasonably be supported by LDraw programs would be via a 3rd-party library that renders the SVG to an in-memory bitmap image that could then be used as the texture. Creating custom SVG parsers in LDraw programs seems like the wrong solution.

Although I'm not informed on the technical details, I can recognize that support for direct parsing of SVG textures may not be the right approach, especially if LDraw code is supported by texmap. An in-memory bitmap is closest to what I imagined, but if LDraw geometry can be projected as a texture then perhaps it's more of a translation issue. It may be enough to be able to import an SVG file and convert it to LDraw using an existing tool, which could act as a plugin to a modeling program (similar to the many tools incorporated with LDPE).

The potential pitfall is losing the scalability especially of curved geometry, which must necessarily be down-sampled when converting from SVG to LDraw. The solution I'd really like to see would be expanding the LDraw format to somehow represent curved lines and surfaces (beyond simply using curved primitives). But that's another topic…

I for one feel that supporting SVG for textures would be a bad idea, but I won't completely rule out the possibility of support in LDView if people push for it.

What do you feel are the drawbacks of supporting SVG?

Note: I created SvgToDat 7 years ago, but as per its README: "Only works with a subset of SVG geometric primitives."

Was it 7, or 17?

There are three tools I'm aware of: yours, T. Boschi's svg2dat, and Lasse's svg2ldraw.

I'll note that SVG textures will only be supported by the Library if LDView supports them. If we choose to allow a "Subset of SVG geometric primitives", then that subset will need to be very sharply defined so that the Library can validate the files.

I'll also note that the PHP SVG capabilies rely on ImageMagick which in turn relies on librsvg which, by thier own documentation, does not aim to "implement every single SVG feature that is in the spec".

This is a good point. SVG does an awful lot of stuff that isn't relevant to our purposes (and it probably doesn't do some things that are, such as materials), so full parsing ability would certainly be overkill. This would likely mean very specific restrictions on allowable SVG content, which would likely mean more pre-processing in Inkscape or wherever, both to clean the file to allowable specs and perhaps also to re-map certain things like colors and materials to LDraw-usable form.

This is important because, to me, the greatest benefit to supporting SVG would be to reduce the workflow for authors and hopefully expand opportunities for contributors, especially with patterned parts.

Right now it's fairly time-consuming to go from a reference image to LDraw code, but once you have that, you're basically finished (unless it's a curved pattern, but being able to texmap LDraw code would alleviate that).

With SVG the situation is reversed: it's quite simple to go from reference image to SVG, but then a fair amount of work remains to translate that to LDraw code. So it's that final step where I see an opportunity to increase participation, whether by way of conversion/translation, or actual rendering support.

[Chris Böhnke]

Regarding the "material" aspect:

Main problem with the material properties will likely be to include the reflective properties ("shinyness") of metallic "ink" colours (82 Metallic Gold, 80 Metallic Silver etc.). I'd say it will be noticable in high quality renders if those are ignored.

"Real" material of stickers seems to be fairly identical (at least for 1985?-today). Both the white and clear stickers have a similar finish to them, not so sure about the really old ones (Fabuland, Homemaker) - I have a few that look more dull, is that due to age?

There are also a few ones with a chrome-like finish for mirrors, but I'd say those are simple enough to not need texmaps at all.

[Roland Melkert]

Main problem with the material properties will likely be to include the reflective properties ("shinyness") of metallic "ink" colours (82 Metallic Gold, 80 Metallic Silver etc.). I'd say it will be noticable in high quality renders if those are ignored.

Here the 'LDraw texture' would have the advantage as you could write a shader to apply the global ldraw material properties during rendering. 

This would be optional as the simplest implementation would just generate a RAW rgba texture instead of loading it from png.

[N. W. Perry]

Here the 'LDraw texture' would have the advantage as you could write a shader to apply the global ldraw material properties during rendering. 

This would be optional as the simplest implementation would just generate a RAW rgba texture instead of loading it from png.

For this and other reasons, it seems to me that any implementation of SVG would need to pass through LDraw format anyway, at least in some cases.

Or could the already-specified GLOSSMAP parameter serve to provide material finished for SVG-derived textures? (Would this even be logical, or desirable?)

Maybe another way we should be looking at this is simply that we want to be able to map both raster and vector patterns, without necessarily locking ourselves into specific formats.

In other words, for raster images we already allow PNG, but maybe someday another format will also prove suitable? And for vectors, we propose at least LDraw format, but do we also leave open the future possibility of SVG or other?

[Travis Cobbs]

What do you feel are the drawbacks of supporting SVG?

I feel that the main drawback is complexity. Rendering programs need to depend on yet another library.

Was it 7, or 17?

I just looked at the date on GitHub. I forgot that I created it long before that.

[Orion Pobursky]

I feel that the main drawback is complexity. Rendering programs need to depend on yet another library.

I echo this concern. With PNG it's simple, an image is an image, but with SVG there's a whole raft of commands that we won't support.  This will inevitably cause problems when someone submits part and it doesn't render correctly. It's also adds a whole lot more complexity to the validation process.

[Hageta]

I would propose that 2D LDraw patterns would work like layers if multiple primitives are used, this would make creating patterns easier. They could be ordered either top to bottom or the other way around, this would be part of the specification.

Another idea I have would be a kind of line metacommad for 2D patterns. It would have at least 3 components: LDraw colour, thickness in LDU and list of points, that make up the line.

[Roland Melkert]

I would propose that 2D LDraw patterns would work like layers if multiple primitives are used, this would make creating patterns easier. They could be ordered either top to bottom or the other way around, this would be part of the specification.

Another idea I have would be a kind of line metacommad for 2D patterns. It would have at least 3 components: LDraw colour, thickness in LDU and list of points, that make up the line.

So basically like painting on a canvas 

Interesting idea, it would need a very strict definition on how to render that resulting line though.

Monstly on how the segments are formed, eg:

Code:

[====]
,
<====>
or
(====)
etc

[N. W. Perry]

I would propose that 2D LDraw patterns would work like layers if multiple primitives are used, this would make creating patterns easier. They could be ordered either top to bottom or the other way around, this would be part of the specification.

Another idea I have would be a kind of line metacommad for 2D patterns. It would have at least 3 components: LDraw colour, thickness in LDU and list of points, that make up the line.

Well now that's interesting—if you're going to do that, and given the complexity of SVG implementation, what you're really talking about is extending the LDraw language itself to include 2D drawing commands, and so why not just implement those few commands that are useful from SVG in an LDraw-native syntax, then you don't have to deal with all the other ones that aren't useful.

I've imagined extending LDraw to include more scalable vector capabilities in the past, though I didn't think of adding features for pattern drawing before. Though if we want to think about that, we don't have to wait for the outcome before deciding on the present question of TEXMAP, since we'd simply be allowing any valid LDraw code to be mapped, however it may or may not be extended in the future.

[Hageta]

The way svg paths are defined could be an inspiration for the LDraw version.
svg path d parameter

Also do not forget the layer thing.

[N. W. Perry]

The way svg paths are defined could be an inspiration for the LDraw version.
svg path d parameter

Also do not forget the layer thing.

Yes, the d parameter is pretty simple, just plugging in coordinates and deltas. I already do this by hand. :-) And the Bezier math is an easy formula for a computer.

Layers could be used e.g. to blend colors, giving more realistic results for multiple printing passes on real-world parts (the subject of many a Parts Tracker comment thread over the years).

TEXMAP statements can already be nested so I don't see why they couldn't be layered. I don't know how involved compositing is, though.