 | | | | | | |
| |
|
Hi folks,
working on and off for almost a year with Scott Wardlaw, Alex Taylor and with
the help from Joshua Delahunty we put together a new LDConfig file which
hopefully fills in where the old version failed:
http://news.lugnet.com/cad/?n=15477&t=i&v=a
The file has the following characteristics:
* 100% backwards compatible with the old LDConfig.ldr file
http://www.ldraw.org/library/official/ldconfig.ldr
* Uses LEGO RGB values
* Uses LEGO numbering where possible
* Lists the matched LEGO name
* Uses Bricklink names
* Contains all colors currently listed at Bricklink
* Colors are listed in alphabetical order
* New color definitions for "Glitter" and "Speckle" as defined by the LSC
The following sources have been used to create the file:
New RGB Shadow color values provided by the LEGO Group
http://www.ldraw.org/Article93.html
http://www.peeron.com/cgi-bin/invcgis/colorguide.cgi
http://www.bricklink.com/catalogColors.asp?v=0&itemType=P&itemNo=
http://alumni.cse.ucsc.edu/~dulcaoin/LEGO/LEGO-Color-Chart.pdf
http://www.isodomos.com/ColorTree
http://www.peeron.com/cgi-bin/invcgis/colorguide.cgi
A beta version of the file can be found at:
http://www.holly-wood.it/tmp/LDConfig.ldr
while a Wiki version showing also the colors is stored at:
http://www.ldraw.org/wiki/index.php/LDConfig.ldr
Before going public we have asked some programmers for feedback. Most concerns
were rose about the transparent color values. Be sure we used the Shadow colors
provided by the LEGO Group. Shadow colors are not the RGB values used for the
molds but are representations of those colors used in the company's system.
Question is:
Shall we restore the historical LDraw colors for the range from 0 to 50 since
the new colors look unnatural and washed out? This has to discussed before we
officially ship the new file with the 02-2009 parts update.
Another issue is consistency. While some programs of the LDraw System of Tools
already support the LDConfig.ldr file and use it instead of an inbuild color
system some don't. In order to keep the colors consistent throughout the LDraw
System of Tools it would be desirable to have all programs switch to the
LDConfig file.
In no way we are going to allowed that progs set a new color as it has happened
in the past:
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/30367ps1.dat
We also encourage a switch from the current sorting on numbers to an
alphabetical order of the colors (perfect would be to leave the choice to the
user). You'll also find a list with the original TGL numbers moved to a 3xxxx
range. In no way have the TGL numbers to be mixed with LDraw colors. Also the
comments where we matched the TLG numbers to LDraw colors should be hidden from
the final user.
Comments and feedback are welcome.
w.
| | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Willy Tschager wrote:
> Hi folks,
SNIP
>
> * 100% backwards compatible with the old LDConfig.ldr file
> http://www.ldraw.org/library/official/ldconfig.ldr
> * Uses LEGO RGB values
> * Uses LEGO numbering where possible
> * Lists the matched LEGO name
> * Uses Bricklink names
So it'd be goodbye for Stone Gray? :-( Well, I can live with that..
> * Contains all colors currently listed at Bricklink
> * Colors are listed in alphabetical order
> * New color definitions for "Glitter" and "Speckle" as defined by the LSC
Nice! :-)
SNIP
> Shall we restore the historical LDraw colors for the range from 0 to 50 since
> the new colors look unnatural and washed out? This has to discussed before we
> officially ship the new file with the 02-2009 parts update.
Hmm... looking at the new colours I'd be otherwise fine sans the new Black...
looks too bluish for me.
>
> Another issue is consistency. While some programs of the LDraw System of Tools
> already support the LDConfig.ldr file and use it instead of an inbuild color
> system some don't. In order to keep the colors consistent throughout the LDraw
> System of Tools it would be desirable to have all programs switch to the
> LDConfig file.
Well that's going to be quite a job considering MLCad's and L3P's unmaintained
nature..
SNIP
>
> Comments and feedback are welcome.
>
> w.
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Willy Tschager wrote:
> we put together a new LDConfig file which hopefully fills in where
> the old version failed. A beta version of the file can be found at:
> http://www.holly-wood.it/tmp/LDConfig.ldr
> while a Wiki version showing also the colors is stored at:
> http://www.ldraw.org/wiki/index.php/LDConfig.ldr
> Before going public we have asked some programmers for
> feedback. Most concerns were rose about the transparent color
> values. Be sure we used the Shadow colors provided by the LEGO
> Group. Shadow colors are not the RGB values used for the molds but
> are representations of those colors used in the company's system.
> Question is:
> Shall we restore the historical LDraw colors for the range from 0 to
> 50 since the new colors look unnatural and washed out? This has to
> discussed before we officially ship the new file with the 02-2009
> parts update.
I don't really know what I'm talking about here, but I think there
might be a big difference between the representation of RGB values
in a dye based color system for bricks, another one for printing on
paper, and a color system for computer monitors.
http://en.wikipedia.org/wiki/Gamut
The impression I get is that you can't use the same RGB values
for both systems and see the same colors. I *like* the original
bright shiny ldraw colors. They make it look like the toy that it
is. So if I had a vote, I'd keep the original 64 colors. That's
always been my opinion...
http://news.lugnet.com/cad/dev/?n=9789
But apparently the bright shiny colors (and edges) have gone out of
style. Does this file still exist anywhere?
http://www.ldraw.org/library/unofficial/ldconfig-alt.ldr
> We also encourage a switch from the current sorting on numbers to an
> alphabetical order of the colors
Hmmm, I'm not sure that helps me any. If I can't remember the
number for a color, I'd rather they were clustered by basic color
first, then alphabetically by the actual name. Like this:
Green: Bright Green
Green: Dark Green
Green: Earth Green
If I can't have something like that, I'd rather just sort by number.
> You'll also find a list with the original TGL
> numbers moved to a 3xxxx range. In no way have the TGL numbers to be
> mixed with LDraw colors. Also the comments where we matched the TLG
> numbers to LDraw colors should be hidden from the final user.
I like that info, but I don't really like the way the comments make
the file difficult to scan. Maybe if you moved the LEGOID comments
further to the right it'd give better visual separation from the ldraw
info.
0 // LEGOID 26 - Black
0 !COLOUR Black CODE 0 VALUE #1B2A34 EDGE #595959
Have fun,
Don
| | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Don Heyse wrote:
> In lugnet.cad, Willy Tschager wrote:
> But apparently the bright shiny colors (and edges) have gone out of
> style. Does this file still exist anywhere?
>
> http://www.ldraw.org/library/unofficial/ldconfig-alt.ldr
The file is still shipped with the LDraw Parts Library though it has been
renamed to "ldcfgalt.ldr"
> > We also encourage a switch from the current sorting on numbers to an
> > alphabetical order of the colors
>
> Hmmm, I'm not sure that helps me any. If I can't remember the
> number for a color, I'd rather they were clustered by basic color
> first, then alphabetically by the actual name. Like this:
>
> Green: Bright Green
> Green: Dark Green
> Green: Earth Green
Hmmm this would be best solved with an additional command in the file - say
CATEGORY or CLASTER or whatever. Anyway, modifications to the synthax can only
be applied by the LSC.
> I like that info, but I don't really like the way the comments make
> the file difficult to scan. Maybe if you moved the LEGOID comments
> further to the right it'd give better visual separation from the ldraw
> info.
>
> 0 // LEGOID 26 - Black
> 0 !COLOUR Black CODE 0 VALUE #1B2A34 EDGE #595959
Good point. I'll modify the file accordingly.
w.
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Don Heyse wrote:
| |
In lugnet.cad, Willy Tschager wrote:
| |
We also encourage a switch from the current sorting on numbers to an
alphabetical order of the colors
|
Hmmm, I’m not sure that helps me any. If I can’t remember the
number for a color, I’d rather they were clustered by basic color
first, then alphabetically by the actual name. Like this:
Green: Bright Green
Green: Dark Green
Green: Earth Green
If I can’t have something like that, I’d rather just sort by number.
|
I think group sub-sorting might be more trouble than it’s worth. Editors can
just sort the colors by Hue-Saturation-Brightness. That’s what Bricksmith does.
It’s a simple mathematical transformation.
Allen
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Allen Smith wrote:
| |
In lugnet.cad.dev.org.ldraw, Don Heyse wrote:
| |
In lugnet.cad, Willy Tschager wrote:
| |
We also encourage a switch from the current sorting on numbers to an
alphabetical order of the colors
|
Hmmm, I’m not sure that helps me any. If I can’t remember the
number for a color, I’d rather they were clustered by basic color
first, then alphabetically by the actual name. Like this:
Green: Bright Green
Green: Dark Green
Green: Earth Green
If I can’t have something like that, I’d rather just sort by number.
|
I think group sub-sorting might be more trouble than it’s worth. Editors can
just sort the colors by Hue-Saturation-Brightness. That’s what Bricksmith
does. It’s a simple mathematical transformation.
|
Now that’s what I’m talking about! I just didn’t say it right. ;)
If you’re not going to list the colors in ldconfig.ldr sorted by number then
pick a useful ordering like Hue-Saturation-Brightness. Alphabetic order
is not much better than random.
By the way, what’s up with the grays in the bricksmith list? Not pure
enough to get placed near the top of the list between black and white?
Is there any way to tweak that?
| |
Allen
|
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Don Heyse wrote:
> In lugnet.cad.dev.org.ldraw, Allen Smith wrote:
> > In lugnet.cad.dev.org.ldraw, Don Heyse wrote:
> > > In lugnet.cad, Willy Tschager wrote:
> > > > We also encourage a switch from the current sorting on numbers to an
> > > > alphabetical order of the colors
> > >
> > > Hmmm, I'm not sure that helps me any. If I can't remember the
> > > number for a color, I'd rather they were clustered by basic color
> > > first, then alphabetically by the actual name. Like this:
> > >
> > > Green: Bright Green¬
> > > Green: Dark Green¬
> > > Green: Earth Green¬
> > >
> > > If I can't have something like that, I'd rather just sort by number.
> >
> >
> > I think group sub-sorting might be more trouble than it's worth. Editors can
> > just sort the colors by Hue-Saturation-Brightness. That's what Bricksmith
> > does. It's a simple mathematical transformation.
>
> Now that's what I'm talking about! I just didn't say it right. ;)
> If you're not going to list the colors in ldconfig.ldr sorted by number then
> pick a useful ordering like Hue-Saturation-Brightness. Alphabetic order
> is not much better than random.
Each program that reads and uses the LDconfig.ldr file should know how best to
display the colors. If the program shows color swaths, then it does make good
sense for the program to display them in a Hue-Saturation-Brightness order. For
programs that display only the names, then displaying the names in alphabetical
order makes sense.
When adding to and editing the LDconfig.ldr file, people can not visually
translate the Hex RGB values to color swaths, therefore it does not make sense
to sort them by Hue-Saturation-Brightness in the file itself.
Sorting by color codes or alphabetically makes the file more easily edited and
new colors added without having to use a program to calculate where a new color
would fit in a Hue-Saturation-Brightness sort order.
Color codes are becoming less well-known, as many programs don't display the
color code along with the color swath / color name.
Therefore, alphabetical sorting in the LDconfig.ldr file makes the most sense;
leaving each software program to best determine how these colors should be
displayed to the program user.
Scott W.
Member LSC
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Scott Wardlaw wrote:
> In lugnet.cad.dev.org.ldraw, Don Heyse wrote:
> > In lugnet.cad.dev.org.ldraw, Allen Smith wrote:
> > > In lugnet.cad.dev.org.ldraw, Don Heyse wrote:
> > > > In lugnet.cad, Willy Tschager wrote:
> > > > > We also encourage a switch from the current sorting on numbers to an
> > > > > alphabetical order of the colors
> > > I think group sub-sorting might be more trouble than it's
> > > worth. Editors can just sort the colors by
> > > Hue-Saturation-Brightness. That's what Bricksmith does. It's a
> > > simple mathematical transformation.
> > Now that's what I'm talking about! I just didn't say it right. ;)
> > If you're not going to list the colors in ldconfig.ldr sorted by
> > number then pick a useful ordering like Hue-Saturation-Brightness.
> > Alphabetic order is not much better than random.
> Each program that reads and uses the LDconfig.ldr file should know
> how best to display the colors. If the program shows color swaths,
> then it does make good sense for the program to display them in a
> Hue-Saturation-Brightness order. For programs that display only the
> names, then displaying the names in alphabetical order makes sense.
Personally I find it harder to remember all the silly names than to
remember the basic colors by number. If they aren't sorted by color
then I still want red, blue, yellow, black, white, and grey near the
top of the list. The numeric order has that property.
> When adding to and editing the LDconfig.ldr file, people can not
> visually translate the Hex RGB values to color swaths, therefore it
> does not make sense to sort them by Hue-Saturation-Brightness in the
> file itself.
> Sorting by color codes or alphabetically makes the file more easily
> edited and new colors added without having to use a program to
> calculate where a new color would fit in a Hue-Saturation-Brightness
> sort order.
This is where you lose me. Why is alphabetic order easier to edit?
I'd think that since what you're doing is creating new codes, what you
really want to know is which codes are already used. The old
numerical order still makes the most sense for that. My point with
the HSB ordring is that it might be easier to see if a new color
called say "fruity puff" already has a number with a different name in
the file if you could see all the pinks listed together. You don't
need to translate hex values to know that "powdered pink" and "scala
blush" are similar and might be the same as "fruity puff", but it'd
be a lot harder to find and compare them if listed alphabetically.
Didn't someone just say the bonifide lego names are mostly gibberish?
My honest opinion is that you should leave the file in numeric order
and try to repurpose colors from the dithered section for the most
compatibility. I'm sure if you look you can find a nice dithered
color close enough to "fruity puff" that it can be slightly recolored
in the LDconfig.ldr file to match exactly.
> Color codes are becoming less well-known, as many programs don't
> display the color code along with the color swath / color name.
That's ok, but the folks in charge of the LDconfig.ldr file should
probably know something about the color codes, right? The codes
are what that file is all about! Otherwise we'd just list the
color names along with an RGB value and be done with it.
> Therefore, alphabetical sorting in the LDconfig.ldr file makes the
> most sense; leaving each software program to best determine how
> these colors should be displayed to the program user.
> Scott W.
> Member LSC
I suppose since you guys are responsible for additions to the file,
it makes sense to go with what you like best, even if it's nonsense
to me. :)
Have fun,
Don
(lazy membership avoider and general trouble maker)
| | | | | | | | | | | | | | | | | | | | | | | |
Oh yeah, one more thing. If you've gotta sort alphabetically, I say
don't discriminate. Sort the Lego core colors in the 30000 range
alphabetically too. What? You say can't do that, because those numbers
mean something? How could that be?
I'm gonna be really sorry I wrote this. Probably right after the coffee
kicks in. It's just that I'm old and I've been through this before. I
still remember a sad day long ago when I discovered a junior programmer
had taken an enormous java file and run some silly javadoc function on it
that sorted everything alphabetically. He left and the next guy to
to work on the project could never find anything because all the functional
groupings were gone.
Don't let that happen to us.
Enjoy,
Don
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Don Heyse wrote:
> My honest opinion is that you should leave the file in numeric order
> and try to repurpose colors from the dithered section for the most
> compatibility. I'm sure if you look you can find a nice dithered
> color close enough to "fruity puff" that it can be slightly recolored
> in the LDconfig.ldr file to match exactly.
Yeah, I actually wanted to do that too in the begining. I can't remember how
long we have been working on the release of this file, but it has been a long
time for me. I'm not sure I have enough fight left in me to support (and drag
this out longer) to match the new colors to the historic dithered color codes.
Adding colors in this way is not without its complications, and for those colors
(like Dark Red) that are already defined in this way, they have caused problems.
I also fought to group like color codes together in reserved groups; like the
32-63 color codes were reserved for transparent colors. Colors do have some
grouping, but we had to work around color codes that were already defined.
> > Color codes are becoming less well-known, as many programs don't
> > display the color code along with the color swath / color name.
>
> That's ok, but the folks in charge of the LDconfig.ldr file should
> probably know something about the color codes, right? The codes
> are what that file is all about! Otherwise we'd just list the
> color names along with an RGB value and be done with it.
Well, its not all about the color codes, but point well taken. I'll switch my
vote to sorting by color codes. Thanks for sticking to your guns.
Scott
| | | | | | | | | | | | | | | | | | |
In lugnet.cad, Willy Tschager wrote:
> Comments and feedback are welcome.
>
> w.
All new color codes except 313 Maersk Blue generate errors in L3Lab and L3P
because the numbers just had to be picked from the forbidden zone... :( :( :(
/Tore
| | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
> All new color codes except 313 Maersk Blue generate errors in L3Lab and L3P
> because the numbers just had to be picked from the forbidden zone... :( :( :(
Could you be a bit more precise. What is the "Forbidden zone"?
w.
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Willy Tschager wrote:
> In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
> > All new color codes except 313 Maersk Blue generate errors in L3Lab and L3P
> > because the numbers just had to be picked from the forbidden zone... :( :( :(
>
> Could you be a bit more precise. What is the "Forbidden zone"?
>
> w.
Well, actually there are two forbidden zones; the small at colors 29 through 31
and the large at 48 to 255. Color numbers within those ranges generate errors if
used in L3P and L3Lab. In original LDraw and other really old programs, colors
25-28 will most likely also cause errors as they are hard-coded in L3 programs
and some other more recent tools. I understand that it is of course thought that
programs made today will look the colors up in LDConfig.ldr. But so far we need
current L3P to convert to PovRay.
Using dithered numbers (256-511), like 313 for Maersk Blue, will generate a
somewhat acceptable lightblue from L3P, while an unknown numbers like 29, 92,
and 151 will generate an annoying error and color #7 (lightgray) will be picked
instead.
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
> In lugnet.cad.dev.org.ldraw, Willy Tschager wrote:
> > In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
> > > All new color codes except 313 Maersk Blue generate errors in L3Lab and L3P
> > > because the numbers just had to be picked from the forbidden zone... :( :( :(
> >
> > Could you be a bit more precise. What is the "Forbidden zone"?
> >
> > w.
>
> Well, actually there are two forbidden zones; the small at colors 29 through 31
> and the large at 48 to 255. Color numbers within those ranges generate errors if
> used in L3P and L3Lab. In original LDraw and other really old programs, colors
> 25-28 will most likely also cause errors as they are hard-coded in L3 programs
> and some other more recent tools. I understand that it is of course thought that
> programs made today will look the colors up in LDConfig.ldr. But so far we need
> current L3P to convert to PovRay.
>
> Using dithered numbers (256-511), like 313 for Maersk Blue, will generate a
> somewhat acceptable lightblue from L3P, while an unknown numbers like 29, 92,
> and 151 will generate an annoying error and color #7 (lightgray) will be picked
> instead.
As far as I remember LDView does a more than decent job converting to PovRay as
well as viewer so there is actually no need for L3P or L3Lab - not counting in
that accordingly the L3P page http://www.hassings.dk/l3/l3p14beta.html#version14
it supports the LDConfig.ldr file:
"Colors from ldconfig.ldr
The new default for color values is to use the definitions in ldconfig.ldr
located in the LDraw directory. See LDraw.org Colour Definition Language
Extension."
Reading also through the "LDraw.org Colour Definition Language Extension" specs
at http://www.ldraw.org/Article299.html it doesn't talk about a forbidden zone
and therefore yes I expect "programs made today will look the colors up in
LDConfig.ldr"
w.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Willy Tschager wrote:
> In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
> > In lugnet.cad.dev.org.ldraw, Willy Tschager wrote:
> > > In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
> > > > All new color codes except 313 Maersk Blue generate errors in L3Lab and L3P
> > > > because the numbers just had to be picked from the forbidden zone... :( :( :(
> > >
> > > Could you be a bit more precise. What is the "Forbidden zone"?
> > >
> > > w.
> >
> > Well, actually there are two forbidden zones; the small at colors 29 through 31
> > and the large at 48 to 255. Color numbers within those ranges generate errors if
> > used in L3P and L3Lab. In original LDraw and other really old programs, colors
> > 25-28 will most likely also cause errors as they are hard-coded in L3 programs
> > and some other more recent tools. I understand that it is of course thought that
> > programs made today will look the colors up in LDConfig.ldr. But so far we need
> > current L3P to convert to PovRay.
> >
> > Using dithered numbers (256-511), like 313 for Maersk Blue, will generate a
> > somewhat acceptable lightblue from L3P, while an unknown numbers like 29, 92,
> > and 151 will generate an annoying error and color #7 (lightgray) will be picked
> > instead.
>
> As far as I remember LDView does a more than decent job converting to PovRay as
> well as viewer so there is actually no need for L3P or L3Lab - not counting in
> that accordingly the L3P page http://www.hassings.dk/l3/l3p14beta.html#version14
> it supports the LDConfig.ldr file:
>
> "Colors from ldconfig.ldr
> The new default for color values is to use the definitions in ldconfig.ldr
> located in the LDraw directory. See LDraw.org Colour Definition Language
> Extension."
That's very good news! Very recently I visited
http://www.ldraw.org/Downloads-req-viewdownload-cid-11.html and there it reads:
"Version: 1.3 | File size: 78.00 Kb" and links to
http://www.hassings.dk/l3/l3p.html where it reads: "NEW Read about the v1.3
20010120 release NEW". Maybe time to update some pages?
I haven't checked out how LDView does command line based batch jobs and if I am
able to change LDA to call on LDView to convert the frames into POV instead of
L3P. So I'm not ready to throw out L3P yet. And to abandon L3Lab after all these
years, well I'll do that only if I'm forced to. It's still my LDraw viewer of
choise.
> Reading also through the "LDraw.org Colour Definition Language Extension" specs
> at http://www.ldraw.org/Article299.html it doesn't talk about a forbidden zone
> and therefore yes I expect "programs made today will look the colors up in
> LDConfig.ldr"
>
> w.
I don't see the point in disregarding backwards compability when there's nothing
to gain with it. I was pro skipping subfiling silver, gold and other special
colored pattern details - but that did only affect original LDraw because of a
tiny bug in it. We still have a couple of hundred color numbers that do not
cause problems with older LDraw programs and utilities that don't search
LDConfig.ldr, why on earth not use them first?
Correct, LDraw.org Colour Definition Language Extension specs doesn't talk about
a forbidden zone. But OTOH, has there been a decision that it's ok to use these
incompatible color numbers?
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
> That's very good news! Very recently I visited
> http://www.ldraw.org/Downloads-req-viewdownload-cid-11.html and there it reads:
> "Version: 1.3 | File size: 78.00 Kb" and links to
> http://www.hassings.dk/l3/l3p.html where it reads: "NEW Read about the v1.3
> 20010120 release NEW". Maybe time to update some pages?
It is the webmaster's policy that the authors submit and maintain the links to
their tools and we only remove broken links. Obviously nothing hinders us to
update the link for L3P at Ldraw.org but since nothing on the official page
http://www.hassings.dk/l3/l3p.html points to the beta version we have to take
into account that apparently the author considers his beta version not fit for
the public yet, though it has been released almost a year ago.
> I don't see the point in disregarding backwards compability when there's nothing
> to gain with it. I was pro skipping subfiling silver, gold and other special
> colored pattern details - but that did only affect original LDraw because of a
> tiny bug in it. We still have a couple of hundred color numbers that do not
> cause problems with older LDraw programs and utilities that don't search
> LDConfig.ldr, why on earth not use them first?
Hmm ... let's see: http://www.hassings.dk/l3/l3lab.html Current version: v1.2 -
2000 06 16.
* Last time we stuck to backwards compatibility for a no longer updated prog we
had to separate dithers colors into subfiles.
* Last time we stuck to backwards compatibility for a no longer updated prog the
PT admins had to squeeze the parts numbering into 8 digits.
* Last time we stuck to backwards compatibility for a no longer updated prog the
numbering of the new colors was bend to this scheme:
http://news.lugnet.com/cad/?n=11937
* Last time we stuck to a no longer updated prog we ended up with three years
without any library update and some 3000 part headers checked one by one.
Welcome to 2009.
> Correct, LDraw.org Colour Definition Language Extension specs doesn't talk about
> a forbidden zone. But OTOH, has there been a decision that it's ok to use these
> incompatible color numbers?
Go and ask the LSC.
w.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Willy Tschager wrote:
> * Last time we stuck to backwards compatibility for a no longer updated prog we
> had to separate dithers colors into subfiles.
That is just so not true.
> Welcome to 2009.
Well then, welcome to my reality.
Viewing just a small portion of Datsville on my AMD1100, for example
TOWN-10.ldr, takes 1.8 seconds in L3Lab. But several minutes in LDView - if it
doesn't crash. I am unemployed and with absolutely no hope whatsoever of getting
a fulltime job that will make me able to afford a new PC. (And anyway, I doubt
that a top modern state of the art home PC comes close to 1.8 seconds in
LDView.)
But go ahead you guys, keep making the LDraw community more and more a
highbrowed clique, leaving all but a very small exclusive LDraw Super-Elite
behind. Keep neglecting backwards compability issues and people like Fernando
http://news.lugnet.com/cad/?n=16378 will very soon get tired and move on from
us.
Remember when the LDraw community was teeming with activity? New parts were
added to the official library, not just added to the ever growing list of files
forever held in the Tracker. Almost anyone could create an LDraw oriented
utility program. The LDraw specs where aimed to simplicity and
user-friendliness. Now it seems professionality and correctness. So now only
professional programmers are able to come up with anything compliant.
Wrong way, IMO!
/Tore
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
> In lugnet.cad.dev.org.ldraw, Willy Tschager wrote:
>
> > * Last time we stuck to backwards compatibility for a no longer updated prog we
> > had to separate dithers colors into subfiles.
>
> That is just so not true.
>
> > Welcome to 2009.
>
> Well then, welcome to my reality.
>
> Viewing just a small portion of Datsville on my AMD1100, for example
> TOWN-10.ldr, takes 1.8 seconds in L3Lab. But several minutes in LDView - if it
> doesn't crash. I am unemployed and with absolutely no hope whatsoever of getting
> a fulltime job that will make me able to afford a new PC. (And anyway, I doubt
> that a top modern state of the art home PC comes close to 1.8 seconds in
> LDView.)
That is not correct. The 1.8 sec are the drawing time. If you will have a look
into 'statistics' you will see that most of the time the loading will take and
then 1.8 sec. for the drawing is used.
So this comparison is not correct, but you are right if you say LDView is not so
fast as L3Lab. But for me the result of LDView is much better. If you only need
a viewer to see wheather the parts are correct build and then use POV-Ray to
create the picture, I believe that L3Lab is the better tool. But for all other
usage I would prefer LDView.
cu
mikeheide
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
> In lugnet.cad.dev.org.ldraw, Willy Tschager wrote:
>
> > * Last time we stuck to backwards compatibility for a no longer updated prog we
> > had to separate dithers colors into subfiles.
>
> That is just so not true.
>
> > Welcome to 2009.
>
> Well then, welcome to my reality.
>
> Viewing just a small portion of Datsville on my AMD1100, for example
> TOWN-10.ldr, takes 1.8 seconds in L3Lab. But several minutes in LDView - if it
> doesn't crash. I am unemployed and with absolutely no hope whatsoever of getting
> a fulltime job that will make me able to afford a new PC. (And anyway, I doubt
> that a top modern state of the art home PC comes close to 1.8 seconds in
> LDView.)
>
> But go ahead you guys, keep making the LDraw community more and more a
> highbrowed clique, leaving all but a very small exclusive LDraw Super-Elite
> behind. Keep neglecting backwards compability issues and people like Fernando
> http://news.lugnet.com/cad/?n=16378 will very soon get tired and move on from
> us.
Did you have any suggestions for him? I did not, other than that he does not
have his paths set up correctly (which was already mentioned). I do not even
have LPub 2 installed anywhere anymore. Do you? If so, maybe you could help
him. I'd appreciate it very much.
>
> Remember when the LDraw community was teeming with activity? New parts were
> added to the official library, not just added to the ever growing list of files
> forever held in the Tracker. Almost anyone could create an LDraw oriented
> utility program. The LDraw specs where aimed to simplicity and
> user-friendliness. Now it seems professionality and correctness. So now only
> professional programmers are able to come up with anything compliant.
>
>
> Wrong way, IMO!
> /Tore
Kevin
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
| |
Viewing just a small portion of Datsville on my AMD1100, for example
TOWN-10.ldr, takes 1.8 seconds in L3Lab. But several minutes in LDView - if it
doesn’t crash. I am unemployed and with absolutely no hope whatsoever of
getting a fulltime job that will make me able to afford a new PC. (And anyway,
I doubt that a top modern state of the art home PC comes close to 1.8 seconds
in LDView.)
|
I have a few comments here. First of all, if you’re going to load a huge model
in LDView, it’s usually best to set its “Memory Usage” setting to Low
(especially on old hardware). Secondly, as has been pointed out, LDView takes a
lot longer to load models than L3P, but after they are loaded, they can be
examined at much higher speed (although not once they cause LDView to have to
swap).
On my computer here at work, I get around 2.5 FPS on town.mpd (from
here) once it has
loaded. That’s all of Datsville, and it does take awhile to load (about 35
seconds). Switching to town-10.dat in the MPD gives me around 50 FPS with
memory usage set to Low and 75 FPS with memory usage set to High. (I switched
to High after selecting the town-10.dat MPD sub-model; loading town.mpd with it
set to High is generally a bad idea.)
All of the above was done on a recent fast computer, and obviously things slow
down dramatically as the age of the computer increases. On your computer, L3Lab
seems to be a more appropriate program, because it was designed with different
goals, but the fact is that on a modern computer, LDView works fine, even with
large models.
--Travis
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Travis Cobbs wrote:
| |
I have a few comments here. First of all, if you’re going to load a huge
model in LDView, it’s usually best to set its “Memory Usage” setting to Low
(especially on old hardware). Secondly, as has been pointed out, LDView
takes a lot longer to load models than L3P, but after they are loaded, they
can be examined at much higher speed (although not once they cause LDView to
have to swap).
|
This makes me curious as to how this Memory Usage feature works. Why would I
set the memory usage to “Low” if I have plenty of RAM? What does this do for
me?
Eric
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Eric Albrecht wrote:
| |
In lugnet.cad.dev.org.ldraw, Travis Cobbs wrote:
| |
I have a few comments here. First of all, if you’re going to load a huge
model in LDView, it’s usually best to set its “Memory Usage” setting to Low
(especially on old hardware). Secondly, as has been pointed out, LDView
takes a lot longer to load models than L3P, but after they are loaded, they
can be examined at much higher speed (although not once they cause LDView to
have to swap).
|
This makes me curious as to how this Memory Usage feature works. Why would I
set the memory usage to “Low” if I have plenty of RAM? What does this do for
me?
|
The main effect that this setting has is its control over the amount of display
list compilation used. Display lists are a feature in OpenGL (the graphics
library used by LDView) for drawing static objects. They convert (compile) the
data into an internal format that the graphics card is more efficient at
rendering. My understanding is that this compiled data is also usually stored
directly in video memory.
I can’t remember with absolute certainty, but I believe that Low produces no
display lists, Medium produces a display list for each part, but not for
anything above the part level, and High produces a display list for every part,
plus every sub-model in the model, plus the main model.
As it turns out, display lists use a lot of memory, both PC main memory and
graphics card video memory. So it might be useful to set to Medium or Low even
if you have plenty of system memory, because if they don’t all fit into the
video memory, things slow down.
--Travis
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Travis Cobbs wrote:
| |
As it turns out, display lists use a lot of memory, both PC main memory and
graphics card video memory. So it might be useful to set to Medium or Low
even if you have plenty of system memory, because if they don’t all fit into
the video memory, things slow down.
|
Thanks for the explanation. Since my computer at work (which I am using) is a
high end CAD workstation with enough VRAM to display a billion polygons, I guess
I should just leave it on HIGH! On my home machine, I will probably slow it
down.
Eric
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Eric Albrecht wrote:
| |
Thanks for the explanation. Since my computer at work (which I am using) is
a high end CAD workstation with enough VRAM to display a billion polygons, I
guess I should just leave it on HIGH! On my home machine, I will probably
slow it down.
|
It may be able to display a billion polygons, but it certainly can’t keep a
billion unique polygons in video memory. Each unique point requires a bare
minimum of 12 bytes, and usually requires more than that (for color/texture
info). The indexes into the point list used to draw the polygon are usually 2
or 4 byte integers, so that’s either 2 or 4 more bytes per point. Even with a
fully connected triangular mesh, you’re talking about 1 point and 3 indexes per
triangle. (You can draw in other modes that use less memory, but they also tend
to be a lot slower.)
--Travis
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
> But go ahead you guys, keep making the LDraw community more and more a
> highbrowed clique, leaving all but a very small exclusive LDraw Super-Elite
> behind.
Well, what we are actually trying with the new LDConfig.ldr file is getting more
colors into LDraw, colors people find in today’s set but not LDraw and IMHO it
lowers the bar for users if the colors are consistent throughout the system.
Since you havn’t complaint that there are colors missing in the current palette
I doubt that you’ll miss them once they are part of the new palette.
> Remember when the LDraw community was teeming with activity? New parts were
> added to the official library, not just added to the ever growing list of files
> forever held in the Tracker.
Sounds you're going to apply as additional PT admin to get those parts out to
the user - I welcome that!
> Almost anyone could create an LDraw oriented
> utility program. The LDraw specs where aimed to simplicity and
> user-friendliness. Now it seems professionality and correctness. So now only
> professional programmers are able to come up with anything compliant.
Well from the user's POV (since I have no programmer's skills) I prefer a
professional one-stop-shopping-prog with all the features included instead of
L3P + L3PAdd-on + POV + LGEO with loads .ini entries and such.
> /Tore
w.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Willy Tschager wrote:
> In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
>
> > But go ahead you guys, keep making the LDraw community more and more a
> > highbrowed clique, leaving all but a very small exclusive LDraw Super-Elite
> > behind.
>
> Well, what we are actually trying with the new LDConfig.ldr file is getting more
> colors into LDraw, colors people find in today’s set but not LDraw and IMHO it
> lowers the bar for users if the colors are consistent throughout the system.
Kickin' in open doors, are you? I have absolutely no reason to disagree.
> Since you havn’t complaint that there are colors missing in the current palette
> I doubt that you’ll miss them once they are part of the new palette.
You are right about one thing: newer LEGO colours isn't one of my obsessions,
but I may download other peoples' LDraw MOCs...
> Sounds you're going to apply as additional PT admin to get those parts out to
> the user - I welcome that!
I'd love to, but I don't think it would be a very good idea. My criteria seem
light years away from the other PT Admins'.
> Well from the user's POV (since I have no programmer's skills) I prefer a
> professional one-stop-shopping-prog with all the features included instead of
> L3P + L3PAdd-on + POV + LGEO with loads .ini entries and such.
You know what? I'm mainly a user, too. And it's not as a programmer but as a
user I don't like a 20-fold rendering time, no matter how professional the
renderer may be, or heaps with warnings and colors substituted with lightgray as
the option. Who is this average LDraw user often referred to anyway, who's
experiences have to be taken in so much more consideration than, for example,
mine?
/Tore
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
--snip--
> Who is this average LDraw user often referred to anyway, who's
> experiences have to be taken in so much more consideration than, for example,
> mine?
>
>
> /Tore
The majority of LDraw users I know of outside LUGNET (flickr, facebook and TBB)
use MLCAD and LDview for their LDraw experience. It's not a full poll and it's
not a big sample but it's probably a better example of 'new users' than what
you'll see on LUGNET.
I understand the desire for backwards compatibility but sometimes decisions that
made sense in a different world (EGA... not even VGA) have to be looked over and
overturned. I would be willing to bet that your statistically averaged modern
user hasn't even heard of l3p, l3plab or POVray. What they have heard of is the
modern colours that simply aren't rendered well enough in older software.
Likewise (to agree with you on another point) I do think that they would care
less about a perfect part than they do about an official (and thus easily
installed) part. But that is a decision for the elected and delegated
'officials' and, even more importnantly, for the people that will actually carry
out the necessary work.
My thoughts,
Tim
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Timothy Gould wrote:
| |
Likewise (to agree with you on another point) I do think that they would care
less about a perfect part than they do about an official (and thus easily
installed) part. But that is a decision for the elected and delegated
‘officials’ and, even more importnantly, for the people that will actually
carry out the necessary work.
|
The 2006-2007 LSC agreed with this also, which is why we added the part about
“(needs work)” to the LDraw.org Official
Library Header Specification.
--Travis
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
> But go ahead you guys, keep making the LDraw community more and more a
> highbrowed clique, leaving all but a very small exclusive LDraw Super-Elite
> behind.
No need for the vitriol Tore.
> Remember when the LDraw community was teeming with activity?
Yes but, as with all things, people come and people go. I, for example, am much
more withdrawn than I was in 2004 since I'm on an operational submarine now and
only have a limited amount of time in port. Believe me, I have about 5 or 6
projects on the back burner waiting for me to find time to get back to them.
> New parts were
> added to the official library, not just added to the ever growing list of files
> forever held in the Tracker.
I've said this before and I'll say it again: I would rather have a smaller
number of high quality parts than a large number of low quality ones. I do
photoreal renders (when I have time to work on them) and higher quality, more
refined parts definately make a difference. Plus all the parts are publicly
available for download on the PT.
> Almost anyone could create an LDraw oriented
> utility program. The LDraw specs where aimed to simplicity and
> user-friendliness. Now it seems professionality and correctness. So now only
> professional programmers are able to come up with anything compliant.
Let's face it, the average user doesn't see and doesn't care about the
underlying LDraw code. They just want to create models on their computer and
render them in a way that is pleasing. The spec is written by programmers, for
programmers. So yes, there may be some complexity but this is necessary since
Lego is a complex system. The spec will also evolve. Yes, backward
compatibility is important but I have no interest in preserving it if it
threatens to hold back the development of new ways to enrich the current user
experience. At some points the lines have to be cut
-Orion
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Orion Pobursky wrote:
> In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
> > But go ahead you guys, keep making the LDraw community more and more a
> > highbrowed clique, leaving all but a very small exclusive LDraw Super-Elite
> > behind.
>
> No need for the vitriol Tore.
Couldn't find the word "vitriol" in my dictionary, just "vitrify". But from the
context I conclude it's something like aggressive, rude, grumpy, impolite, or
emotional. And yes, I admit I've been unnesessarily grumpy and I am truly sorry
for that. But it is with an enormous sadness I watch the LDraw elitee leaving
users like me behind, and doing so with a most condescending attitude.
> > New parts were
> > added to the official library, not just added to the ever growing list of files
> > forever held in the Tracker.
>
> I've said this before and I'll say it again: I would rather have a smaller
> number of high quality parts than a large number of low quality ones. I do
> photoreal renders (when I have time to work on them) and higher quality, more
> refined parts definately make a difference. Plus all the parts are publicly
> available for download on the PT.
What you are saying is that your LDraw usage is important, mine isn't. And, in
your photoreal renders, are the minifig heads still polygonized from the
original, official LDraw dat files, or are you using LGEO or Anton Raves'
library anyway? I fully understand that you don't want to use a part that "needs
work". Well then, just don't. But if it's good for over 98% of the usages, like
sharing MOC instructions, OMR, animation, whatever... who is "holding back the
development", really?
> Let's face it, the average user doesn't see and doesn't care about the
> underlying LDraw code. They just want to create models on their computer and
> render them in a way that is pleasing.
Great to see that you are concerned about the average user. I thought I was
counted as a user. Because as a user, I pointed out the unfortunate of using
colour codes that L3Lab can't handle. Use LDView instead, I was recommended. I
said I don't like to wait for minutes instead of seconds (alright I tweaked the
example to 40 seconds, but it's still unacceptable to me), but my opinion as an
LDraw user is not importatant, is it?
> Yes, backward
> compatibility is important but I have no interest in preserving it if it
> threatens to hold back the development of new ways to enrich the current user
> experience. At some points the lines have to be cut
Of course I agree to that. So let's get back to my original commentary. "All new
color codes except 313 Maersk Blue generate errors in L3Lab and L3P
because the numbers just had to be picked from the forbidden zone... :( :( :(".
(Keep in mind that I was unaware of L3P 1.4 when I wrote it.) In this case, I
have not asked for anything that could "threaten to hold back the development"
in any way at all. Yet my POVs has been completely trashed and neglected. Color
313 Maersk Blue is chosen with consideration. To pick the other color numbers
from the dithered range would by no means threaten anything.
/Tore
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
> In lugnet.cad.dev.org.ldraw, Orion Pobursky wrote:
> > I've said this before and I'll say it again: I would rather have a
> > smaller number of high quality parts than a large number of low
> > quality ones. I do photoreal renders
Quality is important, but the first priority of Ldraw should always
be to make it easy to create and share the models. Photo-realism is
nice, to be sure, but certainly a somewhat lower priority. I'm not
aware of any photo-realistic realtime ldraw editor. Is there one
available that I don't know about? That'd be ultra spiffy!
> let's get back to my original commentary. "All new
> color codes except 313 Maersk Blue generate errors in L3Lab and L3P
> because the numbers just had to be picked from the forbidden zone...
The obvious solution to this problem is to convince Lars to put out
some new versions of L3P and L3Lab with no "forbidden zone". Then
everyone can be happy. The most recent releases are only about a
year to a year and a half old, so it's not an impossible dream. I
say, let the nagging/begging begin. ;^)
Enjoy,
Don
| | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Willy Tschager wrote:
> In lugnet.cad.dev.org.ldraw, Tore Eriksson wrote:
> > All new color codes except 313 Maersk Blue generate errors in L3Lab and L3P
> > because the numbers just had to be picked from the forbidden zone... :( :( :(
>
> Could you be a bit more precise. What is the "Forbidden zone"?
>
> w.
I think he means the semi reserved ranges 32..63 (transparent version of 0..31)
and 256..511 (dithered version of two encoded 0..15 colors).
But as far I know these can be overridden by a 'normal' definition and should
only be treaded as 'special' when they are still undefined after reading all
information.
If thats the case the remaining gaps can be calculated based upon the loaded
information of colors 0..31.
This leaves the >=512 colors which are often ignored unless they are in the rgb
encoding ranges I talked about in a earlier post.
| | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Willy Tschager wrote:
> Hi folks,
<snip a lot of info>
Seems like quite an undertaking.
> Shall we restore the historical LDraw colors for the range from 0 to 50 since
> the new colors look unnatural and washed out?
My vote would go to keeping the old ldraw colors, like said else were most
monitors aren't calibrated.
>
> Another issue is consistency. While some programs of the LDraw System of Tools
> already support the LDConfig.ldr file and use it instead of an inbuild color
> system some don't. In order to keep the colors consistent throughout the LDraw
> System of Tools it would be desirable to have all programs switch to the
> LDConfig file.
I don't know about other software but my LD4DStudio uses the config file as a
base, users can override anything to their liking when needed by editing
additional xml files.
> We also encourage a switch from the current sorting on numbers to an
> alphabetical order of the colors (perfect would be to leave the choice to the
> user). You'll also find a list with the original TGL numbers moved to a 3xxxx
> range. In no way have the TGL numbers to be mixed with LDraw colors. Also the
> comments where we matched the TLG numbers to LDraw colors should be hidden from
> the final user.
I don't think the order of things in the config file is relevant to any one but
the maintainers, Because I don't think software should present the raw content
to the user. Instead it should reformat / sort it in a sooting way.
About the >=30000 range, most current applications only allow upto 511 or 1023
for 'normal color numbers'. There are also some (unofficial?) reserved hex
spaces for encoded rgb values (#02000000..#03FFFFFF and 04000000..#07FFFFFF).
Taking this into account I would also suggest using a hex range for these lc
core colors, so the color decoder code in any program can identify them a such
e.g (#400..#EFF (1024..3839)).
Just my thoughts,
Roland
| | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Roland Melkert wrote:
> About the >=30000 range, most current applications only allow upto 511 or 1023
> for 'normal color numbers'. There are also some (unofficial?) reserved hex
> spaces for encoded rgb values (#02000000..#03FFFFFF and 04000000..#07FFFFFF).
>
> Taking this into account I would also suggest using a hex range for these lc
> core colors, so the color decoder code in any program can identify them a such
> e.g (#400..#EFF (1024..3839)).
This can be done with the caveat that we start with something like say 2001 or
3001 in order to preserve the original LEGO numbering starting from 1 to 300.
for 2001 the TLG color number would be "#7D1". Correct?
w.
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Willy Tschager wrote:
> In lugnet.cad.dev.org.ldraw, Roland Melkert wrote:
> > About the >=30000 range, most current applications only allow upto 511 or 1023
> > for 'normal color numbers'. There are also some (unofficial?) reserved hex
> > spaces for encoded rgb values (#02000000..#03FFFFFF and 04000000..#07FFFFFF).
> >
> > Taking this into account I would also suggest using a hex range for these lc
> > core colors, so the color decoder code in any program can identify them a such
> > e.g (#400..#EFF (1024..3839)).
>
> This can be done with the caveat that we start with something like say 2001 or
> 3001 in order to preserve the original LEGO numbering starting from 1 to 300.
> for 2001 the TLG color number would be "#7D1". Correct?
>
> w.
Indeed, basically it doesn't matter what range you use. I just wanted to point
out that 'other' ranges are rounded upon hexadecimal notation (due to math
advantages). So I suggested also using that for these new ldc numbers for
consistency sake.
But human wise 2015 would be more recognizable than #40F (if #400..#EFF would be
used) I guess.
I do think there should be an official 'normal' color ceiling defined by
ldraw.org though. Just like the now (unofficial) 512 ceiling.
Roland
| | | | | | | | | | | | | | | | | | | | | | |
(canceled)
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Joshua Delahunty wrote:
> In lugnet.cad.dev.org.ldraw, Roland Melkert wrote:
> > In lugnet.cad.dev.org.ldraw, Willy Tschager wrote:
> > > In lugnet.cad.dev.org.ldraw, Roland Melkert wrote:
> > > > About the >=30000 range, most current applications only allow upto 511 or 1023
> > > > for 'normal color numbers'. There are also some (unofficial?) reserved hex
> > > > spaces for encoded rgb values (#02000000..#03FFFFFF and 04000000..#07FFFFFF).
> > > >
> > > > Taking this into account I would also suggest using a hex range for these lc
> > > > core colors, so the color decoder code in any program can identify them a such
> > > > e.g (#400..#EFF (1024..3839)).
> > >
> > > This can be done with the caveat that we start with something like say 2001 or
> > > 3001 in order to preserve the original LEGO numbering starting from 1 to 300.
> > > for 2001 the TLG color number would be "#7D1". Correct?
> > >
> > > w.
> >
> > Indeed, basically it doesn't matter what range you use. I just wanted to point
> > out that 'other' ranges are rounded upon hexadecimal notation (due to math
> > advantages). So I suggested also using that for these new ldc numbers for
> > consistency sake.
> >
> > But human wise 2015 would be more recognizable than #40F (if #400..#EFF would be
> > used) I guess.
> >
> > I do think there should be an official 'normal' color ceiling defined by
> > ldraw.org though. Just like the now (unofficial) 512 ceiling.
>
> I chose 30000 as the base for TLG colors for a couple reasons:
>
> a) when the parts were renumbered internally around 1968 or so, they started
> with 3001 for the 2x4 brick and built from there. Around 1994, numbering shifted
> again. The numbers up to 10000 (where the old documentation codes had started)
> had been used, so they started at 30000 and built upwards. It seemed a nice nod
> to history to use a number starting with 30xx (or in this case 30xxx)
>
> b) subtract 30000, and you have the TLG color number, nothing else fancy to do
> to convert
>
> c) 3000 seemed too low to leave enough room for a "ceiling" for LDRAW colors.
So far we have much more TLC color numbers than in LDraw (Bricklink) with TLC
apparently not going further than 300. Therefore a numbering starting with 3000
would be fine.
w.
| | | | | | | | | | | | | | | | | | |
In lugnet.cad, Willy Tschager wrote:
> A beta version of the file can be found at:
>
> http://www.holly-wood.it/tmp/LDConfig.ldr
For those wanting to use these new colors in MLCAD, ColorManager will convert it
for MLCAD use:
http://www.scottwardlaw.com/colormanager
-Scott
| | | | | | | | | | | | | | | | | | |
| |
|
Has any thought been given to anyone on how patterned parts/stickered parts are
to be handled? Because there are more colors used in printed and stickered
parts then there will ever be in the plastic colors that this defines.
I'm not trilled with the idea sorting by name, especially since there's nothing
defined in the LDConfig standard to allow translating names to languages besides
English. You might know that the part your using is some shade of purple, but
you'd have to search through the entire list trying to see what's the closest
match. And then you might be frustrated, since the name in the list calls it
"Lilac" or "Violet."
I don't really like that some colors are defined twice. If you want to have
white be available as both #15 and #30001, then 30001 should just be an alias of
the current color. Otherwise, how will a program know how to filter out
duplicates?
Many of the colors definitely don't look right. Are the colors listed on the
Peeron page (Pantone values) for printed building instructions, or the plastic
piece color? I imagine it's for printing, since the black looks bluish, the
white looks grayish, and the in-between colors just look off. The current
colors used by the ldconfig file seem better.
Andy
| | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Andrew Westrate wrote:
| |
I don’t really like that some colors are defined twice. If you want to have
white be available as both #15 and #30001, then 30001 should just be an alias
of the current color. Otherwise, how will a program know how to filter out
duplicates?
|
Duplicated colors are my deepest concern. Below is a screenshot of Bricksmith’s
color picker using the new ldconfig.ldr:
I can’t just hide the TLG colors. For one thing, some of them don’t seem to have
non-TLG counterparts (like TLG_Bright_Reddish_Orange). For another, any model
could be defined with these colors and I would have to properly display them
when selected. So I feel like I’m stuck with an unnavigable color palette.
I also think this is confusing to the user. What’s the difference between “TLG
Bright Blue” and “Blue”? Some people might think the former is better because
it’s TLG; others might opt for the latter, because nobody I’ve ever met calls
their blue bricks “TLG Bright Blue.”
Which colors are the appropriate colors for new models? The old (legacy?) LDraw
codes? Or the new Lego colors?
This gets confusing fast. I’d rather not put users through the trouble. Keep the
original LDraw code points as the exclusive homes for their colors, and keep
some of the plain original names. (Yes, I prefer “Brown” over “TLG Earth
Orange.” And “Green”/”Dark Green” vs. “TLG Dark Green”/”TLG Earth Green”. Lego’s
names are seriously confusing!) Lego’s official names can be documented with
comments rather than with duplicative LDraw codepoints which can never be
retracted once released.
All that said, I think it is fantastic to finally support the full color
palette, and I applaud all the hard work that’s gone into defining it. Thanks!
Allen
| | | | | | | | | | | | | | | | | | |
(canceled)
| | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Joshua Delahunty wrote:
> I'm fairly certain, after a lot of use and experimentation, that the
> RGB values supplied (which came originally from LEGO Digital
> Designer) work correctly as swatches, rather than object-generation
> colors. They've basically been "pre-lightened" to match the
> apparent look of a part held up to the page. When LDView
> (specifically) generates images based on these, it does so with
> OpenGL, and the apparent light that's allowed to "shine through"
> causes the colors to look even further lighter (about twice lighter
> than the base color, spoken subjectively).
>
> My experiments have show that (for instance with Blue), if one takes
> the transparent color and darkens it by about 2x, one comes up with
> something very close to the original color (here, blue) hex value,
> and then when the color is used in a model in LDView, the result is
> a lot closer to what one would expect to see.
>
> So, if I take an Aquazone windshield (say), and hold it up against
> my PDF, printed out, the Transparent Blue (43) looks about right
> next to the plastic. But if I generate an image of that windshield
> with LDView on a white background on the monitor, it looks far too
> light. If I then change 30043's color to one much closer to blue's
> (23), then LDView's image looks much better next to "the real
> thing."
>
> I'm guessing that LDD looks at the transparency bit, and adjusts the
> colors accordingly so it doesn't "double whammy" the lightening of
> transparent colors. Either that logic could be moved to the apps in
> question (yeah, I'm laughing myself at such a suggestion), or the
> trans colors might be offset by a given ratio to adjust them better.
So is it possible to save a version of LDView's lighting parameters so
that it defaults to colors that look right when using this
ldconfig.ldr file? If so, then I'd like to suggest putting some
comments at the top of the file mentioning this, and possibly even
listing the proper settings for LDView and any other programs that
are capable of adjusting their lighting settings.
Also, maybe now is the time to suggest standardizing some meta commands
for default lighting parameters to go with the default colors.
Don
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Joshua Delahunty wrote:
> > Most concerns
> > were [raised] about the transparent color values. Be sure we used the Shadow colors
> > provided by the LEGO Group. Shadow colors are not the RGB values used for the
> > molds but are representations of those colors used in the company's system.
> > Question is:
> >
> > Shall we restore the historical LDraw colors for the range from 0 to 50 since
> > the new colors look unnatural and washed out?
>
>
> I'm guessing that LDD looks at the transparency bit, and adjusts the colors
> accordingly so it doesn't "double whammy" the lightening of transparent colors.
> Either that logic could be moved to the apps in question (yeah, I'm laughing
> myself at such a suggestion), or the trans colors might be offset by a given
> ratio to adjust them better.
I used this calculator:
http://www.drpeterjones.com/colorcalc/
to get darker shades for the trans edges. Could you try to get a ratio that
works for the trans colors?
w.
| | | | | | | | | | | | | | | | | |
| |
Shall we restore the historical LDraw colors for the range from 0 to 50 since
the new colors look unnatural and washed out? This has to discussed before we
officially ship the new file with the 02-2009 parts update.
|
In order to add new colors to the list easily and with some officiality, it
makes good sense to follow a system like using the colors provided from the Lego
company. This is what I agreed to when creating this list of colors; as I knew
that I could simply change the RGB values for my own use.
I’m now concerned that new LDraw users may be much more turned off by these
washed out colors and will likely not continue to use LDraw. LDD is already
much more flashy and colorful than MLCAD / BrickSmith.
If the choice is still given, I’d have to stay with the historical LDraw colors
that match up with those in the LDconfig.ldr file.
Here are two examples of the washed out colors verses colors that I have been
working on; which are very similar to the historical LDraw colors:
The VW bug is a Lego Miniland design modified for the more limited orange
colors.
The Refrigerator Train Car is the great design of Cale Leiphart.
Scott
| | | | | | |
