Modelling patterns that depend on the underlying part colour

[Chris Dee]

An issue has arisen on the Parts Tracker that I think deserves wider discussion than is possible there.

By convention, we only model the printed colours of patterns and use colour 16 for any unprinted areas. This allows the base part colour to "show through" when rendered. Although this is exactly what would happen if LEGO were to print the pattern on another colour of part, there is an argument that in some cases we are restricting the usability of the LDraw library by doing this.

The Fire Logo Pattern has caused most concern. By leaving the unprinted left-hand flame as colour 16, the LDraw part files that use this can only really be used in red. The second example is the Slope Brick 45 2 x 2 with Gauge Pattern, which is normally printed on black and uses the base part colour to create some of the detail. The potential benefit is shown in this rendering by Magnus Forsberg - left image = "desired" rendering on green; centre image = actual pattern on black"; right image = actual pattern on green.

I can see that the case is clear for the Fire Logo - the left flame was always intended to be red. For other patterns, including the Gauge Pattern, we would need to guess about the intent of the pattern designer. That guesswork makes it very difficult to apply any consistency, and potentially generates more controversy than the current discussion, as the implementation will depend on each person's interpretation of the design intent. The benefit of the current solution is that it is totally unambiguous, but I fear we are applying rules for their own sake and denying rendering opportunities to the users of the LDraw parts library.

For now I have certified these patterns and their parent parts as they now fit with the current convention. However, I would welcome further discussion, opinions and potential solutions.

[Tim Gould]

Hi Chris,

Thanks for raising this here.

I think that a caveat could be added along the lines of:

Under exceptional circumstances a background colour may be hardcoded as a fixed colour, either in an original submission or resubmission, if the intended colour seems clear to the author. A note should be added with the submission stating that this has been done and the reason for the hardcoding. In the event that any reviewer places a 'hold' for this decision the part should revert to the usual standard for reviewing.

This way the original author has a chance to make a judgement, and if it is agreed upon universally by the reviewers it will go in and common sense prevails. But if a situation is ambiguous enough for one person to 'hold' then it reverts to the unambiguous standard.

I actually agree with both Magnus and Steffen for the examples.

Tim

[Steffen]

as already said on the PT, for the fire logo we definetely lose flexibility when using color 16 for the red flame.

doing that means that that file can only be used in color red to look correct, and that renders
the color 16 usage of that file so useless as if it hadn't been used at all (and everything would have been hardcoded to red).

in the ldraw library we always have followed the principle to allow people to colorize their parts
as they like, even if a real LEGO part of that does not exist. this is one very nice thing of our library.

when applying my suggested solution to the fire logo, both sides get happy:
- the folks insisting on that it must only be used in red can do so and will exactly get what they want
- people coloring it differently can put the fire logo even onto an e.g. green or blue brick. that otherwise would not be possible.

I in this case simply think that our rules can not cover each and every case,
and that the fire logo well deserves an exception.

As for the gauges, I'll be happy with both solutions, using color 16 or not,
since I have not really made up my mind if the black portions there are such an important
part of the pattern that they cannot be color 16. Magnus sees it that way, and I tend to follow him.

[Philippe Hurbain]

I also tend to prefer pattern with hard-coded color as it offers more flexibility to use with othre color background.

[Rolf Osterthun]

Hey,

I am not that active like you, but I would like to give some thoughts.

There is more than one official Space Police series out there. I could imagine that one day there could be a Space Fire Brigade with different colors than the terrestrial. Even the flame could have a different color. Or there could be a Hazardous Material Fire Brigade. Environmental pollution may become a theme .

The statement by Steffen

in the ldraw library we always have followed the principle to allow people to colorize their parts
as they like, even if a real LEGO part of that does not exist. this is one very nice thing of our library.

is new to me, but as mentioned: I am not that active. I thought that such parts are custom parts. Could you give me an example?

And I think that the discussed parts will become custom parts too, when you set the colors hard coded. What will happen if LEGO decides to pattern a blue brick with a red flame? Would this be a new design number? What will happen if LEGO decides to put a green flame on a green brick? Change the hard coded part; create another hard coded part?

There was a time where the LDD only provided parts that were produced (or at least were on sale) at that time. And I hated it. LDraw is much more flexible and I like it for this.

