Part color issue


Part color issue
#1
4150p02.dat
Tile  2 x  2 Round with Pizza Pattern


This part calls for color 354, but there is not such color in ldconfig.ldr. Does the part need to be fixed?

[edit]

Never mind. I see it in the parts tracker already. What is the closest official color to dithered color #354?
Reply
RE: Part color issue
#2
(2018-03-02, 1:09)Michael Horvath Wrote: 4150p02.dat
Tile  2 x  2 Round with Pizza Pattern


This part calls for color 354, but there is not such color in ldconfig.ldr. Does the part need to be fixed?

[edit]

Never mind. I see it in the parts tracker already. What is the closest official color to dithered color #354?

Remember that patterned parts can use RGB colors. I would argue that it's better to match the original printed color than to find an official LDConfig color that comes close.
Reply
RE: Part color issue
#3
(2018-03-02, 2:17)Travis Cobbs Wrote:
(2018-03-02, 1:09)Michael Horvath Wrote: 4150p02.dat
Tile  2 x  2 Round with Pizza Pattern


This part calls for color 354, but there is not such color in ldconfig.ldr. Does the part need to be fixed?

[edit]

Never mind. I see it in the parts tracker already. What is the closest official color to dithered color #354?

Remember that patterned parts can use RGB colors. I would argue that it's better to match the original printed color than to find an official LDConfig color that comes close.

I did not realize LDraw parts could have RGB colors defined in them. Thanks.
Reply
RE: Part color issue
#4
(2018-03-02, 3:44)Michael Horvath Wrote: I did not realize LDraw parts could have RGB colors defined in them. Thanks.

Only the patterns of patterned parts and stickers are allowed to use RGB colors.
Reply
RE: Part color issue
#5
(2018-03-02, 5:50)Travis Cobbs Wrote:
(2018-03-02, 3:44)Michael Horvath Wrote: I did not realize LDraw parts could have RGB colors defined in them. Thanks.

Only the patterns of patterned parts and stickers are allowed to use RGB colors.

I still need to know what some good approximations are for my non-patterned models.
Reply
RE: Part color issue
#6
(2018-03-03, 7:38)Michael Horvath Wrote: I still need to know what some good approximations are for my non-patterned models.

color 354 is dithered from 6 and 2, so just take the rgb's of those and average them.
Reply
RE: Part color issue
#7
(2018-03-03, 18:16)Roland Melkert Wrote:
(2018-03-03, 7:38)Michael Horvath Wrote: I still need to know what some good approximations are for my non-patterned models.

color 354 is dithered from 6 and 2, so just take the rgb's of those and average them.

Is there a list of these colors somewhere? I need to fix a lot of submodels.
Reply
RE: Part color issue
#8
(2018-03-03, 19:22)Michael Horvath Wrote:
(2018-03-03, 18:16)Roland Melkert Wrote: color 354 is dithered from 6 and 2, so just take the rgb's of those and average them.

Is there a list of these colors somewhere? I need to fix a lot of submodels.

Everythign between 256 and 511 without an entry in ldconfig is a dithered color.

354-256=98
98 div 16 = 6
98 mod 16 = 2

6 and 2 are in ldconfig
Reply
RE: Part color issue
#9
(2018-03-03, 19:28)Roland Melkert Wrote:
(2018-03-03, 19:22)Michael Horvath Wrote: Is there a list of these colors somewhere? I need to fix a lot of submodels.

Everythign between 256 and 511 without an entry in ldconfig is a dithered color.

354-256=98
98 div 16 = 6
98 mod 16 = 2

6 and 2 are in ldconfig

So, this calculation holds true for all unnamed colors, dating back to many years ago?

Also, is there a full list somewhere I can look at? I want to anticipate future problems.
Reply
RE: Part color issue
#10
(2018-03-04, 22:41)Michael Horvath Wrote: So, this calculation holds true for all unnamed colors, dating back to many years ago?

Also, is there a full list somewhere I can look at? I want to anticipate future problems.

I'm not exactly sure what you mean by "all unnamed colors", or what you mean by a full list. The calculation holds for all color numbers between 256 and 511.

