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.

[Manfred Schaefer]

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.

Hello,

Regarding SVG graphics. I use Inkscape to convert bitmap graphics into vector graphics. This works quite well. Inkscape saves the data as SVG graphics. I don't know which part or how much of the definition is used, but sometimes the absolute and relative values are not defined correctly (upper case, lower case).
But that's not the big problem. The issue is Bezier curves. You can either trace these with line segments or piece by piece using arc segments with different factors in the x and z directions. Arc segments have the advantage that primitives can be used. Then comes the triangulation.
Once I've gotten that far, why should I still use SVG?
In my opinion, bitmap graphics are only a stopgap solution and can cause problems; for example, exporting to PovRay in LDView does not work.
If primitives are used, scaling is hardly a problem thanks to the capabilities of LDView.
Before the TEXMAP specification is extended, I would consider it more useful to improve the graphics capabilities, such as color gradients.
Or functions such as for loops, parameter passing, and much more.
PostScript could serve as food for thought here.

Best regards,
Manfred

[N. W. Perry]

Regarding SVG graphics. I use Inkscape to convert bitmap graphics into vector graphics. This works quite well. [process snipped]
Once I've gotten that far, why should I still use SVG?

Exactly. The idea of supporting SVG is so that you wouldn't have to go that far.

But your point is well taken that it's only a small number of SVG parameters that must be converted, and to do so is fairly trivial (in terms of process if not human time), so why take the trouble to implement SVG at any kind of full level?

It occurs to me that SVG is really more of a language than a format, and so the better idea might be to adapt statements from that language into LDraw's, rather than converting or parsing at render time.

If primitives are used, scaling is hardly a problem thanks to the capabilities of LDView.

True, although primitives tend to see less use in patterns than in 3D geometry. There are also cases like text, where gaining scalability comes at a cost to file size and mesh complexity.

I would like to see a case where such scaling capabilities can be applied to non-primitive curves as well. Right now the biggest challenge in rendering seems to be where primitives adjoin non-primitive curved surfaces.

Before the TEXMAP specification is extended, I would consider it more useful to improve the graphics capabilities, such as color gradients.
Or functions such as for loops, parameter passing, and much more.

If improving graphics capabilities within the LDraw specification is moved to a separate proposition, and if the SVG parameters are joined to that discussion instead of this one, then I see no reason why TEXMAP has to wait. The only remaining component would then be the addition of LDraw code to the TEXMAP spec, which so far has seen some support and no objection that I know of. So that part should be ready to go, and if and when LDraw language is extended with additional graphics capabilities, they would already be supported by a mapping and projection method.

---

This raises the question, then: If SVG were removed from the proposal, leaving only LDraw code to be added to TEXMAP, what remains to be determined before the proposal could advance?
Are there any arguments against the LDraw side of the proposal?

[Max Murtazin]

If SVG is ever to be allowed, I feel like there has to be some restrictions put onto which parts of SVG specs are to be allowed. There is already a very big problem with consistency of implementations of it's parts, even in some big software, and I have no doubts the problem will only be exaggerated with the solutions different implementations of LDraw renderers will run into

