| |
In lugnet.cad, Philippe Hurbain wrote:
> Case in point, http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/58119.dat where
> Medium Stone and Dark Stone appear the same...
That's a good question. The Parts Tracker probably doesn't use ldconfig.ldr,
because the image-generator uses a custom script to maintain a combined library
of official & unofficial files, which predates ldconfig.ldr.
I'm also not sure the version of ldglite we've installed is recent enough to
support ldconfig.ldr.
I'll look into the issue.
Steve
|
|
| |
In lugnet.cad, Steve Bliss wrote:
| |
In lugnet.cad, Philippe Hurbain wrote:
| |
Case in point, http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/58119.dat
where Medium Stone and Dark Stone appear the same...
|
That’s a good question. The Parts Tracker probably doesn’t use ldconfig.ldr,
because the image-generator uses a custom script to maintain a combined
library of official & unofficial files, which predates ldconfig.ldr.
I’m also not sure the version of ldglite we’ve installed is recent enough to
support ldconfig.ldr.
I’ll look into the issue.
Steve
|
consider also a switch to LDView as rendering engine; it does a fine job for
the MOTM:
w.
|
|
| |
In lugnet.cad, Willy Tschager wrote:
| |
In lugnet.cad, Steve Bliss wrote:
| |
In lugnet.cad, Philippe Hurbain wrote:
| |
Case in point, http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/58119.dat
where Medium Stone and Dark Stone appear the same...
|
That’s a good question. The Parts Tracker probably doesn’t use
ldconfig.ldr, because the image-generator uses a custom script to maintain a
combined library of official & unofficial files, which predates
ldconfig.ldr.
I’m also not sure the version of ldglite we’ve installed is recent enough to
support ldconfig.ldr.
I’ll look into the issue.
Steve
|
consider also a switch to LDView as rendering engine; it does a fine job for
the MOTM:
|
Yeah, it might be time to make the switch. Ldglite has never been updated
to use ldconfig.ldr (although it probably wouldn’t difficult). It currently
only supports the older ldlite config file ldliterc.dat with ldlite
COLOR metacommands to redefine the colors. For a while there were some
up to date versions of that file kicking around here.
I don’t remember what platform the scripts run on. Was it BSD with OSMesa
for the opengl support? It might be a little bit of work to build an ldview
executable to run on that, but shouldn’t be too hard. You’ll want to track
the resource usage though. With an automated background process, you don’t
want to use up everything and bring the web server and such to a halt while
rendering.
Don
|
|
| |
In lugnet.cad, Willy Tschager wrote:
> consider also a switch to LDView as rendering engine; it does a fine job for
> the MOTM
I missed that one. We've got ldview installed on the server?
Hmm...
Steve
|
|
| |
In lugnet.cad, Steve Bliss wrote:
> In lugnet.cad, Willy Tschager wrote:
> > consider also a switch to LDView as rendering engine; it does a fine job for
> > the MOTM
>
> I missed that one. We've got ldview installed on the server?
If you don't (and I suspect that you don't), I'd be happy to help you compile it
there (assuming the binaries don't work), but there's a significant catch. Even
when rendering snapshots from the command line, it currently still requires a
connection to an X server's display. That's kind of a problem for background
tasks.
An OSMesa version could probably be made as Don suggests, but I don't know at
this point what the level of difficulty would be in doing that. It could
potentially be quite high.
--Travis
|
|
| |
In lugnet.cad, Travis Cobbs wrote:
> In lugnet.cad, Steve Bliss wrote:
> > In lugnet.cad, Willy Tschager wrote:
> > > consider also a switch to LDView as rendering engine; it does a fine job for
> > > the MOTM
> >
> > I missed that one. We've got ldview installed on the server?
>
> If you don't (and I suspect that you don't), I'd be happy to help you compile it
> there (assuming the binaries don't work), but there's a significant catch. Even
> when rendering snapshots from the command line, it currently still requires a
> connection to an X server's display. That's kind of a problem for background
> tasks.
>
> An OSMesa version could probably be made as Don suggests, but I don't know at
> this point what the level of difficulty would be in doing that. It could
> potentially be quite high.
That's unfortunate (but what I thought I remembered). I didn't have a lot of
luck updating the ldliterc.dat file used by the PT. Even after regenerating all
the unofficial part images, 58119's image is still incorrect.
I'll have to mess with it some more, hopefully I'll have time this evening.
Steve
|
|
| |
In lugnet.cad, Steve Bliss wrote:
> In lugnet.cad, Travis Cobbs wrote:
> > In lugnet.cad, Steve Bliss wrote:
> > > In lugnet.cad, Willy Tschager wrote:
> > > > consider also a switch to LDView as rendering engine; it does a fine job for
> > > > the MOTM
> > >
> > > I missed that one. We've got ldview installed on the server?
> >
> > If you don't (and I suspect that you don't), I'd be happy to help you compile it
> > there (assuming the binaries don't work), but there's a significant catch. Even
> > when rendering snapshots from the command line, it currently still requires a
> > connection to an X server's display. That's kind of a problem for background
> > tasks.
> >
> > An OSMesa version could probably be made as Don suggests, but I don't know at
> > this point what the level of difficulty would be in doing that. It could
> > potentially be quite high.
>
> That's unfortunate (but what I thought I remembered). I didn't have a lot of
> luck updating the ldliterc.dat file used by the PT. Even after regenerating all
> the unofficial part images, 58119's image is still incorrect.
>
> I'll have to mess with it some more, hopefully I'll have time this evening.
>
> Steve
steve,
any updates on this? BTW, did you get my request to use LDAO in the
All-In-One-Installer or has it been eaten up by your spam-monster?
w.
|
|
| |
Hello Steve,
> That's unfortunate (but what I thought I remembered). I didn't have a lot of
> luck updating the ldliterc.dat file used by the PT. Even after regenerating all
> the unofficial part images, 58119's image is still incorrect.
>
> I'll have to mess with it some more, hopefully I'll have time this evening.
Any news about this? I have submitted a new part with the same color scheme
(http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/58121.dat), problem remains
:-(
Philo
|
|
| |
In lugnet.cad, Philippe Hurbain wrote:
> Hello Steve,
>
> > That's unfortunate (but what I thought I remembered). I didn't have a lot of
> > luck updating the ldliterc.dat file used by the PT. Even after regenerating all
> > the unofficial part images, 58119's image is still incorrect.
> >
> > I'll have to mess with it some more, hopefully I'll have time this evening.
>
> Any news about this? I have submitted a new part with the same color scheme
> (http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/58121.dat), problem remains
> :-(
Nope, sorry. No update. As far as I can tell, ldglite[1] won't recognize
colors like 71 and 72.
--
Steve
1) At least, the ldglite binary on the server.
|
|
| |
In lugnet.cad, Steve Bliss wrote:
> In lugnet.cad, Philippe Hurbain wrote:
> > Hello Steve,
> >
> > > That's unfortunate (but what I thought I remembered). I didn't have a lot of
> > > luck updating the ldliterc.dat file used by the PT. Even after regenerating all
> > > the unofficial part images, 58119's image is still incorrect.
> > >
> > > I'll have to mess with it some more, hopefully I'll have time this evening.
> >
> > Any news about this? I have submitted a new part with the same color scheme
> > (http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/58121.dat), problem remains
> > :-(
>
> Nope, sorry. No update. As far as I can tell, ldglite[1] won't recognize
> colors like 71 and 72.
than we should start thinking about the switch to LDView as render engine ... if
this is technically doable. to be frank I didn't understand a single word from
all the tech speech above: x server or not, OSMesa a mess ... Travis, I guess
you need server access to answer my questions?
w.
ps. steve, did you get my request for the all-in-on permission or have my mails
been eaten up by your spam monster?
|
|
| |
In lugnet.cad, Steve Bliss wrote:
> In lugnet.cad, Philippe Hurbain wrote:
> > Hello Steve,
> >
> > > That's unfortunate (but what I thought I remembered). I didn't
> > > have a lot of luck updating the ldliterc.dat file used by the PT.
> > > Even after regenerating all the unofficial part images, 58119's
> > > image is still incorrect.
> > >
> > > I'll have to mess with it some more, hopefully I'll have time
> > > this evening.
> >
> > Any news about this? I have submitted a new part with the same color
> > scheme (http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/58121.dat),
> > problem remains
> > :-(
>
> Nope, sorry. No update. As far as I can tell, ldglite[1] won't
> recognize colors like 71 and 72.
While I agree with Willy's assessment that it may be time
to move on to ldview for the part tracker, I did run a quick test
and it looks like ldglite does support modified colors like 71
or 72 with the ldliterc.dat file. Perhaps the location of the
ldliterc.dat file could be the problem. I checked the docs for
the ldlite parser:
http://ldlite.sourceforge.net/
It only uses the file if it's in the current working directory
when you run the program. If you're not sure where that is, you can
find out by adding something like this to the script before the call
to ldglite.
echo $PWD >/tmp/path.txt
There's a good chance it's the home directory of the user that
the script is run by.
If the script uses the l3 parser (-l3 on the command line), I had
more control over the code and allowed the ldliterc.dat file to
be located in any of the places it looks for ldraw files. So for
example, you could put it in LDRAWDIR/models.
Of course it's possible that the version of ldglite built for
parts tracker is so old it predates any of this...
Have fun,
Don
|
|
| |
In lugnet.cad, Don Heyse wrote:
> While I agree with Willy's assessment that it may be time
> to move on to ldview for the part tracker, I did run a quick test
> and it looks like ldglite does support modified colors like 71
> or 72 with the ldliterc.dat file. Perhaps the location of the
> ldliterc.dat file could be the problem. I checked the docs for
> the ldlite parser:
>
> http://ldlite.sourceforge.net/
>
> It only uses the file if it's in the current working directory
> when you run the program.
Oooo! Thanks for mentioning this. I had forgotten about it, as if I never knew
it.
After messing around, I (manually) got the image for 58119.dat straightened out
<http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/58119.dat>
But I haven't convinced the script that it should run this way. Yet.
If the image for part 58119 is still wrong when you look at it, I've probably
re-overwritten the image file, trying to get the script to work right.
Steve
|
|
| |
In lugnet.cad, Steve Bliss wrote:
> After messing around, I (manually) got the image for 58119.dat straightened out
> <http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/58119.dat>
>
> But I haven't convinced the script that it should run this way. Yet.
OK, that wasn't so hard. The script should be fixed now. I've pushed through
re-renders for 58119 and x919. All other parts are queued for re-rendering, all
images should be updated in a short time.
If anyone wants to look at the ldliterc.dat file, you can grab a copy at
http://www.ldraw.org/library/unofficial/ldliterc.dat
Steve
|
|
| |
In lugnet.cad, Willy Tschager wrote:
> than we should start thinking about the switch to LDView as render engine ... if
> this is technically doable. to be frank I didn't understand a single word from
> all the tech speech above: x server or not, OSMesa a mess ... Travis, I guess
> you need server access to answer my questions?
I would need access to the server, yes. I think that if Xvnc were installed on
the server, LDView could connect to that, and everything would then be happy.
(Xvnc is an X Server that's designed to be connected to remotely via vnc. From
LDView's point of view, there would then be an X server, but Xvnc doesn't use a
local screen at all, so the web server is still happy.)
--Travis
|
|
| |
In lugnet.cad, Steve Bliss wrote:
> In lugnet.cad, Steve Bliss wrote:
> > After messing around, I (manually) got the image for 58119.dat
> > straightened out
> > <http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/58119.dat>
> >
> > But I haven't convinced the script that it should run this way. Yet.
>
> OK, that wasn't so hard. The script should be fixed now. I've pushed
> through > re-renders for 58119 and x919. All other parts are queued
> for re-rendering, all images should be updated in a short time.
>
> If anyone wants to look at the ldliterc.dat file, you can grab a copy at
> http://www.ldraw.org/library/unofficial/ldliterc.dat
It looks like you have a bug in whatever program you're using to
convert ldconfig.ldr to ldliterc.dat.
In the first set of colors on each line the blue value always
seems to be the same as the green value.
Don
|
|
| |
In lugnet.cad, Travis Cobbs wrote:
> I would need access to the server, yes. I think that if Xvnc were installed on
> the server, LDView could connect to that, and everything would then be happy.
> (Xvnc is an X Server that's designed to be connected to remotely via vnc. From
> LDView's point of view, there would then be an X server, but Xvnc doesn't use a
> local screen at all, so the web server is still happy.)
I just did a quick check on my own Linux box (a virtual machine, actually) with
xvfb (X Virtual Frame Buffer), and that worked fine with LDView. Since xvfb is
a standard part of the X distribution, it should be easy to install on most
major *nix distributions. Installation of xvfb might have to be done by an
admin, though.
--Travis
|
|
| |
In lugnet.cad, Don Heyse wrote:
> It looks like you have a bug in whatever program you're using to
> convert ldconfig.ldr to ldliterc.dat.
"Program"? I wish. It was a manual conversion, not all of the entries are
amenable to programmatic conversion.
> In the first set of colors on each line the blue value always
> seems to be the same as the green value.
Doh! It should be fixed now, take a look.
No wonder the orange switch on the PF box looked so odd...
Steve
|
|
| |
In lugnet.cad, Steve Bliss wrote:
> In lugnet.cad, Don Heyse wrote:
> > It looks like you have a bug in whatever program you're using to
> > convert ldconfig.ldr to ldliterc.dat.
>
> "Program"? I wish. It was a manual conversion, not all of the entries are
> amenable to programmatic conversion.
>
> > In the first set of colors on each line the blue value always
> > seems to be the same as the green value.
>
> Doh! It should be fixed now, take a look.
>
> No wonder the orange switch on the PF box looked so odd...
I could probably whip up a program that does the conversion fairly quickly (hour
or two of work?) if you're interested. I have the advantage that I already have
a full parser for ldconfig.ldr. Spitting out the ldliterc.dat file should be
straightforward.
--Travis
|
|
| |
In lugnet.cad, Travis Cobbs wrote:
> In lugnet.cad, Travis Cobbs wrote:
> > I would need access to the server, yes. I think that if Xvnc were
> > installed on the server, LDView could connect to that, and everything
> > would then be happy. (Xvnc is an X Server that's designed to be
> > connected to remotely via vnc. From LDView's point of view, there
> > would then be an X server, but Xvnc doesn't use a local screen at
> > all, so the web server is still happy.)
>
> I just did a quick check on my own Linux box (a virtual machine,
> actually) with xvfb (X Virtual Frame Buffer), and that worked fine
> with LDView. Since xvfb is a standard part of the X distribution,
> it should be easy to install on most major *nix distributions.
> Installation of xvfb might have to be done by an admin, though.
Yeah we experimented with xvfb many years ago.
http://news.lugnet.com/cad/dev/?n=6478
There was some weirdness with the aspect ratio that was probably
caused by a bug in ldglite at the time. And there were some questions
about large image sizes, but it should be a viable solution for ldview.
I don't know why we ended up using osmesa instead. Perhaps to simplify
things by rolling it all up into a single process? Leaving xvfb
running might have been a bit of a drag on the server. Or maybe it
was just simply easier to build osmesa on the BSD system since it
didn't seem to come with X11 or opengl.
It's certainly a simpler rendering path without the X11 layer.
Have fun,
Don
|
|
| |
In lugnet.cad, Steve Bliss wrote:
> In lugnet.cad, Don Heyse wrote:
> > It looks like you have a bug in whatever program you're using to
> > convert ldconfig.ldr to ldliterc.dat.
>
> "Program"? I wish. It was a manual conversion, not all of the entries
> are amenable to programmatic conversion.
>
> > In the first set of colors on each line the blue value always
> > seems to be the same as the green value.
>
> Doh! It should be fixed now, take a look.
I don't have a test case for all the colors, but the ones I did
try look ok now.
> No wonder the orange switch on the PF box looked so odd...
It all looks odd to me with the black edge lines on all the bricks.
Good for printed instructions, but not as pretty on screen. Oh well.
I suppose it doesn't really matter for parts tracker where the parts
are all rendered in the default gray color.
Also I also noticed a few colors that must not have made the cut to
the big time official list. What ever happened to color 32 trans-black,
or color 39 trans-light-gray (aka smoke)? I thought that was in use
somewhere for some of the starwars canopies.
Have fun,
Don
|
|
| |
In lugnet.cad, Travis Cobbs wrote:
> I could probably whip up a program that does the conversion fairly
> quickly (hour or two of work?) if you're interested. I have the
> advantage that I already have a full parser for ldconfig.ldr.
> Spitting out the ldliterc.dat file should be straightforward.
Yes, but wouldn't that be subverting Willy's diabolical plan to render
everything with ldview? ;^)
Don
|
|
| |
In lugnet.cad, Don Heyse wrote:
> In lugnet.cad, Steve Bliss wrote:
> > Doh! It should be fixed now, take a look.
>
> I don't have a test case for all the colors, but the ones I did
> try look ok now.
Hmm. I should put my color patch .DAT file on the server somewhere...
> > No wonder the orange switch on the PF box looked so odd...
>
> It all looks odd to me with the black edge lines on all the bricks.
That could be changed. But I think most people who profess a preference prefer
the black edges, rather than colored edges. We could soften the black edges to
a charcoal shade. Would that be better?
> Also I also noticed a few colors that must not have made the cut to
> the big time official list. What ever happened to color 32 trans-black,
> or color 39 trans-light-gray (aka smoke)? I thought that was in use
> somewhere for some of the starwars canopies.
Smoke is color 40 (trans-dk gray). At least in the color def file.
Other colors can be added. We just need a generally-agreed-upon definition for
them.
Steve
|
|
| |
In lugnet.cad, Don Heyse wrote:
> In lugnet.cad, Travis Cobbs wrote:
> > I could probably whip up a program that does the conversion fairly
> > quickly (hour or two of work?) if you're interested. I have the
> > advantage that I already have a full parser for ldconfig.ldr.
> > Spitting out the ldliterc.dat file should be straightforward.
>
> Yes, but wouldn't that be subverting Willy's diabolical plan to render
> everything with ldview? ;^)
Well, to be perfectly honest, while I'm pretty confident that LDView can be
gotten to work relatively easily (via xvfb) on the LDraw server, I'm not sure
whether its performance will be "acceptable". So I think it's only fair to keep
the options open.
On the flip side, if they do switch over to using LDView, then perhaps the
Peeron images will update also, which would lead to the somewhat ironic
situation of LDView generating a parts list that links to images on a public web
server that were generated by LDView, but LDView itself not being capable of
generating those same images for local references. (Mind you, that's just a
feature that I haven't implemented yet, but it seems to me that there would be a
certain irony involved.)
The current parts list has the advantage that the files can easily be sent to others and posted online, since all you need is Internet access in order to see the images. If LDView generates the images, I also run into the problem of where to put them. Do I use a separate directory for each parts list, so you can zip it up easier, or a common directory so the images can be reused?
--Travis
|
|
| |
> OK, that wasn't so hard. The script should be fixed now. I've pushed through
> re-renders for 58119 and x919. All other parts are queued for re-rendering, all
> images should be updated in a short time.
Great! Thanks, Steve!!!
Philo
|
|
| |
In lugnet.cad, Travis Cobbs wrote:
> In lugnet.cad, Don Heyse wrote:
> > In lugnet.cad, Travis Cobbs wrote:
> > > I could probably whip up a program that does the conversion fairly
> > > quickly (hour or two of work?) if you're interested. I have the
> > > advantage that I already have a full parser for ldconfig.ldr.
> > > Spitting out the ldliterc.dat file should be straightforward.
> >
> > Yes, but wouldn't that be subverting Willy's diabolical plan to render
> > everything with ldview? ;^)
>
> Well, to be perfectly honest, while I'm pretty confident that LDView can be
> gotten to work relatively easily (via xvfb) on the LDraw server, I'm not sure
> whether its performance will be "acceptable". So I think it's only fair to keep
> the options open.
>
> On the flip side, if they do switch over to using LDView, then perhaps the
> Peeron images will update also, which would lead to the somewhat ironic
> situation of LDView generating a parts list that links to images on a public web
> server that were generated by LDView, but LDView itself not being capable of
> generating those same images for local references. (Mind you, that's just a
> feature that I haven't implemented yet, but it seems to me that there would be a
> certain irony involved.)
>
> The current parts list has the advantage that the files can easily be sent
> to others and posted online, since all you need is Internet access in order
> to see the images. If LDView generates the images, I also run into the
> problem of where to put them. Do I use a separate directory for each parts
> list, so you can zip it up easier, or a common directory so the images can
> be reused?
>
> --Travis
Though the color problem has been solved I'm still in favour for the switch for
the simply fact that LDView is maintained and updated (and LDView's outputs look
much smarter ;-) but it's up to Travis to take the decision - since he has to
code it up.
w.
|
|
| |
In lugnet.cad, Travis Cobbs wrote:
> In lugnet.cad, Don Heyse wrote:
> > In lugnet.cad, Travis Cobbs wrote:
> > > I could probably whip up a program that does the conversion fairly
> > > quickly (hour or two of work?) if you're interested. I have the
> > > advantage that I already have a full parser for ldconfig.ldr.
> > > Spitting out the ldliterc.dat file should be straightforward.
> >
> > Yes, but wouldn't that be subverting Willy's diabolical plan to render
> > everything with ldview? ;^)
>
> Well, to be perfectly honest, while I'm pretty confident that LDView can be
> gotten to work relatively easily (via xvfb) on the LDraw server, I'm not sure
> whether its performance will be "acceptable". So I think it's only fair to keep
> the options open.
Though the error has been fixed I'm still in favour for the switch for the
simple fact that LDView is maintained and updated (and that IMHO it's output
looks much smarter) but I'm happy to leave the decision to go/no go to Travis
since he has to code it up.
w.
|
|
| |
In lugnet.cad, Willy Tschager wrote:
| |
Though the error has been fixed I’m still in favour for the switch for the
simple fact that LDView is maintained and updated (and that IMHO it’s output
looks much smarter) but I’m happy to leave the decision to go/no go to Travis
since he has to code it up.
|
I’d be happy to try, but it would require some things:
- An admin to install xvfb on the server
- An admin to give me a user account on the server to get it working
- Possible admin support if other dependencies are missing on the server
As a note, requirement 1 probably requires that X11 be installed on the server,
if it isn’t already there. That’s because, as far as I know, X11 stuff only
works if all the libraries are installed.
--Travis
|
|
| |
In lugnet.cad, Steve Bliss wrote:
| |
OK, that wasn’t so hard. The script should be fixed now. I’ve pushed through
re-renders for 58119 and x919. All other parts are queued for re-rendering,
all images should be updated in a short time.
If anyone wants to look at the ldliterc.dat file, you can grab a copy at
http://www.ldraw.org/library/unofficial/ldliterc.dat
|
Maybe it’s just me, but the parts on the tracker now seem to be very light. I
looked at the ldliterc.dat above, and color 7 has the same setting as what is in
ldconfig.ldr. However, the actual color being rendered seems too light. For
example, here is an image from the part tracker:
Here is the same part rendered in LDView (with ldconfig.ldr turned on, and an
attempt on my part to approximate the light angle used in ldglite):
Here it is from LDView with no lighting:
Note also that the images on the part tracker didn’t seem to be so light before.
Does ldglite do something weird with colors when it’s using ldliterc.dat, Don?
Or are the internal ldglite colors perhaps all somewhat dark to counteract
bright lighting parameters?
--Travis
|
|
| |
In lugnet.cad, Travis Cobbs wrote:
| |
In lugnet.cad, Steve Bliss wrote:
| |
OK, that wasn’t so hard. The script should be fixed now. I’ve pushed
through re-renders for 58119 and x919. All other parts are queued for
re-rendering, all images should be updated in a short time.
If anyone wants to look at the ldliterc.dat file, you can grab a copy at
http://www.ldraw.org/library/unofficial/ldliterc.dat
|
Maybe it’s just me, but the parts on the tracker now seem to be very light.
I looked at the ldliterc.dat above, and color 7 has the same setting as what
is in ldconfig.ldr. However, the actual color being rendered seems too
light. For example, here is an image from the part tracker:
Here is the same part rendered in LDView (with ldconfig.ldr turned on, and an
attempt on my part to approximate the light angle used in ldglite):
Here it is from LDView with no lighting:
Note also that the images on the part tracker didn’t seem to be so light
before. Does ldglite do something weird with colors when it’s using
ldliterc.dat, Don? Or are the internal ldglite colors perhaps all somewhat
dark to counteract bright lighting parameters?
|
The actual truth may be lost to the sands of time, but I believe
the ldlite colors were possibly copied from the original LDRAW colors,
and the ldlite Windows lighting code was matched to that? I know
I did a good amount of twiddling in the early days of ldglite coding to
adapt the opengl material and lighting parameters to achieve what I
considered nice shiny looking bricks with bright colors using the ldlite
colors as is. I think you’re correct that I ended up with some fairly
bright lighting params. Perhaps a bit too much ambient light?
Now I don’t remember exactly how the official ldconfig.ldr colors were
arrived at, but they *are* significantly different from the ldglite colors.
Perhaps they’re intended for a dimmer lighting model. Whatever, they
certainly look a bit washed out and dull in ldglite. I suppose I
should compare my lighting model code to yours to quantify the difference.
Meanwhile, perhaps the official ldliterc.dat file should be modified to
use the original ldlite colors where they already exist? (Edge colors
could still be set to black to make the majority happy)
Don
|
|
| |
In lugnet.cad, Don Heyse wrote:
| |
In lugnet.cad, Travis Cobbs wrote:
| |
light. For example, here is an image from the part tracker:
Here is the same part rendered in LDView (with ldconfig.ldr turned on, and
an attempt on my part to approximate the light angle used in ldglite):
Here it is from LDView with no lighting:
|
Now I don’t remember exactly how the official ldconfig.ldr colors were
arrived at, but they *are* significantly different from the ldglite colors.
Perhaps they’re intended for a dimmer lighting model. Whatever, they
certainly look a bit washed out and dull in ldglite. I suppose I
should compare my lighting model code to yours to quantify the difference.
Meanwhile, perhaps the official ldliterc.dat file should be modified to
use the original ldlite colors where they already exist? (Edge colors
could still be set to black to make the majority happy)
|
I’m pretty sure the ldconfig.ldr colors are designed to match the brick colors
when no lighting is used (as in the second LDView picture above. If the ambient
and diffuse terms add up to more than 1.0, the original colors end up getting
washed out. I’m guessing that ldglite’s ambient and diffuse terms add up to
quite a bit more than 1.0.
When I did the “subdued” lighting in LDView, I set it up so that the ambient and
diffuse terms add up to 1.0. (It uses 0.5 for the intensity of both the ambient
and the diffuse, actually.) Relatively recently I noticed that my regular
lighting has a diffuse intensity of 1.0 and an ambient intensity of 0.2. I’m
hesitant to change it now, though, since it’s been that way for so long. I’ll
probably see what 0.8 diffuse looks like and change it if it seems OK.
--Travis
|
|
| |
In lugnet.cad, Don Heyse wrote:
| |
Meanwhile, perhaps the official ldliterc.dat file should be modified to
use the original ldlite colors where they already exist? (Edge colors
could still be set to black to make the majority happy)
|
I’m open to improving the unofficial ldliterc.dat colors, but I don’t expect we
want to use all the default ldlite colors -- unless they were tuned away from
the original LDraw (ie, 4-bit VGA) colors.
The other issue is if we the built-in ldlite values for some colors, and the
ldconfig.ldr values for other colors, some combinations might look odd.
Steve
|
|
| |
In lugnet.cad, Anders Isaksson wrote:
| |
Travis Cobbs wrote:
| |
For example, here is an image from the part tracker:
|
To my eyes, the proportions of that picture are completely off, that part
should have the proportions of a normal 1x2x1, right? Not 1x2x0.72 or
whatever that picture shows...
|
I think it’s using an isometric matrix for the view, which leads to this effect.
This matches the default output from ldraw.exe. Here is 3004.dat rendered with
ldraw.exe and then scaled down to match the size of the image on the part
tracker:
Note that when I scaled the image, I only set the horizontal size to match (52),
and the locked aspect ratio produced the same vertical size automatically. I do
agree that it looks “wrong”. I think the side studs on 52107 exaggerate the
effect.
--Travis
|
|
| |
In lugnet.cad, Travis Cobbs wrote:
| |
In lugnet.cad, Don Heyse wrote:
| |
In lugnet.cad, Travis Cobbs wrote:
| |
light. For example, here is an image from the part tracker:
Here is the same part rendered in LDView (with ldconfig.ldr turned on, and
an attempt on my part to approximate the light angle used in ldglite):
Here it is from LDView with no lighting:
|
Now I don’t remember exactly how the official ldconfig.ldr colors were
arrived at, but they *are* significantly different from the ldglite colors.
Perhaps they’re intended for a dimmer lighting model. Whatever, they
certainly look a bit washed out and dull in ldglite. I suppose I
should compare my lighting model code to yours to quantify the difference.
Meanwhile, perhaps the official ldliterc.dat file should be modified to
use the original ldlite colors where they already exist? (Edge colors
could still be set to black to make the majority happy)
|
I’m pretty sure the ldconfig.ldr colors are designed to match the brick
colors when no lighting is used (as in the second LDView picture above. If
the ambient and diffuse terms add up to more than 1.0, the original colors
end up getting washed out. I’m guessing that ldglite’s ambient and diffuse
terms add up to quite a bit more than 1.0.
When I did the “subdued” lighting in LDView, I set it up so that the ambient
and diffuse terms add up to 1.0. (It uses 0.5 for the intensity of both the
ambient and the diffuse, actually.) Relatively recently I noticed that my
regular lighting has a diffuse intensity of 1.0 and an ambient intensity of
0.2. I’m hesitant to change it now, though, since it’s been that way for so
long. I’ll probably see what 0.8 diffuse looks like and change it if it
seems OK.
|
I’d leave your setup alone since it seems to work well with the
current color list. You’re right about ldglite. I didn’t like dark
shadows, or maybe I run my monitor too dark to avoid migraines, but
the lighting settings do add up to more than 1.0. To get something I
liked with my equipment, I cranked the ambient up to 0.75 and set the
diffuse light at 0.5. Does the distance to the diffuse light have
any effect? Mine is pretty far back behind the camera.
The ldglite ambient and diffuse lights could be set to your “regular”
settings with following command line settings:
-lc-1000,1000,1000,1,1,1 -lC0.2,0.2,0.2
Maybe using a different location than (-1000,1000,1000)?
Anyhow, here’s my lighting and materials setup for shaded rendering.
What else are we doing differently, besides one/two sided lighting?
Don
// Set the light way up and behind us. Will this make it too dim?
// NOTE: The LDRAW polys are not CCW compliant so the normals are random
// LdLite uses 2 opposing lights to avoid the problem with normals?
// I attempted this below but it does not seem to work for OpenGL.
// Hmmm, perhaps LdLite just took the fabs() of normals instead.
// If I calculate normals then I could do that too.
// x, y, z, dist divisor. (divisor = 0 for light at infinite distance)
GLfloat lightposition0[] = { -1000.0, 1000.0, 1000.0, 0.0 };
GLfloat lightcolor0[] = { 0.5, 0.5, 0.5, 1.0 }; // Half light
GLfloat lightcolor1[] = { 0.75, 0.75, 0.75, 1.0 }; // bright light
glEnable(GL_LIGHTING);
// Medium diffuse light for some minor shadow effects
glEnable(GL_LIGHT0);
glLightfv(GL_LIGHT0, GL_POSITION, lightposition0);
glLightfv(GL_LIGHT0, GL_DIFFUSE, lightcolor0);
// Bright ambient light for the whole scene.
glLightModelfv(GL_LIGHT_MODEL_AMBIENT, lightcolor1);
// 2 sided lighting because I'm too lazy to use BFC.
glLightModeli(GL_LIGHT_MODEL_TWO_SIDE, GL_TRUE);
// OpenGL's color material feature provides a less expensive way to change
// material parameters. With color material enabled, material colors track
// the current color. This means that instead of using the relatively
// expensive glMaterialfv routine, you can use the glColor3f routine.
//
// Ambient and diffusion properties for front and back faces.
// Full ambient and diffusion for R, G, B, alpha ???
GLfloat full_mat[] = { 1.0, 1.0, 1.0, 1.0 };
GLfloat half_mat[] = { 0.5, 0.5, 0.5, 1.0 };
GLfloat no_mat[] = { 0.0, 0.0, 0.0, 1.0 };
GLfloat no_shininess[] = { 1.0 };
GLfloat lo_shininess[] = { 5.0 };
GLfloat mid_shininess[] = { 15.0 }; // Seems nice for plastic chrome and gold.
GLfloat hi_shininess[] = { 50.0 }; // { 100.0 };
glEnable(GL_COLOR_MATERIAL);
glColorMaterial(GL_FRONT_AND_BACK, GL_SPECULAR);
glColorMaterial(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE);
glMaterialfv(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE, full_mat);
glMaterialfv(GL_FRONT_AND_BACK, GL_SPECULAR, no_mat);
glMaterialfv(GL_FRONT_AND_BACK, GL_SHININESS, no_shininess);
glMaterialfv(GL_FRONT_AND_BACK, GL_EMISSION, no_mat);
|
|
|
|
| |
In lugnet.cad, Don Heyse wrote:
| |
I’d leave your setup alone since it seems to work well with the
current color list. You’re right about ldglite. I didn’t like dark
shadows, or maybe I run my monitor too dark to avoid migraines, but
the lighting settings do add up to more than 1.0. To get something I
liked with my equipment, I cranked the ambient up to 0.75 and set the
diffuse light at 0.5. Does the distance to the diffuse light have
any effect? Mine is pretty far back behind the camera.
|
The distance would matter, except that you’re using a directional light. Since
the w component of your light position is 0.0, it’s a directional light. As
such, -1,1,1 is the same as the -1000,1000,1000 that you have. (How’s that for
intuitive? Set the w coord of the light position to 0 and it’s directional; set
it to non-zero and it’s a point light. It took me forever to track this down in
the documentation when trying to get light.dat point lights to work.)
| |
The ldglite ambient and diffuse lights could be set to your “regular”
settings with following command line settings:
-lc-1000,1000,1000,1,1,1 -lC0.2,0.2,0.2
Maybe using a different location than (-1000,1000,1000)?
|
My default light “position” is 0,0,1. Note that for directional lights, this is
treated as a direction, not a position, although the documentation seems
ambiguous about the whole issue. (It may be the inverse of the direction, but
it’s definitely a direction.)
| |
Anyhow, here’s my lighting and materials setup for shaded rendering.
What else are we doing differently, besides one/two sided lighting?
|
Note that if BFC is disabled in LDView, it uses two-sided lighting also any time
the light vector doesn’t equal 0,0,1. And even when BFC is enabled, it uses
two-sided lighting for all non-BFC geometry.
I’d suggest you update your comments to reflect the fact that it’s a directional
light. I’d then change the default to -1,1,1 instead of -1000,1000,1000, since
those produce the same result. You might even mention that the 0 in the w
coordinate of the light vector is what triggers the “directional light”
behavior.
| |
// Set the light way up and behind us. Will this make it too dim?
// NOTE: The LDRAW polys are not CCW compliant so the normals are random
// LdLite uses 2 opposing lights to avoid the problem with normals?
// I attempted this below but it does not seem to work for OpenGL.
// Hmmm, perhaps LdLite just took the fabs() of normals instead.
// If I calculate normals then I could do that too.
// x, y, z, dist divisor. (divisor = 0 for light at infinite distance)
GLfloat lightposition0[] = { -1000.0, 1000.0, 1000.0, 0.0 };
GLfloat lightcolor0[] = { 0.5, 0.5, 0.5, 1.0 }; // Half light
GLfloat lightcolor1[] = { 0.75, 0.75, 0.75, 1.0 }; // bright light
glEnable(GL_LIGHTING);
// Medium diffuse light for some minor shadow effects
glEnable(GL_LIGHT0);
glLightfv(GL_LIGHT0, GL_POSITION, lightposition0);
glLightfv(GL_LIGHT0, GL_DIFFUSE, lightcolor0);
// Bright ambient light for the whole scene.
glLightModelfv(GL_LIGHT_MODEL_AMBIENT, lightcolor1);
// 2 sided lighting because I'm too lazy to use BFC.
glLightModeli(GL_LIGHT_MODEL_TWO_SIDE, GL_TRUE);
// OpenGL's color material feature provides a less expensive way to change
// material parameters. With color material enabled, material colors track
// the current color. This means that instead of using the relatively
// expensive glMaterialfv routine, you can use the glColor3f routine.
//
// Ambient and diffusion properties for front and back faces.
// Full ambient and diffusion for R, G, B, alpha ???
GLfloat full_mat[] = { 1.0, 1.0, 1.0, 1.0 };
GLfloat half_mat[] = { 0.5, 0.5, 0.5, 1.0 };
GLfloat no_mat[] = { 0.0, 0.0, 0.0, 1.0 };
GLfloat no_shininess[] = { 1.0 };
GLfloat lo_shininess[] = { 5.0 };
GLfloat mid_shininess[] = { 15.0 }; // Seems nice for plastic chrome and gold.
GLfloat hi_shininess[] = { 50.0 }; // { 100.0 };
glEnable(GL_COLOR_MATERIAL);
glColorMaterial(GL_FRONT_AND_BACK, GL_SPECULAR);
glColorMaterial(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE);
glMaterialfv(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE, full_mat);
glMaterialfv(GL_FRONT_AND_BACK, GL_SPECULAR, no_mat);
glMaterialfv(GL_FRONT_AND_BACK, GL_SHININESS, no_shininess);
glMaterialfv(GL_FRONT_AND_BACK, GL_EMISSION, no_mat);
|
|
|
I think that your glMaterialfv call with GL_AMBIENT_AND_DIFFUSE is redundant,
since the glColorMaterial call overrides anything you set. (Note that I do
something similar in LDView, and haven’t yet gotten around to verifying that it
can be removed.) I’m also pretty sure that your first glColorMaterial call is
clobbered by your second one, so is also redundant.
I’m pretty sure that if you changed your ambient from .75 to .5, you’d end up
with the same lighting that LDView has in “subdued” mode.
--Travis
|
|
| |
In lugnet.cad, Travis Cobbs wrote:
| |
In lugnet.cad, Don Heyse wrote:
| |
I’d leave your setup alone since it seems to work well with the
current color list. You’re right about ldglite. I didn’t like dark
shadows, or maybe I run my monitor too dark to avoid migraines, but
the lighting settings do add up to more than 1.0. To get something I
liked with my equipment, I cranked the ambient up to 0.75 and set the
diffuse light at 0.5. Does the distance to the diffuse light have
any effect? Mine is pretty far back behind the camera.
|
The distance would matter, except that you’re using a directional light.
Since the w component of your light position is 0.0, it’s a directional
light. As such, -1,1,1 is the same as the -1000,1000,1000 that you have.
(How’s that for intuitive? Set the w coord of the light position to 0 and
it’s directional; set it to non-zero and it’s a point light. It took me
forever to track this down in the documentation when trying to get light.dat
point lights to work.)
|
I think knew that at one point based on the comment about “dist divisor”.
And I suspect I didn’t reduce it to -1,1,1 so I could easily switch
to a point light source at that location. (yeah, that’s it... ;^)
| |
| |
The ldglite ambient and diffuse lights could be set to your “regular”
settings with following command line settings:
-lc-1000,1000,1000,1,1,1 -lC0.2,0.2,0.2
Maybe using a different location than (-1000,1000,1000)?
|
My default light “position” is 0,0,1. Note that for directional lights, this
is treated as a direction, not a position, although the documentation seems
ambiguous about the whole issue. (It may be the inverse of the direction,
but it’s definitely a direction.)
|
It seems like the direction toward the light source. Maybe so you can
convert a directional light to a point light by changing only the w?
Works for me...
| |
I’d suggest you update your comments to reflect the fact that it’s a
directional light. I’d then change the default to -1,1,1 instead of
-1000,1000,1000, since those produce the same result. You might even mention
that the 0 in the w coordinate of the light vector is what triggers the
“directional light” behavior.
|
Probably should fix the comments. But first I gotta find out where
I got the idea that w coord was a “distance divisor”. Probably mixed
it up with some older graphics API...
| |
| |
// Set the light way up and behind us. Will this make it too dim?
// NOTE: The LDRAW polys are not CCW compliant so the normals are random
// LdLite uses 2 opposing lights to avoid the problem with normals?
// I attempted this below but it does not seem to work for OpenGL.
// Hmmm, perhaps LdLite just took the fabs() of normals instead.
// If I calculate normals then I could do that too.
// x, y, z, dist divisor. (divisor = 0 for light at infinite distance)
GLfloat lightposition0[] = { -1000.0, 1000.0, 1000.0, 0.0 };
GLfloat lightcolor0[] = { 0.5, 0.5, 0.5, 1.0 }; // Half light
GLfloat lightcolor1[] = { 0.75, 0.75, 0.75, 1.0 }; // bright light
glEnable(GL_LIGHTING);
// Medium diffuse light for some minor shadow effects
glEnable(GL_LIGHT0);
glLightfv(GL_LIGHT0, GL_POSITION, lightposition0);
glLightfv(GL_LIGHT0, GL_DIFFUSE, lightcolor0);
// Bright ambient light for the whole scene.
glLightModelfv(GL_LIGHT_MODEL_AMBIENT, lightcolor1);
// 2 sided lighting because I'm too lazy to use BFC.
glLightModeli(GL_LIGHT_MODEL_TWO_SIDE, GL_TRUE);
// OpenGL's color material feature provides a less expensive way to change
// material parameters. With color material enabled, material colors track
// the current color. This means that instead of using the relatively
// expensive glMaterialfv routine, you can use the glColor3f routine.
//
// Ambient and diffusion properties for front and back faces.
// Full ambient and diffusion for R, G, B, alpha ???
GLfloat full_mat[] = { 1.0, 1.0, 1.0, 1.0 };
GLfloat half_mat[] = { 0.5, 0.5, 0.5, 1.0 };
GLfloat no_mat[] = { 0.0, 0.0, 0.0, 1.0 };
GLfloat no_shininess[] = { 1.0 };
GLfloat lo_shininess[] = { 5.0 };
GLfloat mid_shininess[] = { 15.0 }; // Seems nice for plastic chrome and gold.
GLfloat hi_shininess[] = { 50.0 }; // { 100.0 };
glEnable(GL_COLOR_MATERIAL);
glColorMaterial(GL_FRONT_AND_BACK, GL_SPECULAR);
glColorMaterial(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE);
glMaterialfv(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE, full_mat);
glMaterialfv(GL_FRONT_AND_BACK, GL_SPECULAR, no_mat);
glMaterialfv(GL_FRONT_AND_BACK, GL_SHININESS, no_shininess);
glMaterialfv(GL_FRONT_AND_BACK, GL_EMISSION, no_mat);
|
|
|
I think that your glMaterialfv call with GL_AMBIENT_AND_DIFFUSE is
redundant, since the glColorMaterial call overrides anything you set. (Note
that I do something similar in LDView, and haven’t yet gotten around to
verifying that it can be removed.) I’m also pretty sure that your first
glColorMaterial call is clobbered by your second one, so is also redundant.
|
Yes, It’s a bit of a mess there because I wanted examples of everything
in one place so I could cut and paste when I experimented with
the shininess for chrome and gold.
| |
I’m pretty sure that if you changed your ambient from .75 to .5, you’d end up
with the same lighting that LDView has in “subdued” mode.
|
I tried that, but it still doesn’t seem to match. Your colors look
a bit “warmer” to me for some reason. Am I Hallucinating? It’s probably
just an optical illusion based on the different backgrounds of the pics,
but I can’t seem to see through it.
Have fun,
Don
|
|
| |
In lugnet.cad, Travis Cobbs wrote:
| |
In lugnet.cad, Anders Isaksson wrote:
| |
Travis Cobbs wrote:
| |
For example, here is an image from the part tracker:
|
To my eyes, the proportions of that picture are completely off, that part
should have the proportions of a normal 1x2x1, right? Not 1x2x0.72 or
whatever that picture shows...
|
I think it’s using an isometric matrix for the view, which leads to this
effect. This matches the default output from ldraw.exe. Here is 3004.dat
rendered with ldraw.exe and then scaled down to match the size of the image
on the part tracker:
|
Last night, I updated the rendering script to use L3Lab’s “Front-Upper-Right”
view for most parts (Baseplates use a top-down view, panels use
“Back-Upper-Left”). The actual parameter/array is:
0.7071,0,0.7071,0.3536,0.866,-0.3536,-0.6124,0.5,0.6124
I also changed the scale from .85 to 1.0, which seems to fit the new images to
about the same size as old images.
Do the unofficial images look better now?
Steve
|
|
| |
In lugnet.cad, Anders Isaksson wrote:
> Steve Bliss wrote:
> > Do the unofficial images look better now?
>
> Yes, at least to me :-)
To me also. I meant to respond, but my verification email address was down
temporarily when the original message was posted, and I forgot to respond later.
--Travis
|
|
| |
In lugnet.cad, Steve Bliss wrote:
| |
| |
| |
| |
For example, here is an image from the part tracker:
|
|
|
Last night, I updated the rendering script to use L3Lab’s “Front-Upper-Right”
view for most parts (Baseplates use a top-down view, panels use
“Back-Upper-Left”). The actual parameter/array is:
0.7071,0,0.7071,0.3536,0.866,-0.3536,-0.6124,0.5,0.6124
I also changed the scale from .85 to 1.0, which seems to fit the new images
to about the same size as old images.
Do the unofficial images look better now?
|
Looks better to me too. What’s the rest of the command line look like?
I wonder if maybe we can tweak it one more time to convince the edge lines
to meet at the corners.
Don
|
|
| |
In lugnet.cad, Don Heyse wrote:
> Looks better to me too. What's the rest of the command line look like?
> I wonder if maybe we can tweak it one more time to convince the edge lines
> to meet at the corners.
It looks about like this:
ldglite -a<matrix> -ld -Q -b15 -i1 -MS<outfile>.png <infile>.dat
Lugnet is insisting on eating the matrix text (I seem to remember this happening
before, sometime). So the matrix looks something like:
0.7071,
0,
0.7071,
0.3536,
0.866,
-0.3536,
-0.6124,
0.5,
0.6124
... but all on one line.
Steve
|
|
| |
In lugnet.cad, Steve Bliss wrote:
> In lugnet.cad, Don Heyse wrote:
> > Looks better to me too. What's the rest of the command line look like?
> > I wonder if maybe we can tweak it one more time to convince the edge lines
> > to meet at the corners.
>
> It looks about like this:
> ldglite -a<matrix> -ld -Q -b15 -i1 -MS<outfile>.png <infile>.dat
I think I had some issues with the GL_POINT implementation on
that version of OSMesa OpenGL. If you're bored, you could
try adding a line width to see if that makes the line endpoints
come out right.
Something like -w1.3 or -w1.1 or maybe even -w0.9 could possibly
do it.
Don
|
|
|
