Jump to content
  • Advertisement
Sign in to follow this  
Mercenarey

OpenGL Pointlight: Range vs. Attenuation - how to match them?

This topic is 4081 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

Hi guys. Im playing around with Range and Attenuation at the moment, and I have problems making them match. I would like a setup, where the light is just about zero at the max range, to avoid the popping effect, when the light's boundingvolume (BV->radius == pointlight->range) collides with the object that is to be lighted. Furthermore, I would like a light that is at (or close to) max. intensity when up close, with a fair falloff as range increases, and then a steep falloff to 0 light on the last 10% of the light. I wonder if there are any formulas out there for matching range and attenuation? How do you solve the range vs. attenuation problem? PS: I use the three attenuation values, that MS uses, and which seem to be standard (Attenuation0, Attenuation1, Attenuation2 (D3DLight structure), OpenGL calls them constant, linear and quadratic). [Edited by - Mercenarey on September 14, 2007 6:47:08 PM]

Share this post


Link to post
Share on other sites
Advertisement
In general I find the standard D3D & OGL lighting pipeline to be pretty useless in this area. What you really want is a light that has a min and a max distance. At or closer than the min distance it is at maximum brightness, at or beyond the max distance it's at zero, and in between it is a linear falloff. Yes, I said linear, not quadratic. It's not physically correct, but monitors have such a limit gamut that most artists prefer this behaviour.

Which basically means dropping the fixed-function pipeline and doing some vertex shaders, doing the lighting on the CPU. It's not a terrible thing.

If you're using an HDR pipeline, you may want to go more physically-correct and use fancier falloffs. I don't any experience with HDR pipelines, but I know they open an entirely new and more challenging can of worms.

Share this post


Link to post
Share on other sites
Quote:
Original post by TomForsyth
In general I find the standard D3D & OGL lighting pipeline to be pretty useless in this area. What you really want is a light that has a min and a max distance. At or closer than the min distance it is at maximum brightness, at or beyond the max distance it's at zero, and in between it is a linear falloff. Yes, I said linear, not quadratic. It's not physically correct, but monitors have such a limit gamut that most artists prefer this behaviour.

I agree that it's often more convenient to work within user-defined intensity and distance bounds, but the existing framework is far more flexible than what you propose. It's a bit of a pain, but with a little bit of algebra you can fit a quadratic curve to give the same effect in a much more realistic way. Anyway, if you don't like the inverse-square attenuation it's your prerogative to set the quadratic coefficient to zero.

Admiral

Share this post


Link to post
Share on other sites
The intensity equation is 1/(A*d^2 + B*d + C). Note the reciprocal! There's no way to make that zero at a user-defined distance. Which is why it's rubbish.

Share this post


Link to post
Share on other sites
Quote:
Original post by TomForsyth
The intensity equation is 1/(A*d^2 + B*d + C). Note the reciprocal! There's no way to make that zero at a user-defined distance. Which is why it's rubbish.

Granted, that can make things a little awkward for us, but I'm sure there would be uproar from those who want truly realistic lighting model if it were impossible to have them attenuate as an inverse-square. Perhaps adding a linear term outside of the reciprocal would solve out problems.

Anyway, the FFP is on the brink of extinction. With dynamic flow control in recent shader models, we are free to make our lights behave in whatever perverse ways satisfy our desires.

Admiral

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!