Subject:
|
Re: Why LDraw.org doesn't use ldconfig.ldr ???
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Thu, 4 Oct 2007 21:25:21 GMT
|
Viewed:
|
8366 times
|
| |
|
|
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
|
|
Message has 1 Reply:
 | | Re: Why LDraw.org doesn't use ldconfig.ldr ???
|
| (...) 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... ;^) (...) It seems like the direction (...) (17 years ago, 4-Oct-07, to lugnet.cad, FTX)
|
Message is in Reply To:
| | Re: Why LDraw.org doesn't use ldconfig.ldr ???
|
| (...) 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 (...) (17 years ago, 4-Oct-07, to lugnet.cad, FTX)
|
43 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