What is the goal of the LDraw parts library? Providing all official LEGO parts? Providing only official LEGO parts? May it contain custom parts?

Plese remember: This are only some thoughts.

Rolf

[Chris Dee]

What is the goal of the LDraw parts library? Providing all official LEGO parts? Providing only official LEGO parts? May it contain custom parts?

To provide only official LEGO Part Shapes, but allow them to be rendered in any colour, including non-issued colours. The library will not include custom shapes, but by rendering a patterned part in a different colour you can obviously generate something that was not issued by LEGO.

[Rolf Osterthun]

To provide only official LEGO Part Shapes, but allow them to be rendered in any colour, including non-issued colours. The library will not include custom shapes, but by rendering a patterned part in a different colour you can obviously generate something that was not issued by LEGO.

Thats is absolutely understandable. For shapes this is a good final answer. But it is no answer for patterns, is it? If you handle them the same, color 16 would be the right choice for the discussed parts. Otherwise: May I submit the attached part to the parts tracker (don't worry! I won't)? It is an official LEGO Part Shape, but it is precolored (patterned) in a way it does not exist physically (it is used in the computer game LEGO Pirates of the Caribbean, so it could even perhaps treated as an official LEGO part ). I think this is a custom pattern.

My achivements giude exactly to the initial statement:

By convention, we only model the printed colours of patterns and use colour 16 for any unprinted areas.

And my opinion is that we should keep the convention.

Rolf

[Tim Gould]

But under what Chris is suggesting this part would stay the same. There is absolutely no reason to assume that the white checks are meant to remain white under variants so would be coded at 16.

Tim

[Steffen]

Rolf, that part that you've attached to your post has nothing to do with our discussion here:
we're not talking about parts where it is obvious that parts of the pattern need to be color 16.
we're just talking about a very small set of parts where the pattern contains portion
which only make sense in 1 specific color, like the red portion of the fire pattern.
and yes, I am talking of that classic fire pattern, not some sci-fi "green flame fire pattern" etc.
just the modeling of the classic fire logo, which is the file mentioned above.
it carries no other semantics.
in the currently present color 16 modeling of it, that pattern file only can be used when referenced by an instruction
which sets it to red. so the whole versatility gained by using color 16 at all is spoiled.
all the effort of using color 16 in it in fact currently makes no sense, since you are anyway forced to use the file in red only.
then we could have hardcoded it in red as well - no difference.
my point is that by using color 16 for the outside 4 ndis's, and hardcoded red for the flame portion,
the pattern can be used on any background color freely.
and that degree of freedom is what I want to achieve.
just versatility of our library.


see the attached images for examples (rename to *.png)

[Damien Roux]

I will also give my opinion as I was the one who created the part that raised the problem.

I think we should virtually separate (without thinking about printed colors or not printed ones) the part.
on one hand there is the pattern with should be entirely hardcore and on the other hand there is the part it self which should have a color16.

It has a gauge pattern, right. In my mind the gauge is the entire gauge, not only a part of it based on some colors. Just imagine the pattern is a sticker which has to give the same image whatever the part it is sticked on.

If someone, choose another color for the part, it must still look like a gauge pattern and not like "an almost complete gauge pattern".

[Chris Dee]

I understand that. However, it is still a matter of personal judgement as to which areas of the "pattern" were designed to be the colour of the one part on which it was issued. Different people will potentially have different opinions. I'd rather not have to moderate that discussion for every patterned part that gets developed. For example with the gauge pattern, someone could quite justifiably challenge that they believe that entire background was "supposed to be" black.

I moved this discussion from the Parts Tracker to this forum in the hope that we might get some input from people who have not been quite so personally involved so far (i.e. the user community, rather then the author community). I think that we are still guessing what the users real needs are, which is never a good situation for software development.

[Steffen]

independently from the gauge pattern, I think that for the fire logo pattern, the situation is clear,
and we are ready to take action there: let's code the flame in red, please

[Rolf Osterthun]

Hey Steffen,

Rolf, that part that you've attached to your post has nothing to do with our discussion here:
we're not talking about parts where it is obvious that parts of the pattern need to be color 16.
we're just talking about a very small set of parts where the pattern contains portion
which only make sense in 1 specific color, like the red portion of the fire pattern.

