Could stickers be mapped instead of formed?

[N. W. Perry]

Just thinking of an extension to the idea discussed here…

…if LDraw code could indeed be mapped onto a surface the way bitmap images currently are, could you conceivably map an entire part onto a surface?

You see where I'm going with this—could a sticker part be authored only in its flat form, and then, when needed to be placed on a non-planar surface, could that flat part file be automatically transformed (along with its proper thickness) and applied as part of the rendering process?

Is such behavior even desirable? Or maybe the better question is, would the programming effort required to implement this outweigh the need to author formed versions of all non-flat stickers?

[Gerald Lasser]

I think this would involve a considerable amount of code within the viewers and editors. Like TEXMAP for LDraw code.

I had the thought over the cases where primitive substitution is carried out and after that the hi-res prim cuts into the sticker...

[N. W. Perry]

I think this would involve a considerable amount of code within the viewers and editors. Like TEXMAP for LDraw code.

Exactly, that was the basic genesis of the idea:

I was wondering about the usefulness of using normal type 1..4 lines to describe the pattern which a renderer can use to generate a texture. 

This would work much like embeded textures but instead of !DATA it uses normal ldraw code which must be 2d and flat.

I had the thought over the cases where primitive substitution is carried out and after that the hi-res prim cuts into the sticker...

Good point, you'd have to account for primsub both in the sticker pattern and the target part. I think it would just be a matter of doing the substitution first, before calculating all vertices, but perhaps you'd also need some regulations as to the allowable geometry of sticker patterns.

The trickiest part seems to be getting the proper 0.25 LDU thickness. But I think you would just ignore the stickerback geometry altogether; you'd just project the flat pattern surface directly onto the target part, generate a perimeter from that, and then translate the pattern surface 0.25 ldu on its own relative y-axis normal.

In other words, it would be the same process of creating a (printed) pattern by projecting LDraw code onto other LDraw code, just with the added step of building up the sticker thickness.

[Magnus Forsberg]

Sounds like Lasses PatternFolder  
https://c-mt.dk/

Long time since I played around with it

[N. W. Perry]

Sounds like Lasses PatternFolder  
https://c-mt.dk/

Long time since I played around with it

Uhhh…you're right! I've seen this too, but clearly didn't remember it!

There's also SVG to LDraw, another functionality I've been seeking.

Clearly a long time since I played with these, too!

[Roland Melkert]

Exactly, that was the basic genesis of the idea:

Actually I don't think this is hard to do if an editor already supports the !TEXMAP (and !DATA) extension(s).

It just needs to project the ldraw code onto a texture, something all major rendering api's have tools for.

Spec wise it would only need for !TEXTURE to allow normal ldraw references (besides png ones) and a fixed projection definition (ortho?).

[Chris Böhnke]

Would be awesome if that is possible 

Regarding formed sticker thickness (which seems to be an issue for some, if I read this right):

I found that Blender provides a (moderately) simple and reliable way to offset any 3D formed surface perfectly rectangular (you can also set it to exactly 0.25 LDU). It requires a bit back-and-forth in converting your files though, but there's barely any knowledge required and it's free.

[N. W. Perry]

If LDraw code can be mapped onto a surface, it could have uses other than just patterns. You could use it e.g. to fix the bottom of 3941, where the stud notches don't fit into a fractional cylinder prim, so they show as flat spots when a hi-res cylinder is subbed in. Instead, you could project the entire bottom edge onto an underlying (invisible) full-cylinder primitive.

In fact, if LDraw code can be mapped onto geometric surfaces, then patterns (printed or sticker), as well as non-pattern geometry, could be mapped onto entire base parts, potentially making pattern and sticker parts obsolete. Patterns could exist in the library as a separate type of element, and by using established mapping parameters, could be applied at the model level to any base part. Library entries for patterned/sticker parts could exist simply of a correlation file referencing the base part, the pattern element, and the appropriate mapping parameters to represent official parts.

[Peter Grass]

I don't really get why texture maps aren't used for stickers in the first place? I mean back when the stickers weren't available as PNG's in BI and people were using potato quality JPGs and low quality sticker scans I could see the point but now its just creating extra work for not really much benefit in quality.

That would free up so much time and trouble and BI already has formed sticker models for placing the textures on including the curved slopes and whatnot. Although some of those curves don't of course match the tracker versions of the parts but just making standard formed versions everyone can put their textures on would be far easier.

You can make 100 textured parts in the time it takes to make 1 polygon decorated part.

I can see the point of continuing making the more complicated designs as polygons but not things for flat surfaces.

[Chris Böhnke]

I don't really get why texture maps aren't used for stickers in the first place?

One argument that comes to my mind really quick is metallic colours.

Use of metallics (gold, silver, blue, pink, titanium, copper) on stickers has increased a lot these days when compared to pre 2010 (I might be looking a bit too much on the Icons/UCS sets here, but I guess Ninjago and Friends in particular are also very keen on these).

When using texmaps, the render doesn't get reflection info (amongst other things) so the end result will likely look less "impressive" when done in a higher quality rendering.

Of cause you could "edit out" these areas and fill them in with the proper LDraw colour, but then it's not the quick work flow you are aiming for anyways.

EDIT:
Other issues I see:
*Colour Mismatch - For certain stickers it is common to match the base part's colour around the outer areas. This often poorly achieved on un-altered scans/BIA-files (see https://library.ldraw.org/parts/32072). Not long ago, there was a discussion about edge colours on sticker shortcuts with the result that people preferred a "it looks like a print" look; using more and more raw texmaps will likely work against this desire
*Innaccuracies - Some of the BIA textures might be early designs/prototypes that poorly reflect the real image
*Minor Issues - Stud.io compatibility (maybe other programs too?), copyright issues, file handling (embedded single-file vector .dat vs base .dat + texmap)

[N. W. Perry]

Scalability is another factor. There are enough tools already in existence (or nearly so) that it should be within reach to enjoy the higher quality of vector imagery (such as SVG or LDraw code) for those patterns that would benefit (such as text-based decorations).

We can already:

• convert a bitmap source image to SVG (via Inkscape)
  
• convert a bitmap source image to LDraw (via img4dat, which also has planned support for SVG)
  
• convert SVG to LDraw (via svg2ldraw and 1 or 2 others)
  

We think we can soon:

• project LDraw geometry onto LDraw geometry (via an expansion of the TEXMAP spec)
  

So given a source PNG, yes we can already put that right into TEXMAP (and for certain images, that's preferable anyway), but we're not all that far from being able to take one or two largely automated steps to go to something more scalable and with better resolution. We could also add additional functionality, like selective color replacement (as part of the mapping protocol) so that redundant patterns need not be made simply because they differ in color.

The above tools still need refinement, to be sure, but that doesn't preclude thinking about what the necessary spec should be.