In James Jessiman's LDRAW.EXE, all colors from 256 to 511 were "dither colors". They were called that because they used a 50/50 checkerboard dither pattern, where one color number in the pattern was computed using (color - 256) / 16 (truncated), and the other was computed using (color - 256) mod 16. (Note that 16 of these dither patterns exactly match the color numbers from 0 to 15, since both colors in the dither pattern are the same, and half of them are nearly indistinguishable from the other half, since simply swapping the two colors in the checkerboard pattern is something that is difficult to see visually.)

When I originally wrote LDView (in 2000), I simply calculated the average of the two colors instead of displaying a dither pattern, since the dithering was really an artifact of the fact that LDRAW.EXE was program that was only capable of displaying 16 colors. I don't remember if LDView was the first program to do this, or if I copied the behavior from some other program. (It doesn't really matter.) Most (if not all) LDraw-compatible programs behave this way now.

Later on, other color standards were introduced. For reasons that I never have understood, one early standard was 12-bit dither colors. These were dithers of two different 12-bit colors, and they look like this in hexadecimal: 0x4RGBRGB. They also have transparent versions: 0x5RGBxxx, 0x6xxxRGB, and 0x7xxxxxx (where x is ignored, but considered to be 100% transparent). (Yes, if you use any color number from 0x7000000 through 0x7FFFFFF, you get a completely invisible color.)

Finally, true RGB colors were added: 0x2RRGGBB for opaque and 0x3RRGGBB for transparent, where transparent means "LEGO transparent", or about 50% transparent. These RGB colors are what are allowed in the pattern portions of pattern and sticker parts.

When LDConfig was first created, it was decided that new colors would use the number from the closest available dither color. This (hopefully) explains the seemingly odd nature many of the LDConfig color numbers, and why those numbers are so patchy.
Reply
RE: Part color issue
#11
(2018-03-05, 3:32)Travis Cobbs Wrote:
(2018-03-04, 22:41)Michael Horvath Wrote: So, this calculation holds true for all unnamed colors, dating back to many years ago?

Also, is there a full list somewhere I can look at? I want to anticipate future problems.

I'm not exactly sure what you mean by "all unnamed colors", or what you mean by a full list. The calculation holds for all color numbers between 256 and 511.

In James Jessiman's LDRAW.EXE, all colors from 256 to 511 were "dither colors". They were called that because they used a 50/50 checkerboard dither pattern, where one color number in the pattern was computed using (color - 256) / 16 (truncated), and the other was computed using (color - 256) mod 16. (Note that 16 of these dither patterns exactly match the color numbers from 0 to 15, since both colors in the dither pattern are the same, and half of them are nearly indistinguishable from the other half, since simply swapping the two colors in the checkerboard pattern is something that is difficult to see visually.)

When I originally wrote LDView (in 2000), I simply calculated the average of the two colors instead of displaying a dither pattern, since the dithering was really an artifact of the fact that LDRAW.EXE was program that was only capable of displaying 16 colors. I don't remember if LDView was the first program to do this, or if I copied the behavior from some other program. (It doesn't really matter.) Most (if not all) LDraw-compatible programs behave this way now.

Later on, other color standards were introduced. For reasons that I never have understood, one early standard was 12-bit dither colors. These were dithers of two different 12-bit colors, and they look like this in hexadecimal: 0x4RGBRGB. They also have transparent versions: 0x5RGBxxx, 0x6xxxRGB, and 0x7xxxxxx (where x is ignored, but considered to be 100% transparent). (Yes, if you use any color number from 0x7000000 through 0x7FFFFFF, you get a completely invisible color.)

Finally, true RGB colors were added: 0x2RRGGBB for opaque and 0x3RRGGBB for transparent, where transparent means "LEGO transparent", or about 50% transparent. These RGB colors are what are allowed in the pattern portions of pattern and sticker parts.

When LDConfig was first created, it was decided that new colors would use the number from the closest available dither color. This (hopefully) explains the seemingly odd nature many of the LDConfig color numbers, and why those numbers are so patchy.

I'm not sure what to do in POV-Ray when I encounter these colors in a model. Somehow build variable names and convert them to declarations?

[edit]

Never mind. The correct solution is to change the colors to legal values in MLCad. And download replacement parts from the parts tracker.
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)
Forum Jump:


Users browsing this thread: 1 Guest(s)