 | | Re: "Dither" colors in patterned/sticker parts
|
|
(...) DOH! I forgot to include -- Part of the reason I think RGB colors are not the way to go is because they don't solve the real problem -- there are a good number of patterns that can't realistically be modeled in LDraw. Anything with gradients, (...) (15 years ago, 10-Feb-10, to lugnet.cad.dat.parts)
|
| |
| | Re: "Dither" colors in patterned/sticker parts
|
|
(...) Steve, our opposing positions on RGBs are known. What I seek in this very moment is your position on the second question in this post: (URL) "No password, not a single CA-header edit on your agenda nor a library update since ... was it 2004 or (...) (15 years ago, 10-Feb-10, to lugnet.cad.dat.parts)
|
| |
| | Re: *** MLCad V3.30 ***
|
|
(...) I can confirm that. While the LSC may have dithered over the spec, we certainly didn't drop "dither" intentionally. (Mind you, given the number of referenced specs we had to ratify first before we could get onto "the biggie", I'm surprised we (...) (15 years ago, 10-Feb-10, to lugnet.cad.mlcad)
|
| |
| | Re: "Dither" colors in patterned/sticker parts
|
|
(...) Not sure where you're going with that. I think adding RGB colors to official parts would not be a net improvement to the parts library system. It has nothing to do with backwards compatibility or conservatism. Steve (15 years ago, 10-Feb-10, to lugnet.cad.dat.parts)
|
| |
| | Re: *** MLCad V3.30 ***
|
|
(...) I think Travis' wording may be confusing. Don't use "the old dither algorithm". MLCad 3.30 draws colors 256-511 as *solid* colors. That's better than using the stippling algorithm from previous MLCad versions. (No new/current software stipples (...) (15 years ago, 10-Feb-10, to lugnet.cad.mlcad)
|
