| | | | |
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 dont 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 Im 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. Im 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 its 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
| | | | | | |