Also, with any such extension to me a problem of backwards compatibility begins to look worse with each time. Realistically, this would only enlarge the number of parts that would be effectively unsupported with each such change. Unless the change is going to introduce big improvements to either part making or ease of implementation (which I don't really see this proposal really doing either of the two), I'm not gonna be very supportive of it

[Roland Melkert]

Also, with any such extension to me a problem of backwards compatibility begins to look worse with each time. Realistically, this would only enlarge the number of parts that would be effectively unsupported with each such change. Unless the change is going to introduce big improvements to either part making or ease of implementation (which I don't really see this proposal really doing either of the two), I'm not gonna be very supportive of it

This is why I think using LDraw code to generate a texture might be the best of both worlds. 

Any program should already support LDraw commands and could therefore easily render its output into a texture.

[N. W. Perry]

If SVG is ever to be allowed, I feel like there has to be some restrictions put onto which parts of SVG specs are to be allowed. There is already a very big problem with consistency of implementations of it's parts, even in some big software, and I have no doubts the problem will only be exaggerated with the solutions different implementations of LDraw renderers will run into

Based on the discussion, my feeling now is that SVG—or, as you say, a limited subset of its specifications—is better implemented as an extension to the LDraw language format. I don't know whether this would entail embedded the XML tags for SVG elements into LDraw code, or simply creating new LDraw commands that perform (and could be converted from) SVG commands. In any case, this would be a later, separate discussion and no longer part of the current proposal.

Also, with any such extension to me a problem of backwards compatibility begins to look worse with each time. Realistically, this would only enlarge the number of parts that would be effectively unsupported with each such change. Unless the change is going to introduce big improvements to either part making or ease of implementation (which I don't really see this proposal really doing either of the two), I'm not gonna be very supportive of it

TEXMAP already addresses backwards compatibility with its fallback method, so the situation would be the same as it is now, say with a PNG texture that's not supported by the rendering program. If anything, it should improve backward compatibility since you'd already be creating LDraw code, which could perhaps be more easily converted to a traditional non-mapped LDraw pattern for fallback purposes. Right now, if you're mapping a PNG texture, your options are basically to fallback to an unpatterned geometry, or separately create a version using LDraw geometry.

Improvements should be very tangible with this proposal. For part making, patterns should become much easier since you only have to author a flat version, rather than figuring out how to break up patterns to use them on curved surfaces. And it would give better results, since you get the crispness of LDraw textures without losing the definition of the underlying curvature. (Also don't forget the potential improvements to non-patterned curved surfaces, too.)

Implementation is not my expertise, so I rely on Roland's optimism for its ease of implementation. I do still want to hear from any other developers, though—are there any opinions for or against the proposal, assuming SVG is out of the picture?

[Hageta]

I would also be for only implementing LDraw code only and adding some features of svg to LDraw itself later. These could be used by a converter.

I would also like for overlapping 2D primitives to be valid and treated like layers, wich make creating complex shapes and creating backgrounds easier.

[Max Murtazin]

I would also be for only implementing LDraw code only and adding some features of svg to LDraw itself later. These could be used by a converter.

I would also like for overlapping 2D primitives to be valid and treated like layers, wich make creating complex shapes and creating backgrounds easier.

Reason for banning overlapping geometry is very much practical, as it leads to a lot of trouble when rendering it, such as z-fighting

[N. W. Perry]

Reason for banning overlapping geometry is very much practical, as it leads to a lot of trouble when rendering it, such as z-fighting

Probably this would end up being in the domain of pattern authoring programs; I don't know if such a thing would end up in the spec as it would presumably be bounced down to final geometry in the output. But, in any case, a good topic for the extended discussion on graphics capabilities and presumably outside the domain of the TEXMAP spec.

[Roland Melkert]

Reason for banning overlapping geometry is very much practical, as it leads to a lot of trouble when rendering it, such as z-fighting

I would suggest to only allow this inside a "LDraw Texture" subfile.

A renderer should just disable the depth buffer for awhile.

The ldraw code should enforce that by a begin end block, e.g:

Code:

0 !LAYER START background
<normal ldraw lines>
0 !LAYER END
0 !LAYER START text
<normal ldraw lines>
0 !LAYER END

Naming the layer could be optional.

Alternative would be to always disable the depth buffer while rendering ldraw code to a texture.
No layer indications would be needed in such a case.
But authors must understand it's 'first come, first served' in such a scenario.

[N. W. Perry]

I would suggest to only allow this inside a "LDraw Texture" subfile.

This reminds me to ask, how would the LDraw texture code be provided?

• As a normal subfile using 0 FILE or normal search paths?
  
• As a special kind of subfile, also using 0 FILE or search paths, but with modified headers/syntax?
  
• As a code snippet using the proposed !CODE meta (or search paths)?
  
• Within the TEXMAP statement?
  
• All of the above?
  

I had envisioned either !CODE snippets or geometry within the TEXMAP statement, but perhaps other options should be left open, if further extensions to LDraw texture capabilities are to be explored.

[Roland Melkert]

This reminds me to ask, how would the LDraw texture code be provided?

I don't see the need to make any kind of special type of subfile, any ldraw file could be rendered into a texture.

The spec needs only to dictate the projection and depth buffer settings.

[N. W. Perry]

I don't see the need to make any kind of special type of subfile, any ldraw file could be rendered into a texture.

The spec needs only to dictate the projection and depth buffer settings.

I'm thinking specifically about the <pngfile> argument in the current TEXMAP meta syntax. We would need to add ldrfile as an option here; anything else? Maybe txtfile?

Do we need !CODE? For library purposes I assume LDraw texture files would need to exist as standalone .ldr files, but for personal projects it seems useful to be able to drop in a few lines of code without needing to build correct headers, etc.

Second question:
How can we make the "receiving" surface—that is, the <geometry1> data in the !: meta—invisible? Is that possible now (with a PNG file) or would something have to be added?

[Roland Melkert]

Do we need !CODE? For library purposes

No it is only for embedding png's inside a mpd on the user side.

How can we make the "receiving" surface—that is, the <geometry1> data in the !: meta—invisible? Is that possible now (with a PNG file) or would something have to be added?

This works exactly the same for a png or ldr texture as the ldr is only used to generate a bitmap internally. The same kind of bitmap png's will end up in currently.

The spec needs only to allow referring to a ldraw file (dat/ldr/mpd) or a png.
And it must also explain how such a ldraw file is expected to end up in a bitmap projection wise and maybe (relative) size wise.

[Magnus Forsberg]

Am I understanding you all correct? 

   

The same ldraw code, the pattern, gets embedded into an png-image that can be projected onto a perfect, unbroken surface, 
and is included as a full fallback section in the texmap section?

[Orion Pobursky]

This is that way I see it.

I support this method as it is clearly backwards compatible and is easy to review within the current LDraw standards.
However, library support will not be implemented until and unless LDView, LDCad, Buildinginstructions.js, and LeoCad support.

Additionally, I do not support allowing the "layering" of LDraw geometry via an additional !META command.

[N. W. Perry]

No it is only for embedding png's inside a mpd on the user side.

!DATA does that—my idea was that !CODE would do the same for non-binary data. It was originally meant for SVG code, but I thought it code also be useful for LDraw snippets even if we're not including SVG.

This works exactly the same for a png or ldr texture as the ldr is only used to generate a bitmap internally. The same kind of bitmap png's will end up in currently.

Can you, for example, map a texture onto a cylinder primitive, but not actually render the cylinder, only the texture? (So you'd just see a curved picture floating in the air, basically.) Could be as simple as using a color that's 100% transparent, I suppose.

It might be silly to do that with a png, but if you could do it with LDraw code, you could create surfaces based on rounded primitives that don't fit into the existing fractional sizes—for example, the bottom edge of a 3941.dat.

[N. W. Perry]

Am I understanding you all correct? 
The same ldraw code, the pattern, gets embedded into an png-image that can be projected onto a perfect, unbroken surface, 
and is included as a full fallback section in the texmap section?

Well, not the exact same code, since the pattern being mapped could be authored flat, without background areas, etc, whereas the fallback code would have to include all these things (as it currently does). Authors might opt for a simpler pattern in their fallback section (as they currently do), such as the default face currently being used for Maxifig heads.

The new method should thus be much simpler to author, and also give visually better results than either hard-coded geometry or a texmapped PNG (assuming that the embedding of LDraw code into bitmap occurs at the proper place in the rendering pipeline—i.e., after prim sub has been applied to the receiving surface, accounting for current view, zoom factor, etc.).

[Roland Melkert]

!DATA does that—my idea was that !CODE would do the same for non-binary data. It was originally meant for SVG code, but I thought it code also be useful for LDraw snippets even if we're not including SVG.

Sorry I was thinking !DATA.

In theory the !DATA content could be anything (base64 encoded) but the current spec limits it to png. It is basically just a ASCII friendly container.

[Roland Melkert]

Been thinking about implementing a proof of concept in a special build of LDCad.

Needed:
- Projection (probably best to let the spec define a static one like Ortho looking at the z direction)
- Internal texture dimensions in ldu (the 'png' width/height, or supplied by a texture meta extension)
- Texture resolution (pixels per LDU=> probably best as an internal setting or render quality depended).
- Lighting settings (probably best to use none)
- Texture background color (probably best to always use 'transparent')

So imho the whole thing could work using a meta like:

Code:

0 !TEXMAP (START | NEXT) <method> <parameters> <pngfile|ldrawFile> [GLOSSMAP pngfile]

Which would let renderer decide the size of the texture based on the source's min/max x/y coordinates.

or something more flexible:

Code:

0 !TEXMAP (START | NEXT) <method> <parameters> <pngfile|ldrawFile> [GLOSSMAP pngfile] [SURFACE W H ofsX ofsY]

Where the ldraw source x/y coordinates will be added to ofsX,ofsY within a base surface of WxH (ldu). This could be applied to png's too but using pixels instead of ldu.


Thoughts?

[Travis Cobbs]

So, I want to step back. Is this functionality really something that part authors will use, and is it useful enough to justify implementation?

I'm pretty sure you could get the same rendered results by creating the LDraw geometry and then saving a PNG from a top-down view in LDView with transparent background enabled, then using that PNG as a texture. I will readily admit that doing it that way is a kludge, but if all people want is the ability to model their textures in LDraw, it does the job without requiring any spec or renderer changes.

Having said all that, if part authors believe that this will be genuinely useful, I'm not opposed to implementing it.

[N. W. Perry]

So, I want to step back. Is this functionality really something that part authors will use, and is it useful enough to justify implementation?

I'm pretty sure you could get the same rendered results by creating the LDraw geometry and then saving a PNG from a top-down view in LDView with transparent background enabled, then using that PNG as a texture. I will readily admit that doing it that way is a kludge, but if all people want is the ability to model their textures in LDraw, it does the job without requiring any spec or renderer changes.

Having said all that, if part authors believe that this will be genuinely useful, I'm not opposed to implementing it.

Using a PNG this way would not give the same results, as you'd be locked into the resolution of that PNG file before you even start the program. Projected LDraw geometry would be rasterized at the other end of the pipeline, taking into account the current view/zoom level, plus maybe user settings, etc. More scalable without increasing file size.

Would authors use it? I sure would. Being able to author a flat pattern and have it projected with all the crispness of LDraw geometry onto a cylindrical or spherical part, without messing up the smoothness of that curvature—or onto something much more complex, like a Muppet head or a sheep or something? I currently consider that beyond my skill level, but the projection method seems accessible to me. My feeling is that it will encourage other, less experienced part authors to try their hand at pattern authoring.

But besides what authors want, keep in mind that it benefits the reviewing and spec side of things, too. We've kind of set the standard (and rightly so, I think) that PNG textures aren't ideal for most patterns, but we also don't hold parts solely for being texmapped (and also rightly so, I think). This creates an extra workload down the line, as authors feel the need to re-takeup a texmapped part to vectorize the pattern. Being able to have patterns done the "right" way the first time, and more easily and with better results that the current method, has got to be worthwhile.

It does also have the potential to greatly simplify the library; if the concept proves successful, it could obviate the need for the entire category of patterned parts. All you need would be a collection of pattern files, and the base parts to project them onto.

And, don't forget the possible benefits to non-patterned parts as well. If projected LDraw code can solve some of the more irksome rendering anomalies we currently have, it's certainly worth implementing.

[Roland Melkert]

So, I want to step back. Is this functionality really something that part authors will use, and is it useful enough to justify implementation?

Besides the things mentioned above generating a texture on the go also opens the door to custom shaders using the original ldraw color codes (instead of translated rgba) at a pixel level. 

Such a shader could apply different material characteristics to the same surface allowing for things like metallic high lights etc.

This is besides it using the current draw palette instead of hardcoded rgba values.

[N. W. Perry]

Been thinking about implementing a proof of concept in a special build of LDCad.

Needed:
- Projection (probably best to let the spec define a static one like Ortho looking at the z direction)

I'm a little ignorant on this side of things. What projection info is needed that's different for LDraw code than the three methods we have now for PNG?

Certainly ortho would be commonly used; for authoring patterns on complex shapes, you'd most often be working from orthogonal photos. (Technically a perspective method should be used, but the effect is so minimal at ldu scale…)

At one time I was thinking that you could project onto a primitive surface by using its filename as an input parameter. But I'm not sure that makes sense technically (all the prims eventually boil down to planar, cylindrical or spherical anyway).

- Texture resolution (pixels per LDU=> probably best as an internal setting or render quality depended).

Should be determined by current screen resolution/viewbox, although this could be governed by render quality user settings in the tool.

- Lighting settings (probably best to use none)

Can't think of a use for this during the mapping phase (as opposed to final render)?

- Texture background color (probably best to always use 'transparent')

Probably either transparent or main color. Presumably you would not be projecting a background, only the pattern itself. Though setting a background color could have uses for non-pattern projected code.

So imho the whole thing could work using a meta like:

Code:

0 !TEXMAP (START | NEXT) <method> <parameters> <pngfile|ldrawFile> [GLOSSMAP pngfile]

Which would let renderer decide the size of the texture based on the source's min/max x/y coordinates.

or something more flexible:

Code:

0 !TEXMAP (START | NEXT) <method> <parameters> <pngfile|ldrawFile> [GLOSSMAP pngfile] [SURFACE W H ofsX ofsY]

Where the ldraw source x/y coordinates will be added to ofsX,ofsY within a base surface of WxH (ldu). This could be applied to png's too but using pixels instead of ldu.

How is the size determined currently for png? Is there a need to add the scalability option? (I might call it "SIZE" rather than "SURFACE", as to me that suggests material/finish settings rather than dimensions.)

[Roland Melkert]

I'm a little ignorant on this side of things. What projection info is needed that's different for LDraw code than the three methods we have now for PNG?

The projection the texture meta mentions is about how to map the image to the target polygons.
The projection I mentioned is about how the LDRaw geometry is 'projected' onto the texture image itself.
PNG's don't have that step as they're already image data.

Should be determined by current screen resolution/viewbox, although this could be governed by render quality user settings in the tool.

Zoom level details is usually done through mip mapping, the resolution I mentioned is about how big the 'master' image will be internally.
Looking at some official texture for mini-fig faces (which are actual quit low res) 10pix/ldu seems like a decent starting point.

How is the size determined currently for png? Is there a need to add the scalability option?

Don't know, like mentioned above the ones for minifig faces seem very low res to me.

[N. W. Perry]

The projection the texture meta mentions is about how to map the image to the target polygons.
The projection I mentioned is about how the LDRaw geometry is 'projected' onto the texture image itself.
PNG's don't have that step as they're already image data.

OK, that's what I guessed. I can't think of a reason this would be anything other than orthographic, but maybe there is one.

Zoom level details is usually done through mip mapping, the resolution I mentioned is about how big the 'master' image will be internally.
Looking at some official texture for mini-fig faces (which are actual quit low res) 10pix/ldu seems like a decent starting point.

A good starting point, yes. Maybe the spec needs to set a minimum resolution, but as LDraw is a vector format I would leave it open-ended, as the resolution is effectively limited only by memory I guess. Some programs probably have a practical limit already built in.

[Travis Cobbs]

Using a PNG this way would not give the same results, as you'd be locked into the resolution of that PNG file before you even start the program. Projected LDraw geometry would be rasterized at the other end of the pipeline, taking into account the current view/zoom level, plus maybe user settings, etc. More scalable without increasing file size.

Maybe Roland will be rendering on the fly based on things like that, but if this goes through, I expect LDView to render the texture at file load time. Also, I don't think that rendering to texture each frame based on projected size would be performant, although I could be wrong about that.

Would authors use it? I sure would. Being able to author a flat pattern and have it projected with all the crispness of LDraw geometry onto a cylindrical or spherical part, without messing up the smoothness of that curvature—or onto something much more complex, like a Muppet head or a sheep or something? I currently consider that beyond my skill level, but the projection method seems accessible to me. My feeling is that it will encourage other, less experienced part authors to try their hand at pattern authoring.

As mentioned above, I really don't think that it's going to be equivalent to the original geometry, because I don't think it's going to be rendered to a texture each frame. It will allow for flat LDraw geometry to be projected onto arbitrary surfaces, but that will happen as a texture.

But besides what authors want, keep in mind that it benefits the reviewing and spec side of things, too. We've kind of set the standard (and rightly so, I think) that PNG textures aren't ideal for most patterns, but we also don't hold parts solely for being texmapped (and also rightly so, I think). This creates an extra workload down the line, as authors feel the need to re-takeup a texmapped part to vectorize the pattern. Being able to have patterns done the "right" way the first time, and more easily and with better results that the current method, has got to be worthwhile.

It could be me, but I think that you are overly optimistic about what this is going to look like at runtime. To me, it's just going to be a texture in a different format, but it seems like you think it is going to magically produce full vector-quality output at runtime. Maybe I'm missing something, and maybe Roland plans to implement it the way that you are expecting, but if so, I totally misunderstood the whole thread. Roland, are you expecting the flat LDraw geometry to get projected onto the target geometry, or are you planning to render to texture and then project that? And if the latter, are you rendering to texture at load time or at draw time?

It does also have the potential to greatly simplify the library; if the concept proves successful, it could obviate the need for the entire category of patterned parts. All you need would be a collection of pattern files, and the base parts to project them onto.

And, don't forget the possible benefits to non-patterned parts as well. If projected LDraw code can solve some of the more irksome rendering anomalies we currently have, it's certainly worth implementing.

The same could be done with the existing PNG textures. Remember, the suggested change is to allow LDraw files to be used in place of PNG files. Everything else stays the same.

[Travis Cobbs]

Besides the things mentioned above generating a texture on the go also opens the door to custom shaders using the original ldraw color codes (instead of translated rgba) at a pixel level. 

Such a shader could apply different material characteristics to the same surface allowing for things like metallic high lights etc.

This is besides it using the current draw palette instead of hardcoded rgba values.

Unlike my reply above, this is a definite advantage over PNG textures. And while I definitely won't use it to implement the requested but missing gloss maps initially, I assume that it could be done using the color information we have from ldconfig.ldr.

[N. W. Perry]

It could be me, but I think that you are overly optimistic about what this is going to look like at runtime. To me, it's just going to be a texture in a different format, but it seems like you think it is going to magically produce full vector-quality output at runtime. Maybe I'm missing something, and maybe Roland plans to implement it the way that you are expecting, but if so, I totally misunderstood the whole thread.

Mostly true, except for the magically part—LDView and other programs already produce beautiful vector-quality output from LDraw code, so my expectation was something similar, but with the added ability to project flat LDRaw geometry onto a different surface. (Again, this is something already possible with existing tools, just not at render time in an LDraw viewer.)

Unfortunately, I don't know enough about the topic to understand the mechanics of how this is done, but since it combines already-extant capabilities, just perhaps in a different order, it didn't occur to me to be technically insurmountable. Perhaps that's not the case, in which case that's just the sort of feedback I'm hoping for with this discussion.

It's also likely that different programs can accomplish this in different ways, and that the specification itself wouldn't dictate the method used. It may also be that TEXMAP isn't the right way get this kind of result.

I do agree that improving the current available results should be a motivating goal in making any change to the spec. We should be able to project LDraw-based patterns (insofar as they're seen as superior to PNG-based ones) onto curved or complex surfaces, without "wrinkling" the surface as is currently seen. I think the role of the spec is to open avenues for generating the best possible results; exactly how that's implemented, in my opinion, is left to the wizardry of those of you who actually create the tools.