 | | | | | |
Hi everybody!
I have a question: I regularly download official and unofficial parts update
from lDraw official site and often I found some new parts referring to colors
that are no more supported, at least if I refer to official lDraw color
definition file (LDConfig.ldr).
For example in the today updated unofficial parts definition I find reference to
color 39 that is not listed in LDConfig.ldr.
It may be i misunderstand something!! please let me know...
thanks
Sergio
| | | | | | | | | | | | | | |
In lugnet.cad, Sergio Reano wrote:
> Hi everybody!
>
> I have a question: I regularly download official and unofficial parts update
> from lDraw official site and often I found some new parts referring to colors
> that are no more supported, at least if I refer to official lDraw color
> definition file (LDConfig.ldr).
>
> For example in the today updated unofficial parts definition I find reference to
> color 39 that is not listed in LDConfig.ldr.
39 has never been an official LDraw color but a MLCad color. Parts (officials as
well as unofficials) using MLCad colors have to been recolored. A complete list
can be found here:
http://news.lugnet.com/cad/dat/parts/?n=6434
w.
| | | | | | | | | | | | | | | | | |
> 39 has never been an official LDraw color but a MLCad color. Parts (officials as
> well as unofficials) using MLCad colors have to been recolored. A complete list
> can be found here:
>
> http://news.lugnet.com/cad/dat/parts/?n=6434
BTW, could it be possible to update Parts Tracker image generator to use the new
LDConfig.ldr? Case in point http://www.ldraw.org/cgi-bin/ptdetail.cgi?s=ms1048
where the front should be trans orange (color 182), not dull grey...
Philo
| | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Willy Tschager wrote:
> In lugnet.cad, Sergio Reano wrote:
> > Hi everybody!
> >
> > I have a question: I regularly download official and unofficial parts update
> > from lDraw official site and often I found some new parts referring to colors
> > that are no more supported, at least if I refer to official lDraw color
> > definition file (LDConfig.ldr).
> >
> > For example in the today updated unofficial parts definition I find reference to
> > color 39 that is not listed in LDConfig.ldr.
>
> 39 has never been an official LDraw color but a MLCad color. Parts (officials as
> well as unofficials) using MLCad colors have to been recolored. A complete list
> can be found here:
>
> http://news.lugnet.com/cad/dat/parts/?n=6434
>
> w.
OK, understand!
So using lDraw colors is the right way for the future.
MLCad color in parts have to be fixed.
Anyway I think it should be a good practice to disallow new (official or
unofficial) parts using other than official lDraw colors.
One more thing: it is possible to distribute pre-colored/hard colored parts in
separate files other than official/unofficial ones. Or at least fix the header
file to include the 'Physical_Colour' attribute for needing files.
If anyone can do this, I can send the list of files needing the fix!
Sergio
| | | | | | | | | | | | | | | | | |
In lugnet.cad, Willy Tschager wrote:
> In lugnet.cad, Sergio Reano wrote:
> > Hi everybody!
> >
> > I have a question: I regularly download official and unofficial parts update
> > from lDraw official site and often I found some new parts referring to colors
> > that are no more supported, at least if I refer to official lDraw color
> > definition file (LDConfig.ldr).
> >
> > For example in the today updated unofficial parts definition I find reference to
> > color 39 that is not listed in LDConfig.ldr.
>
> 39 has never been an official LDraw color but a MLCad color. Parts (officials as
> well as unofficials) using MLCad colors have to been recolored. A complete list
> can be found here:
>
> http://news.lugnet.com/cad/dat/parts/?n=6434
>
> w.
Please see also the comments about this issue on
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/73435.dat
cu
mikeheide
| | | | | | | | | | | | | | | | |
In lugnet.cad, Michael Heidemann wrote:
| |
Please see also the comments about this issue on
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/73435.dat
|
The key thing I think should be brought away from those comments is the original
LDraw handling of transparent colors. Colors 32-47 are simply transparent
versions of colors 0-15. So, color 39 is a transparent version of color 7
(light gray), and color 40 is a transparent version of color 8 (dark gray).
This seems to have caused the following two problems:
- Real parts don’t come in those two colors, so one of the two needed to be picked for smoke. Prior to the creation of ldconfig.ldr, color 39 (trans light gray) was picked. (I think this is what happened; someone please correct me if I’m wrong on this.)
- When ldconfig.ldr was introduced (apparently in 2003) it included color 40, but not color 39, even though the official parts library at that time included parts using color 39, but no parts using color 40.
Personally, I’m of the opinion that the original ldconfig.ldr was at fault here,
but that doesn’t necessarily mean that color 39 should be used going forward.
The RGB values for color 40 in ldconfig.ldr are the same as for color 8 (dark
gray). Maybe those are closer to being correct than the RGB values for gray to
achieve “smoke”.
--Travis
| | | | | | | | | | | | | | | | |
In lugnet.cad, Travis Cobbs wrote:
| |
In lugnet.cad, Michael Heidemann wrote:
| |
Please see also the comments about this issue on
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/73435.dat
|
The key thing I think should be brought away from those comments is the
original LDraw handling of transparent colors. Colors 32-47 are simply
transparent versions of colors 0-15. So, color 39 is a transparent version
of color 7 (light gray), and color 40 is a transparent version of color 8
(dark gray). This seems to have caused the following two problems:
- Real parts don’t come in those two colors, so one of the two needed to be picked for smoke. Prior to the creation of ldconfig.ldr, color 39 (trans light gray) was picked. (I think this is what happened; someone please correct me if I’m wrong on this.)
- When ldconfig.ldr was introduced (apparently in 2003) it included color 40, but not color 39, even though the official parts library at that time included parts using color 39, but no parts using color 40.
|
Sorry if maybe I repeat something already said about color 39, but this is how I
recall it:
In Original LDraw, clear looked better with dithered lightgrey than white, so
James and I decided to use color 39 for window “glass”, instead of 47, which
would have been the more natural choise. We would rather look for the best
output than follow a strict protocol.
Now that noone I know of uses Original LDraw anymore, and I believe most
renderers would make better result using 47 for plastic “glass”, there is no
reason to stick to that old standard anymore.
Correct me if I’m wrong here, it was well over ten years ago...
/Tore
| | | | | | | | | | | | | | | | |
In lugnet.cad, Tore Eriksson wrote:
| |
In lugnet.cad, Travis Cobbs wrote:
| |
In lugnet.cad, Michael Heidemann wrote:
| |
Please see also the comments about this issue on
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/73435.dat
|
The key thing I think should be brought away from those comments is the
original LDraw handling of transparent colors. Colors 32-47 are simply
transparent versions of colors 0-15. So, color 39 is a transparent version
of color 7 (light gray), and color 40 is a transparent version of color 8
(dark gray). This seems to have caused the following two problems:
- Real parts don’t come in those two colors, so one of the two needed to be picked for smoke. Prior to the creation of ldconfig.ldr, color 39 (trans light gray) was picked. (I think this is what happened; someone please correct me if I’m wrong on this.)
- When ldconfig.ldr was introduced (apparently in 2003) it included color 40, but not color 39, even though the official parts library at that time included parts using color 39, but no parts using color 40.
|
Sorry if maybe I repeat something already said about color 39, but this is
how I recall it:
In Original LDraw, clear looked better with dithered lightgrey than white, so
James and I decided to use color 39 for window “glass”, instead of 47, which
would have been the more natural choise. We would rather look for the best
output than follow a strict protocol.
Now that noone I know of uses Original LDraw anymore, and I believe most
renderers would make better result using 47 for plastic “glass”, there is no
reason to stick to that old standard anymore.
|
This explains a lot of things - thx Tore for sharing. I’m going to discuss this
in the LDConfig workgroup and see if we find a solution for the problem.
w.
| | | | | | | | | | | | | | | | |
In lugnet.cad, Willy Tschager wrote:
| |
In lugnet.cad, Tore Eriksson wrote:
| |
In lugnet.cad, Travis Cobbs wrote:
| |
In lugnet.cad, Michael Heidemann wrote:
| |
Please see also the comments about this issue on
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/73435.dat
|
The key thing I think should be brought away from those comments is the
original LDraw handling of transparent colors. Colors 32-47 are simply
transparent versions of colors 0-15. So, color 39 is a transparent version
of color 7 (light gray), and color 40 is a transparent version of color 8
(dark gray). This seems to have caused the following two problems:
- Real parts don’t come in those two colors, so one of the two needed to be picked for smoke. Prior to the creation of ldconfig.ldr, color 39 (trans light gray) was picked. (I think this is what happened; someone please correct me if I’m wrong on this.)
- When ldconfig.ldr was introduced (apparently in 2003) it included color 40, but not color 39, even though the official parts library at that time included parts using color 39, but no parts using color 40.
|
Sorry if maybe I repeat something already said about color 39, but this is
how I recall it:
In Original LDraw, clear looked better with dithered lightgrey than white,
so James and I decided to use color 39 for window “glass”, instead of 47,
which would have been the more natural choise. We would rather look for the
best output than follow a strict protocol.
Now that noone I know of uses Original LDraw anymore, and I believe most
renderers would make better result using 47 for plastic “glass”, there is no
reason to stick to that old standard anymore.
|
This explains a lot of things - thx Tore for sharing. I’m going to discuss
this in the LDConfig workgroup and see if we find a solution for the problem.
|
Something to consider for the discussion; ldglite still uses dithering to
render the part images for the tracker. If for some reason you decide to
move the clear glass color from 39 to color 47, you may want to also move
the clear light grey RGB values with it. Otherwise the clear glass could
appear foggy white in the part tracker pics.
Or maybe it’s time to switch to ldview for the part tracker pictures. I
suspect the ldglite excutable used by the part tracker scripts predates the
ldglite support for LDConfig.ldr. So you probably need to do a recompile
with the current sources to see the expected results in the tracker pictures
after moving all the colors around. Since a recompile may be needed, why not
build an ldview executable instead?
Have fun,
Don
| | | | | | | | | | | | | | | | |
In lugnet.cad, Don Heyse wrote:
> Or maybe it's time to switch to ldview for the part tracker pictures. I
> suspect the ldglite excutable used by the part tracker scripts predates the
> ldglite support for LDConfig.ldr. So you probably need to do a recompile
> with the current sources to see the expected results in the tracker pictures
> after moving all the colors around. Since a recompile may be needed, why not
> build an ldview executable instead?
Travis has worked on a switch after this post:
http://news.lugnet.com/cad/?n=14787&t=i&v=a
but I do not remember why there was no happy ending.
w.
| | | | | | | | | | | | | | | | | |
In lugnet.cad, Willy Tschager wrote:
> In lugnet.cad, Don Heyse wrote:
> > Or maybe it's time to switch to ldview for the part tracker pictures. I
> > suspect the ldglite excutable used by the part tracker scripts predates the
> > ldglite support for LDConfig.ldr. So you probably need to do a recompile
> > with the current sources to see the expected results in the tracker pictures
> > after moving all the colors around. Since a recompile may be needed, why not
> > build an ldview executable instead?
>
> Travis has worked on a switch after this post:
>
> http://news.lugnet.com/cad/?n=14787&t=i&v=a
>
> but I do not remember why there was no happy ending.
I created a command line-only version of LDView and got it built on the peeron
server, but nobody took the next step of creating a new LDView-based image
generation script. I'd be happy to help out anyone who has the access to do
this and is willing to do so; LDView itself should be ready.
--Travis
| | | | | | | | | | | | | | | | | |
In lugnet.cad, Willy Tschager wrote:
> In lugnet.cad, Don Heyse wrote:
> > Or maybe it's time to switch to ldview for the part tracker pictures. I
> > suspect the ldglite excutable used by the part tracker scripts predates the
> > ldglite support for LDConfig.ldr. So you probably need to do a recompile
> > with the current sources to see the expected results in the tracker pictures
> > after moving all the colors around. Since a recompile may be needed, why not
> > build an ldview executable instead?
>
> Travis has worked on a switch after this post:
>
> http://news.lugnet.com/cad/?n=14787&t=i&v=a
>
> but I do not remember why there was no happy ending.
>
> w.
If anyone interested, my application (SR 3D Builder) can generate parts images
based on the contents of a text files or taking the single image directly from
the screen.
It generates the images for itself, but anybody can use them for any purpose,
included part tracker
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Sergio Reano wrote:
> In lugnet.cad, Willy Tschager wrote:
> > In lugnet.cad, Don Heyse wrote:
> > > Or maybe it's time to switch to ldview for the part tracker pictures. I
> > > suspect the ldglite excutable used by the part tracker scripts predates the
> > > ldglite support for LDConfig.ldr. So you probably need to do a recompile
> > > with the current sources to see the expected results in the tracker pictures
> > > after moving all the colors around. Since a recompile may be needed, why not
> > > build an ldview executable instead?
> >
> > Travis has worked on a switch after this post:
> >
> > http://news.lugnet.com/cad/?n=14787&t=i&v=a
> >
> > but I do not remember why there was no happy ending.
> >
> > w.
>
> If anyone interested, my application (SR 3D Builder) can generate parts images
> based on the contents of a text files or taking the single image directly from
> the screen.
> It generates the images for itself, but anybody can use them for any purpose,
> included part tracker
But if I've understood correctly, the Peeron server is a *nix box and
sr3dbuilder is Windows-only. So it can't work on the parts tracker unless it
comes to support *nix too.
Would the swich to LDView give a fix to the part images not properly generating
on the PT? At some times the picture comes out uncomplete and sometimes
unrefreshed..
| | | | | | | | | | | | | | | | |
In lugnet.cad, Santeri Piippo wrote:
> Would the swich to LDView give a fix to the part images not properly generating
> on the PT? At some times the picture comes out uncomplete and sometimes
> unrefreshed..#
That's nothing to do with the rendering software, it's due to overload on the
webserver, causing the script that queues the rendering request to fail.
I requeue them manually when I notice.
Chris
| | | | | | |
