Yes, definitely. You can set the exposure value manually if you want-- many games do just this! (CoD:BlOps and possibly MW3 in particular)
EDIT: I'm pretty sure Source/Half-Life 2 lets you goof with exposure as well, though they do have a wonky fake-exposure trick due to their clever-as-hell in-shader tonemapping operation.
Also, HDRBlendable is (I think) the FP10 format. It should render slightly faster since you write half as much (assuming you're fill-bound, which isn't all that uncommon in high-overdraw scenarios with cheap shaders-- much like a light prepass renderer) as a traditional FP16. You can also experiment with fixed-point encoding schemes if you're willing to give up multipass rendering, though I don't think that's actually an option for you.
Behavior of energy conserving BRDF
Btw I changed from rendering specular to a seperate Buffer, to just rendering it in the alpha channel and then multiplying the color from my specularmap with it later in the 2. geometry pass with the N.L * N.H term. Is there any difference/wrong with this?
If you do this, you'll only have monochrome specular highlights instead of them matching the color of the light. You can try and cheat by multiplying the specular intensity with the color of the diffuse lighting at that pixel, but that still won't be correct.
Also does it make sense to use tone mapping without having any kind of luminance of exposure control ?
It can still make sense to do it since tone mapping will give you a nice mapping of really bright values to brighter colors. If you don't tone map you'll just clamp at 1, which doesn't produce great results. However you'll be effectively stuck at 1 exposure value, which won't allow you to adapt to drastically different lighting conditions. To do that you would either need to set exposure manually (like InvalidPointer) susggests, or implement some sort of auto exposure routine.
Also, HDRBlendable is (I think) the FP10 format. It should render slightly faster since you write half as much (assuming you're fill-bound, which isn't all that uncommon in high-overdraw scenarios with cheap shaders-- much like a light prepass renderer) as a traditional FP16.
It's FP10 on the 360, but FP16 on the PC. However XNA won't let you use filtering that format even if your GPU supports, since it enforces compatibility with the 360. This is also why it won't let you blend HalfVector4.
But in a light pre pass renderer I have to render all geometry a second time anyway. So I'd have access to my material ID's and everything again there.
So what am I missing when just rendering out the (N.L * N.H) term and afterwards before putting it together with the lighting multiply it by the specular color defined by the specular map ?
So what am I missing when just rendering out the (N.L * N.H) term and afterwards before putting it together with the lighting multiply it by the specular color defined by the specular map ?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement