| |
Hi,
I have some questions about all those colors.
I am using BrickSmith on Mac, I do not know if MLCAD does offer more colors.
Bricksmith is missing the newer transparent dark orange and medium blue colors
and some rarely used solid ones as bluish light grey, maersk blue, medium blue,
light lime, very light orange, flesh tones.
I did a model containing all colors in BrickSmith:
http://www.brickshelf.com/gallery/LGEO/colors/picture_3.png
you can download the model file:
http://www.brickshelf.com/gallery/LGEO/colors/colors.ldr
Exported with L3P and the LGEO option, it renders like this:
http://www.brickshelf.com/gallery/LGEO/colors/colors.png
Lost by the conversion are the pearl colors (upper corner), new bluish greys and
reddish brown. very light grey becomes chrome silver and dark orange renders
chrome gold.
Is there any comittee organizing colors? I think we should have a list where
each color ever produced (best source for color catalog is BrickLink, I think)
is assigned to a color number? This would help programmers of the CAD programs
as the users when using more uncommon colors. (Ok, the discussion of color names
itself is an issue of its own...)
Lutz
|
|
| |
In lugnet.cad, Lutz Uhlmann wrote:
| |
Hi,
I have some questions about all those colors.
I am using BrickSmith on Mac, I do not know if MLCAD does offer more colors.
Bricksmith is missing the newer transparent dark orange and medium blue colors
and some rarely used solid ones as bluish light grey, maersk blue, medium
blue, light lime, very light orange, flesh tones.
|
I think it would be nice if Bricksmith read the ldconfig.ldr file to load color
definitions, or if it offered a pane in the preferences or color picker to
define new colors. Best of all, if it had an interface like that to read and
update ldconfig.ldr.
| |
I did a model containing all colors in BrickSmith:
http://www.brickshelf.com/gallery/LGEO/colors/picture3.png
you can download the model file:
http://www.brickshelf.com/gallery/LGEO/colors/colors.ldr
Exported with L3P and the LGEO option, it renders like this:
http://www.brickshelf.com/gallery/LGEO/colors/colors.png
Lost by the conversion are the pearl colors (upper corner), new bluish greys
and reddish brown. very light grey becomes chrome silver and dark orange
renders chrome gold.
|
I’ve noticed the same problem when trying to render some of my models, where L3P
does not recognize the newer color code and uses default gray instead. Unless it
is possible to make L3P read ldconfig.ldr as well, I think the only solution is
to replace the color codes it doesn’t know with hexadecimal color
specifications. For example, replace 134 (Pearl Copper) with 0x02938767,
where 938767 is the RRGGBB color for Pearl Copper defined in ldconfig.ldr
and 0x02 is the opaque prefix described in
this post (0x03 gives transparent
colors). I use this format to get truecolor in Bitsticker. I have also
considered writing a filter script to translate any of these unknown color codes
to hex colors so that they can be rendered accurately with L3P and POVray.
Incidentally, have you noticed that only parts listed earlier in the file are
visible through transparent parts in Bricksmith? I’m not sure if this is
conventional LDraw behavior or if it is just due to how Bricksmith renders
things, but when possible I have started putting transparent parts (such as
canopies and windows) as the last parts in the file just so I can be sure to see
everything through them. I posted simple examples
here and
here.
| |
Is there any comittee organizing colors? I think we should have a list where
each color ever produced (best source for color catalog is BrickLink, I think)
is assigned to a color number? This would help programmers of the CAD programs
as the users when using more uncommon colors. (Ok, the discussion of color
names itself is an issue of its own...)
|
I think this is a good point. I like to use actual part colors as much as
possible when modeling in LDraw, but I’ve found the support for different colors
to vary from tool to tool. Something like ldconfig.ldr seems like a good place
to make standard colors definition that can be updated regularly without
requiring separate program updates. In fact it is described in the
color extension specification, so it seems
like a reasonable basis for this idea. If support for this file is widespread
(I’m not sure if it is), I suppose the question is how are additions to this
file approved and distributed? Perhaps this is answered elsewhere, but I ask in
order to emphasize Lutz’ point that in reality there is a lot of variation in
how colors (as hue definitions - I’m not so concerned with names) are handled
throughout the LDraw system.
Jim
|
|
| |
In lugnet.cad, Lutz Uhlmann wrote:
> Hi,
Hi Lutz, most excellent to see some questions from you; it's been a long time
since we've conversed.
> I have some questions about all those colors.
> I am using BrickSmith on Mac, I do not know if MLCAD does offer more colors.
> Bricksmith is missing the newer transparent dark orange and medium blue colors
> and some rarely used solid ones as bluish light grey, maersk blue, medium blue,
> light lime, very light orange, flesh tones.
>
> I did a model containing all colors in BrickSmith:
> http://www.brickshelf.com/gallery/LGEO/colors/picture_3.png
>
> you can download the model file:
> http://www.brickshelf.com/gallery/LGEO/colors/colors.ldr
>
> Exported with L3P and the LGEO option, it renders like this:
> http://www.brickshelf.com/gallery/LGEO/colors/colors.png
>
> Lost by the conversion are the pearl colors (upper corner), new bluish greys and
> reddish brown. very light grey becomes chrome silver and dark orange renders
> chrome gold.
>
> Is there any comittee organizing colors? I think we should have a list where
> each color ever produced (best source for color catalog is BrickLink, I think)
> is assigned to a color number? This would help programmers of the CAD programs
> as the users when using more uncommon colors. (Ok, the discussion of color names
> itself is an issue of its own...)
The LDRAW "group" (if you will) has created a color standard in ldconfig.ldr, a
text file describing common settings to be used by LDRAW utilities (the color
table, at this point). So far, few programs have supported it, with L3P and
LDView being notable exceptions.
MLCAD and LeoCAD being too applications that (IMHO) sorely need support.
I was getting ready to add support for it to ldglite* when I found LDView, and
haven't looked back. I would have recommended LDView to you for your (separate)
instruction-step query, but LDView doesn't (yet) support STEPs in models, it's
an all or nothing viewer. Other than that, it's extremely full featured
(including possible overkill in some areas -- Stereo imagery, for instance
:wink:) It's replaced ldglite for me for all tasks.
Anyway, back to ldconfig.ldr...
A bit more info can be found here:
http://www.ldraw.org/modules.php?op=modload&name=News&file=article&sid=299
and here:
http://news.lugnet.com/cad/mlcad/?n=2162
But basically it's an external way to define how colors are named and used.
I am currently working on a version of ldconfig.ldr that has the official
numbers (where they don't conflict with existing numbers), names, and RGB
values. I should be done in the next week or so, and I'll see about convincing
the ldraw.org folks to host it as an "alternative" ldconfig.ldr file. (Either
way, I'll be hosted it next to my color chart doc at
http://alumni.cse.ucsc.edu/~dulcaoin/LEGO/LEGO-Color-Chart.pdf)
I really wish a comment indicator such as // had been added to the format, but I
haven't seen one; that would have allowed some nice commentary when I changed
names to match LDRAW usage, but I haven't such a syntax presented.
Hopefully, this will address some of your issues? The next steps would be
getting ldconfig.ldr support into MLCAD and LeoCAD.
-- joshua
* not that I'm in any way in charge of ldglite; this would have been a side
personal project
|
|
| |
--snip--
> The LDRAW "group" (if you will) has created a color standard in ldconfig.ldr, a
> text file describing common settings to be used by LDRAW utilities (the color
> table, at this point). So far, few programs have supported it, with L3P and
> LDView being notable exceptions.
L3p doesn't support it as far as I can tell... in fact L3P refuses to give bley
or dark bley any colour at all.
--snip--
Tim
|
|
| |
In lugnet.cad, Timothy Gould wrote:
> > The LDRAW "group" (if you will) has created a color standard in ldconfig.ldr, a
> > text file describing common settings to be used by LDRAW utilities (the color
> > table, at this point). So far, few programs have supported it, with L3P and
> > LDView being notable exceptions.
>
> L3p doesn't support it as far as I can tell... in fact L3P refuses to give bley
> or dark bley any colour at all.
Correct. As I noted in my other reply, the only way I've been able to render
those colors (and a few others) with L3P/POV-ray is to replace the color codes
with their 0x02RRGGBB style equivalents, and that's not really the most
desirable solution.
Jim
|
|
| |
In lugnet.cad, Timothy Gould wrote:
> --snip--
>
> > The LDRAW "group" (if you will) has created a color standard in ldconfig.ldr, a
> > text file describing common settings to be used by LDRAW utilities (the color
> > table, at this point). So far, few programs have supported it, with L3P and
> > LDView being notable exceptions.
>
> L3p doesn't support it as far as I can tell... in fact L3P refuses to give bley
> or dark bley any colour at all.
My apologies if true. I was going off Steve's assertion in the LUGNET posting I
linked to -- I haven't used L3P myself (only LDView).
-- joshua
|
|
| |
In lugnet.cad, Jim DeVona wrote:
> In lugnet.cad, Timothy Gould wrote:
>
> > > The LDRAW "group" (if you will) has created a color standard in ldconfig.ldr, a
> > > text file describing common settings to be used by LDRAW utilities (the color
> > > table, at this point). So far, few programs have supported it, with L3P and
> > > LDView being notable exceptions.
> >
> > L3p doesn't support it as far as I can tell... in fact L3P refuses to give bley
> > or dark bley any colour at all.
>
> Correct. As I noted in my other reply, the only way I've been able to render
> those colors (and a few others) with L3P/POV-ray is to replace the color codes
> with their 0x02RRGGBB style equivalents, and that's not really the most
> desirable solution.
>
> Jim
I find it easier just to use a different colour for bleys so I can set it up
properly in a povray include file. I always use 263 for dark bley but don't yet
have a standard for light bley.
Tim
|
|
| |
In lugnet.cad, Joshua Delahunty wrote:
> ...
>
> I was getting ready to add support for it to ldglite* when I found LDView, and
> haven't looked back. I would have recommended LDView to you for your (separate)
> instruction-step query, but LDView doesn't (yet) support STEPs in models, it's
> an all or nothing viewer. Other than that, it's extremely full featured
> (including possible overkill in some areas -- Stereo imagery, for instance
> :wink:) It's replaced ldglite for me for all tasks.
Actually, in conjunction with Bricksmith's "Export Steps" option, LDView could
be used to render each step (since each step is exported as a separate file). As
recently discussed here, it is possible to run the current version of LDView on
your Mac, too - but that's a work in progress.
> ...
>
> I really wish a comment indicator such as // had been added to the format, but I
> haven't seen one; that would have allowed some nice commentary when I changed
> names to match LDRAW usage, but I haven't such a syntax presented.
Technically, doesn't "0" mark an LDraw comment anyway? Of course, it is used for
all kinds of meta commands and standard header fields, but if you place the
comment after any headers and start it with something that's not a meta command
- such as "//" - shouldn't that be valid?
Jim
|
|
| |
In lugnet.cad, Timothy Gould wrote:
> > > ...
> > >
> > > L3p doesn't support it as far as I can tell... in fact L3P refuses to give bley
> > > or dark bley any colour at all.
> >
> > Correct. As I noted in my other reply, the only way I've been able to render
> > those colors (and a few others) with L3P/POV-ray is to replace the color codes
> > with their 0x02RRGGBB style equivalents, and that's not really the most
> > desirable solution.
> >
> > Jim
>
> I find it easier just to use a different colour for bleys so I can set it up
> properly in a povray include file. I always use 263 for dark bley but don't yet
> have a standard for light bley.
Neat. Can you explain what you mean by povray include file? A separate file from
the model generated by L3P, that contains color definitions? How do you prevent
L3P from replacing your custom colors with the default gray, as it does with
other colors it doesn't already recognize?
I like the idea of sticking with whatever code is commonly assigned to a color
(such as 72 for "bley," I believe) so that it looks right in any programs that
do know that color.
I'm all for good solutions, though!
Jim
|
|
| |
In lugnet.cad, Jim DeVona wrote:
> In lugnet.cad, Timothy Gould wrote:
>
> > > > ...
> > > >
> > > > L3p doesn't support it as far as I can tell... in fact L3P refuses to give bley
> > > > or dark bley any colour at all.
> > >
> > > Correct. As I noted in my other reply, the only way I've been able to render
> > > those colors (and a few others) with L3P/POV-ray is to replace the color codes
> > > with their 0x02RRGGBB style equivalents, and that's not really the most
> > > desirable solution.
> > >
> > > Jim
> >
> > I find it easier just to use a different colour for bleys so I can set it up
> > properly in a povray include file. I always use 263 for dark bley but don't yet
> > have a standard for light bley.
>
> Neat. Can you explain what you mean by povray include file? A separate file from
> the model generated by L3P, that contains color definitions? How do you prevent
> L3P from replacing your custom colors with the default gray, as it does with
> other colors it doesn't already recognize?
>
> I like the idea of sticking with whatever code is commonly assigned to a color
> (such as 72 for "bley," I believe) so that it looks right in any programs that
> do know that color.
>
> I'm all for good solutions, though!
>
> Jim
Well the problem with bleys is that L3P doesn't just replace them, it deletes
them. Fortunately it doesn't seem to have this problem with parts in colours
greater than or equal to 256.
Fortunately, l3p colour definitions check to make sure the colour isn't already
defined. As such if you include a file with your own custom definitions before
the first colour is defined by l3p (I always add the call to the include file
after the AMB and DIF definitions) then it will use your colours rather than its
own.
Tim
|
|
| |
In lugnet.cad, Jim DeVona wrote:
> In lugnet.cad, Joshua Delahunty wrote:
>
> > ...
> >
> > I was getting ready to add support for it to ldglite* when I found LDView, and
> > haven't looked back. I would have recommended LDView to you for your (separate)
> > instruction-step query, but LDView doesn't (yet) support STEPs in models, it's
> > an all or nothing viewer. Other than that, it's extremely full featured
> > (including possible overkill in some areas -- Stereo imagery, for instance
> > :wink:) It's replaced ldglite for me for all tasks.
>
> Actually, in conjunction with Bricksmith's "Export Steps" option, LDView could
> be used to render each step (since each step is exported as a separate file). As
> recently discussed here, it is possible to run the current version of LDView on
> your Mac, too - but that's a work in progress.
Then I would definitely recommend LDView for the rendering chain. I've recently
used it to create a set of part images (as I used to use ldglite) for the entire
library, and they are FAN-TAB-u-Glorious!
Travis has been very helpful, and even added some features to the UNRELEASED*
3.2 (which is unreleased, has no announced release date, and still "in Alpha"
status) I asked for, with a day's turn-around. Fixed some defects I've found,
too. I can't praise LDView enough...
> > ...
> >
> > I really wish a comment indicator such as // had been added to the format, but I
> > haven't seen one; that would have allowed some nice commentary when I changed
> > names to match LDRAW usage, but I haven't such a syntax presented.
>
> Technically, doesn't "0" mark an LDraw comment anyway? Of course, it is used for
> all kinds of meta commands and standard header fields, but if you place the
> comment after any headers and start it with something that's not a meta command
> - such as "//" - shouldn't that be valid?
I wanted something for end-of-line comments, rather than having to place
comments every-other-line (which is what I ended up doing -- I've spent some
time on this project today after posting that it was forthcoming)
something like...
0 !COLOUR Black CODE 0 VALUE #1b234 EDGE 0 // TLG: 26
which would show that the TLG code for Black is 26 (the LDRAW code is 0)
instead, I had to (I believe) go with:
0 TLG: 26
0 !COLOUR Black CODE 0 VALUE #1b2a34 EDGE 0
0 TLG: 23
0 !COLOUR Bright_Blue CODE 1 VALUE #0d69a8 EDGE 0
(bleh)
-- joshua
* SCREAMED to make it clear there's no LDView 3.2 downloadable yet, so no one
wastes time looking.
|
|
| |
In lugnet.cad, Joshua Delahunty wrote:
> Travis has been very helpful, and even added some features to the UNRELEASED*
> 3.2 (which is unreleased, has no announced release date, and still "in Alpha"
> status) I asked for, with a day's turn-around. Fixed some defects I've found,
> too. I can't praise LDView enough...
> ...
> * SCREAMED to make it clear there's no LDView 3.2 downloadable yet, so no one
> wastes time looking.
I've been making an effort recently to demonstrate that LDView (including the
development version, 3.2) will work on the Mac. Although LDView 3.2 itself is,
as you emphasize, unreleased, the source code is available, so I've been trying
to help Travis work out some of the kinks with it on the Mac. I agree that it's
a great program and that he's doing a great job with it.
Anyway, my point is that people who are particularly interested in it - and who
may have any helpful expertise - are probably welcome to download the latest
code (Travis' site explains how), try to build it, and see how it works, as long
as they do understand that it is indeed a work in progress.
> > > I really wish a comment indicator such as // had been added to the format, but I
> > > haven't seen one; that would have allowed some nice commentary when I changed
> > > names to match LDRAW usage, but I haven't such a syntax presented.
> >
> > Technically, doesn't "0" mark an LDraw comment anyway? Of course, it is used for
> > all kinds of meta commands and standard header fields, but if you place the
> > comment after any headers and start it with something that's not a meta command
> > - such as "//" - shouldn't that be valid?
>
> I wanted something for end-of-line comments, rather than having to place
> comments every-other-line (which is what I ended up doing -- I've spent some
> time on this project today after posting that it was forthcoming)
>
> something like...
>
> 0 !COLOUR Black CODE 0 VALUE #1b234 EDGE 0 // TLG: 26
Ah, I see. Yeah, that is more compact.
Jim
|
|
| |
In lugnet.cad, Timothy Gould wrote:
| |
Well the problem with bleys is that L3P doesn’t just replace them, it deletes
them. Fortunately it doesn’t seem to have this problem with parts in colours
greater than or equal to 256.
|
You mean that a color 71 or 72 brick goes into
L3P and nothing comes out? Unless I’ve got the wrong grey (quite possible; bley
genealogy bores me), L3P complains and applies the default color, but it doesn’t
remove the the part from the scene.
For example: bleysandwich.ldr,
bleysandwich.pov,
bleysandwich.png
The bricks are rendered in plain old grey, but they’re still there.
What have I missed? (Just trying to grok as many LDraw tools as I can.)
Jim
|
|
| |
In lugnet.cad, Jim DeVona wrote:
| |
In lugnet.cad, Timothy Gould wrote:
| |
Well the problem with bleys is that L3P doesn’t just replace them, it
deletes them. Fortunately it doesn’t seem to have this problem with parts in
colours greater than or equal to 256.
|
You mean that a color 71 or 72 brick goes
into L3P and nothing comes out? Unless I’ve got the wrong grey (quite
possible; bley genealogy bores me), L3P complains and applies the default
color, but it doesn’t remove the the part from the scene.
For example:
bleysandwich.ldr,
bleysandwich.pov,
bleysandwich.png
The bricks are rendered in plain old grey, but they’re still there.
What have I missed? (Just trying to grok as many LDraw tools as I can.)
Jim
|
Ahhhh. My apologies. It’s been ages since I tried so that is probably what
happened.
The end result is that I can’t apply my own bley definitions (yes the numbers
are right) which is probably why I thought they were deleted.
Tim
|
|
| |
In lugnet.cad, Joshua Delahunty wrote:
> In lugnet.cad, Timothy Gould wrote:
> > L3p doesn't support it as far as I can tell... in fact L3P refuses to give bley
> > or dark bley any colour at all.
>
> My apologies if true. I was going off Steve's assertion in the LUGNET posting I
> linked to -- I haven't used L3P myself (only LDView).
I believe that the (now nearly mythical) "next version" of L3P has been
announced to support ldconfig.ldr.
--Travis
|
|
|
