(2020-04-30, 17:42)Orion Pobursky Wrote: I disagree with this. I think we should go with the intended color, not the color as it shows on a real part. Part of the appeal of LDraw is that you can use a part in a color that has never produced in real life. Trying to deal with the slight transparency of the ink is a nightmare waiting to happen.
Yeah, I don't remember who opined that; it was somewhere in one of the various standards/guidleines/tutorials that exist out there… Suffice to say, the principle is out there somewhere, so it's guiding at least some people.
I would add, though, that another part of the appeal of LDraw (to me, at least) is that you can replicate the part as it looks in real life. And yet another part of the appeal is that it's comprehensible and flexible enough that you could, in fact, have both. So to me, it doesn't have to be an exclusive choice—the ideal solution would be one that allows both a faithful representation of the real part, and the ability to extend the palette.
Quote:Actually, I don't think this is "our" problem. An intrepid developer could, in fact, have this transparency in their renderer if they wanted and us doing anything other than the intended color would mess this up.
Yes, something just like that is what would probably be the ultimate solution. You'd encode the pattern with the intended color (assuming you could determine it), and then somebody would add a transparency parameter that governs how that color interacts with the underlying base color. I'll let others hash out who that somebody ought to be…I know that we do have some material definitions that include parameters (like speckle and transparent parts), but I also know that many of LDraw's most powerful extensions have been those brought in by developers.