I attached this part only to clarify my position. It was only an example to emphasize that a pattered part that does not exist in real should not be submitted to the parts tracker. And my oppinion was, that the hard coloring of the red portion of the fire pattern makes that part a custom patterned part.

my point is that by using color 16 for the outside 4 ndis's, and hardcoded red for the flame portion,
the pattern can be used on any background color freely.
and that degree of freedom is what I want to achieve.
just versatility of our library.

At the one hand you wish to use the part in all colors with a red flame. At the other hand you refuse me to use this part for a sci-fi model. Versatility with restrictions? Please don't take the "you" personally!

and yes, I am talking of that classic fire pattern, not some sci-fi "green flame fire pattern" etc.
just the modeling of the classic fire logo, which is the file mentioned above.
it carries no other semantics.

Looks like LEGO did not only created a "classic fire pattern". Should there be a "classic fire pattern" and a neutral "fire pattern"? There are some parts that needs the fire pattern with a hardcoded red for the flame portion (e.g. 2493c02pb01, 2494pb07, (4346p01; looks different)). This might be a basis where we could build up a definition for an acceptable exception to the convention (clear part with red flame guides to red flame even if not printed).

This is only my opinion. And my opinion is that we should keep the convention.

Rolf

[Tim Gould]

Hi Rolf,

If the fire pattern had appeared on a black door what colour would the flame look like? That is the relavent question for that part. My opinion that the answer is it would have a red flame. Do you think it would have black flame or red?

If the flag piece had appeared in blue would the white patches have remained white? My opinion is no, as is yours.

For most patterns the part we code as 16 could take any value depending on what it is placed on. Here the current standard applies and is right. For a small minority of patterns (eg. the flame quite clearly and gauge arguably) it seems much more likely that the colour would have been hardcoded had the pattern appeared on a different background colour.

Tim

[Rolf Osterthun]

Hey,

I am sorry but english is not my native language. So some of my statements might be confusing?

If the fire pattern had appeared on a black door what colour would the flame look like? That is the relavent question for that part. My opinion that the answer is it would have a red flame. Do you think it would have black flame or red?

The fire pattern appeared on a transparent window (2494pb07). And the flame IS red. By this LEGO shows that the flame is intended to be red. For the red parts with the fire pattern they just saved the red printer color. Out of this there could be made a clear definition if a color should be hard coded or not.

When there will be such a definition, I think it is absolutely ok to color the flame red. I have changed my mind on the red flame after my research showed up the window. If I hadn't found the window, my opinion would still be that (in your example) the color of the flame should be black.

This is only one part. But there might be more and I think there should be a clear definition in the convention if a color should be hard coded or not. I do not like the idea of the "personal judgement". Not for the authors and not for the reviewers.

The next part is the part with the gauge pattern. LEGO never printed this pattern on a different color. So we do not know the intention of the designer. My oppinion is that due to this the black areas should be colored in main color.

Rolf

[Steffen]

the transparent part you mentioned, 2494pb07,
http://bricks.argz.com/bricksfiles/image...94pb07.png
http://www.piipoo.com/product_details.php?p=9632
uses the "fire logo shield" pattern,
http://www.ldraw.org/cgi-bin/ptdetail.cg...9p70s2.dat
There, the flame is still hardcoded red, which I consider being a Good Thing ™.

I suggest to do it the same way at
http://www.ldraw.org/cgi-bin/ptdetail.cg...209s01.dat

[Chris Dee]

I think we have given everyone ample time to post alternative views and discussion on this topic has dried up.

In the case of the Fire Logo I agree that the strong evidence from the transparent parts is that the left-hand flame was intended to be red.

So I support a change to that subpart.

To my mind the intention for the gauge pattern is much less obvious.

[Steffen]

I would like to do that change now, if you allow,
i.e., I would like to adjust
http://www.ldraw.org/cgi-bin/ptdetail.cg...209s01.dat
so that its implementation becomes similar to what
http://www.ldraw.org/cgi-bin/ptdetail.cg...9p70s2.dat
does.

You can have a look at
http://www.ldraw.org/cgi-bin/ptdetail.cg...209p70.dat
to see how beneficial that will be.

Objections?

PS: yes, agreeeing with you Chris regarding the gauge pattern, but let us do it step by step and first fix this one where things are clear IMHO

[Chris Dee]

Agreed.