sRGB/gamma correct colors

[Radikalizm]

Yes, I am working on parallax mapping right now.

About your gamma space - I don't quite understand. Could you make it clearer(or post some link)?

Here's a good explanation on linear lighting : http://filmicgames.com/archives/299

I couldn't explain it any better myself

[ent1ty]

That is very interesting. Thanks.
Any idea how could I implement this resource consumption-friendly under OGL?

[Radikalizm]

That is very interesting. Thanks.
Any idea how could I implement this resource consumption-friendly under OGL?

When using it in a deferred context you don't have to do your gamma correction on every texture read, just store your gamma space textures in your g-buffer and convert your albedo texture to linear space during light accumulation by applying a power of 2.2, you can convert it back either at the end of the light accumulation pass or in a post-processing effect
Only do this in a pp-effect when using a high enough precision though, when using 32-bit depth with 8 bits per channel you'll probably lose precision

[hendu]

Heh, even the author of that article admits it looks worse than the "improper" default color handling

[hybrid]

Strange that this topic comes up right now. But I've actually commited an addition in SVN/trunk yesterday, which takes care of the sRGB (gamma) conversions automatically. So images are loaded as sRGB (at least this is usually the case), then dx9 and opengl can convert automatically to linear space, do their calculations internally in linear space, and write back the color values to sRGB into the framebuffer. This should bring up much more naturally looking renders. Just give it a try and enable the device flag upon creation.

[Radikalizm]

Heh, even the author of that article admits it looks worse than the "improper" default color handling

I think you misinterpreted that, when doing lighting in gamma space it's possible to automatically get a more pleasing (but unrealistic) image
When using linear lighting you'll need to tweak your pipeline somewhat to get a good looking image, which isn't that big of a hurdle

[ent1ty]

hybrid: won't that also mess up my G-buffer textures?

[hendu]

I think you misinterpreted that, when doing lighting in gamma space it's possible to automatically get a more pleasing (but unrealistic) image
When using linear lighting you'll need to tweak your pipeline somewhat to get a good looking image, which isn't that big of a hurdle

How so? To me the point was that the default colors aren't 100% realistic, but they look better. Thus if you do this to have realistic colors, you have extra overhead from doing that, but need more processing on top of that to get a nice-looking image.

That's a lose-lose, I see no advantage at all in doing colors the "proper", gamma-corrected way.

[hybrid]

Well, reading textures leads to linearization, while writing adjusts the gamma again. So operations like blend and lighting will have a linear color space, while output happens in gamma corrected numbers. So unless you rely on manually written pixel values it should be ok throughout the pipeline.
Only changes that I noticed so far is that the background color (framebuffer clear) changed its colors. Since it's an explicit value, it's assumed to be in linear space, and gets gamma corrected on write. This will probably also happen to vertex colors, which are explicitly set.
Most floating point textures are also not subject to this conversion, only RGB textures are.

[Radikalizm]

I think you misinterpreted that, when doing lighting in gamma space it's possible to automatically get a more pleasing (but unrealistic) image
When using linear lighting you'll need to tweak your pipeline somewhat to get a good looking image, which isn't that big of a hurdle

How so? To me the point was that the default colors aren't 100% realistic, but they look better. Thus if you do this to have realistic colors, you have extra overhead from doing that, but need more processing on top of that to get a nice-looking image.

That's a lose-lose, I see no advantage at all in doing colors the "proper", gamma-corrected way.

First of all, if you adjust your pipeline correctly there is absolutely no overhead for doing linear-space calculatons (as you could see in the article, it is possible to let the hardware handle the conversion itself)

Second of all, linear-space lighting , besides being more realistic, gives a more intuitive approach to handling your scene since your result won't get skewed, and allows for better and more precise effects (eg. post-processing)


There's a reason why developers of next-gen graphics applications and games are moving to linear-space lighting models (if they didn't have them already)

[hendu]

Extra effort done by hardware != no effort. Even if hw-accelerated, it is a nonzero increase.

Second of all, linear-space lighting , besides being more realistic, gives a more intuitive approach to handling your scene since your result won't get skewed, and allows for better and more precise effects (eg. post-processing)

Yeah, letting hw take care of it is easier than worrying about gamma yourself. But I still don't see what is there to worry about; in all comparison images I've seen, the naive, ignore-gamma way looks better. It may be skewed, but it looks better & is no extra effort.

[Radikalizm]

Extra effort done by hardware != no effort. Even if hw-accelerated, it is a nonzero increase.

The time needed to do this conversion is completely neglectable, there's no point in making an issue out of that

Yeah, letting hw take care of it is easier than worrying about gamma yourself. But I still don't see what is there to worry about; in all comparison images I've seen, the naive, ignore-gamma way looks better. It may be skewed, but it looks better & is no extra effort.

It all depends on what you want to do of course, in non-photorealistic scenes the lighting model won't really matter, it'll just be a matter of personal preference, in photorealistic scenes however your specular hightlights will be completely off for example (like mentioned in the article)
Now most irrlicht projects don't really get to the bar of being called 'photorealistic', but if someone would want to take it to that level they'd need to convert their lighting pipeline so it uses a linear model to get correct results

Btw, some other interesting articles on the same site: http://filmicgames.com/archives/557 and http://filmicgames.com/archives/547

[hendu]

I agree, I was going on the premise of a game. Photorealistic simulation is different of course.

Though for realism, it's not far from being able to raytrace in realtime but that's offtopic.

[Radikalizm]

I agree, I was going on the premise of a game. Photorealistic simulation is different of course.

Though for realism, it's not far from being able to raytrace in realtime but that's offtopic.

Of course, a lot of next-generation games go for a photorealistic solution (most modern FPS games for example)

I like the idea of linear lighting since I want my engine to be very flexible, being able to handle photorealistic scenes and more cartoon-like scenes (the pokemon project I mentioned in the 'tapeworm' thread is also to show that my engine is flexible enough to support different styles) at the same time

[hybrid]

I foundn this one really convincing
http://http.developer.nvidia.com/GPUGem ... _ch24.html