LDraw.org Discussion Forums

Full Version: LICreator - Color parsing problem
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
0x02RRGGBB or 0xRRGGBB = opaque RGB
0x03RRGGBB = transparent RGB
0x04RGBRGB = opaque dither
0x05RGBxxx = transparent dither (xxx is ignored)
0x06xxxRGB = transparent dither (xxx is ignored)
0x07xxxxxx = invisible
I need some one who know how detect corresponded ALPHA value from format above.
Realistically, it could depend on the renderer. Having said that, LDView uses 50% alpha for "transparent" colors. I also completely disable back-face-culling for transparent colors, and (by default) depth sort them. This means that generally any pixel with transparent geometry in it will in fact have at least two layers of transparency (front and back surface) drawn over whatever happens to be behind that. If you don't disable back-face-culling for transparent parts, you'll probably need to make them more opaque.

LDConfig colors can contain an actual alpha value, and LDView respects that. (I think, for example, glow-in-the-dark is mostly opaque, but not quite.)
So if LICreator meet everything except normal color /0x02 , 0x/ should use this 50% /0.5 in float number/ alpha for "transparent" color as default value.
Choosing alpha when model is in import mode, slow down. And any one don't be happy do it again.. and again... and again
until process is finished. Right.
0x3RRGGBB, 0x5RGBxxx, and 0x6xxxRGB should all have alpha of 0.5. 0x7xxxxxx is totally invisible. Please note that 0xRRGGBB does not exist as a color standard. There would be no way to distinguish between standard (non-RGB) colors and colors with 0 for RR and GG.

You might want to look at LDView's color-calculating code here (specifically LDLPalette::getAnyColorInfo). Even if you don't write C++ code, you should be able to interpret the calculations.