| |
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
|
|
|
