New meta idea: !COLORMAP

[N. W. Perry]

I was just thinking how, when creating patterned parts, dual molds, assembly shortcuts &c., we need to create separate parts for every color combination. (See for example the many variants of the early named beams, e.g. this one.)

This gave me an idea for a new meta command, which I can only imagine would be no more complicated to implement than, say, the BFC commands. Something like this:

Code:

0 !COLORMAP_NEXT 0 4 15 14

Say you had a pattern with color 0 (black) and color 15 (white), this would re-map those colors to 4 (red) and 14 (yellow), respectively. That way you wouldn't need to author a separate version of that pattern using colors 4 and 14. You also wouldn't need, necessarily, to subpart the pattern into individually-colorable elements. As a result, it would also cut down on the number of library files, to the extent that that's a concern anyway.

Another obvious use would be to create minifig torso and leg assemblies in any conceivable color combination, using just a single shortcut file.

(I assume that "_NEXT" would be the most commonly used scope, so perhaps it could be omitted. But you could also have "_BEGIN" and "_END" variants, allowing you to recolor a whole model in one go.)

Anyway, as I always say I'm no programming expert (nor barely even a novice), so I can't say for sure. But it seems like this would be no more difficult for a parser than flipping the winding of vertices at runtime. And it certainly wouldn't break any existing functionality—you could always create hard-coded versions of any patterns you create this way, either by authoring new parts or by inlining and embedding them (using a sufficiently capable editor of course).  

Thoughts, suggestions? I'd actually be surprised if I were the first to come up with this, so maybe there's a reason it was never considered before…

[Orion Pobursky]

This is kind of the point of color 16 subfiles. If there's a pattern that shares geometry you abstract those parts out into color 16 subfiles and then reuse them in the main file.

[N. W. Perry]

This is kind of the point of color 16 subfiles. If there's a pattern that shares geometry you abstract those parts out into color 16 subfiles and then reuse them in the main file.

Right; this idea would eliminate the need to do so. So, for example, when building a model where the needed color variant doesn't exist, you wouldn't have to author a new part (or wait for others to do so). And, perhaps more usefully, you could use any color combination at any time, regardless of whether it ever saw official release (i.e., there will be no part in the library).

[Roland Melkert]

This gave me an idea for a new meta command..

You could technically do this using the !COLOUR meta.

But I don't think many renderers support it besides setting the global colors using LDConfig.ldr

It is one of the improvements I planned for LDCad 2

[N. W. Perry]

You could technically do this using the !COLOUR meta.

But I don't think many renderers support it besides setting the global colors using LDConfig.ldr

It is one of the improvements I planned for LDCad 2 

Hmm, I didn't think of that. So to do it for just a single part, you'd have to have a !COLOUR meta preceding that part defining new values for that color code, and then another !COLOUR meta immediately after it, identical to the one in the config?

In that case, what about an extension to the !COLOUR meta, canceling any previously-assigned values (and thereby falling back to the config file)?

But then, at that point wouldn't it be just about as easy to have an extension mapping one code to another? (You could almost do this by allowing a color code for the VALUE tag.)

[Roland Melkert]

But then, at that point wouldn't it be just about as easy to have an extension mapping one code to another? (You could almost do this by allowing a color code for the VALUE tag.)

I would prefer some kind of universal push/pop feature, e.g.

!push [name] colour <oldNr> <newNr>

This might also fix some of the buffer exchange short comings when using e.g. subfile instead of colour.

Just some idea floating, this won't be easy to standardise

[N. W. Perry]

I would prefer some kind of universal push/pop feature, e.g.

!push [name] colour <oldNr> <newNr>

This might also fix some of the buffer exchange short comings when using e.g. subfile instead of colour.

Just some idea floating, this won't be easy to standardise

I'm intrigued how this might work with buffer exchange…do you mean that there could be a variety of tags besides color? So you could "push" a pos/ori or a matrix, to show a piece temporarily rotated and/or in a different position?

I wonder if you could "push" a part within a subfile, e.g. to show a hinge rotated within a submodel, but un-rotated if you are editing the submodel itself?