Jump to content
  • Advertisement
Sign in to follow this  
DjMaSh

(opengl lighting) &(Normalise lights or normals?)

This topic is 3756 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have two questions: 1) There are two ways to increase the intensity at which an object is lit. Increase the size of the normals on the verticies OR increase the rgb light values. Which is more correct? 2) should the rgb light values ever be greater than 1.0f? I find my objects aren't being lit enough unless I put these values greater than 1. Am I doing something wrong or is this OK?

Share this post


Link to post
Share on other sites
Advertisement
I'd keep normals unit length. Controlling light intensity through non-unit normals will just lead to confusion.

Feel free to have light values greater than 1. The post-lighting color channels just get clamped to [0,1] range.

Share this post


Link to post
Share on other sites
Quote:
Original post by SnotBob
Feel free to have light values greater than 1. The post-lighting color channels just get clamped to [0,1] range.


You say that giving a value larger than 1 will just get clamped down to 1? These two blocks of statements are equivalent?


float diffuse[] = {1.0f, 0.0f, 0.0f, 1.0f}
glLightfv(GL_LIGHT0, GL_DIFFUSE, diffuse);

float diffuse[] = {1000.0f, 0.0f, 0.0f, 1.0f}
glLightfv(GL_LIGHT0, GL_DIFFUSE, diffuse);



So how come if i use the second statement (where the red value is 1000) my object appears brighter?

Share this post


Link to post
Share on other sites
Quote:
Original post by DjMaSh
Quote:
Original post by SnotBob
Feel free to have light values greater than 1. The post-lighting color channels just get clamped to [0,1] range.


You say that giving a value larger than 1 will just get clamped down to 1? These two blocks of statements are equivalent?

No, the vertex colors get clamped after lighting. Light parameters are not clamped.

Share this post


Link to post
Share on other sites
No, they're not equivalent - the final pixel colour value will get clamped down, not the lighting value.

And you should definitely keep your normals unit-length.

What type of light are you using (spot, point, directional), where is it in relation to your object, and how is your object's material set up?

Share this post


Link to post
Share on other sites
Quote:
Original post by superpig
the final pixel colour value will get clamped down

Just to nitpick: "After lighting (whether enabled or not), all components of both primary and secondary colors are clamped to the range [0, 1]." So the clamping happens before rasterization, i.e. per vertex.

Share this post


Link to post
Share on other sites
Quote:
Original post by SnotBob
per vertex.

Isn't there a nicer technical term which doesn't contain the word "pervert"? ;)

Share this post


Link to post
Share on other sites
OK I have found my problem. I was calling glScalef before my draw cube routine, which had the normals specified in it. So I had to specify a massive lighting value to match the size of the normals I was using. After I called glEnable(GL_NORMALIZE) it seemed to fix the problem.

Does this mean that every time I stretch an object, I will have to recompute the unit normals myself if i don't want to use GL_NORMALIZE?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!