Jump to content

  • Log In with Google      Sign In   
  • Create Account

HDR Light Values


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Quat   Members   -  Reputation: 414

Like
0Likes
Like

Posted 24 January 2014 - 03:58 PM

So with HDR lighting the idea is that we can have high lighting values.  But what scale should be used?  Like if I want to make a light source emit RGB (100, 100, 100) what do those values mean?  Or does it not matter and I just need to make sure everything balances out?  What intensity would be considered "bright" for bloom effects? 

 

Also for LDR lighting, I used a linear light attenuation, but it seems quadratic is more necessary for HDR as the light intensity near the light needs to be reduced faster otherwise the scene looks too bright.  Is this common practice?

 

With respect to tone mapping, it seems HDR light values will affect the "middle gray" value.  That is, if lights are emitting intensities (100, 100, 100), the average luminance will be a lot different than if lights were capped at (1, 1, 1).  So how do I choose a good middle gray value?  They say a normal key is 0.18, but I think it would depend on the average luminance which depends on what light scale I choose.

 

Thanks for any advice.


-----Quat

Sponsor:

#2 InvalidPointer   Members   -  Reputation: 1443

Like
3Likes
Like

Posted 25 January 2014 - 07:32 AM

Generally, intensity values like that are unitless unless you specifically work out some scale for them. A fair number of archviz renderers do so in order for them to work nicely with measured IES light profiles. There isn't a *formal* standard with games/the DCC packages used to create their assets, though, as physically-based rendering is just starting to catch on these days.

 

Incidentally, you very much want to establish some sort of PBR framework so the values you feed into the shader(s) are used in a meaningful context, which should hopefully make sense when you think about it.

 

Re: quadratic attenuation-- that should again make some intuitive sense considering real-world light follows the inverse square law. You likely will see better results moving over to a simple area light model, though, as point lights are physically impossible. This would also give you a more sensible attenuation model 'for free.'

 

Lastly, tone mapping is pretty much entirely an artistic process, you fiddle with it until it subjectively 'looks good,' and that's that.


clb: At the end of 2012, the positions of jupiter, saturn, mercury, and deimos are aligned so as to cause a denormalized flush-to-zero bug when computing earth's gravitational force, slinging it to the sun.

#3 Quat   Members   -  Reputation: 414

Like
0Likes
Like

Posted 27 January 2014 - 01:43 PM


Generally, intensity values like that are unitless unless you specifically work out some scale for them. A fair number of archviz renderers do so in order for them to work nicely with measured IES light profiles. There isn't a *formal* standard with games/the DCC packages used to create their assets, though, as physically-based rendering is just starting to catch on these days.

 

So is informal game approach just to take some "standard light" like a typical room light bulb and give it some arbitrary light intensity, say (1, 1, 1), and then define other lights relative to that?  Like if a light should be 4X brighter than a typcal room light bulb, then it will have (4, 4, 4)?

 


You likely will see better results moving over to a simple area light model, though, as point lights are physically impossible. This would also give you a more sensible attenuation model 'for free.'

 

Do you have a link describing such a "simple area light model"?  I thought area lights were mainly for soft shadows, but too expensive to simulate in real-time.


-----Quat

#4 Bacterius   Crossbones+   -  Reputation: 9280

Like
0Likes
Like

Posted 28 January 2014 - 05:46 AM


So is informal game approach just to take some "standard light" like a typical room light bulb and give it some arbitrary light intensity, say (1, 1, 1), and then define other lights relative to that?  Like if a light should be 4X brighter than a typcal room light bulb, then it will have (4, 4, 4)?

 

The scale is irrelevant as long as you are consistent. You can go with physically based units, or come up with something that is easy to estimate and remember and is familiar to your artists or whatever. The end result will be the same because your tone mapping algorithm will (hopefully) use the same units. The only thing you get is convenience in converting from one scale to another and understanding your own scale without having to look it up every time you need to know how bright 1.25 units is.


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS