Jump to content
aeonios

Graphics Improvements

Recommended Posts

I actually got into graphics programming in 0ad as a break from AI/unitAI programming in zero-k. :P Making shinies is fun!

 DoF can be disabled by disabling postproc, although making dof and bloom separately enableable would be pretty trivial.

Anti-aliasing would indeed be nice. DoF especially makes aliasing painfully obvious (and you'd think that a blur would hide it, but no). FXAA is probably a bad choice though. It has a bad tendency to blur everything into oblivion, especially for small units or anything with a complicated texture. It's also potentially very expensive, especially when it's hitting false positives and blurring things that it shouldn't be.

MSAA would be nice though. I guess I'll look into that soonish. I don't think it should be that difficult though, afaik all you have to do is set up a multisampled depth texture and then enable MSAA rendering in GL state.

Bonus screen shot (it begged to be taken):

 

screenshot0018.png

  • Like 1

Share this post


Link to post
Share on other sites
5 minutes ago, aeonios said:

Bonus screen shot (it begged to be taken):

If you would look at these white roofs, you may notice, that you still see not black shadows. Our HDR doesn't work as HDR :)

Share this post


Link to post
Share on other sites

I think the problem with the roofs is more of an art problem. You don't see super bright super clean whites like that in nature, and they're kind of obnoxious. Also lambertian diffuse lighting is a bad model for rough surfaces like a plaster roof. That'd need oren-nayar and a better material system. I don't really see any issue with the shadows there though.

Share this post


Link to post
Share on other sites

HDR honestly does nothing when it comes to lighting unless you're stacking lights that might cause a color overflow. Screen pixels are 0..255 intensity and you cannot exceed that no matter how big your delusional ambitions are. Also I still don't see what you're talking about. The side of that building is red, and the sides of the houses are white, which is why they show up relatively bright even in shadow.

Share this post


Link to post
Share on other sites
4 minutes ago, aeonios said:

HDR honestly does nothing when it comes to lighting unless you're stacking lights that might cause a color overflow. Screen pixels are 0..255 intensity and you cannot exceed that no matter how big your delusional ambitions are. Also I still don't see what you're talking about. The side of that building is red, and the sides of the houses are white, which is why they show up relatively bright even in shadow.

Bloom simulates a very light things, but you still can see all details in shadows. It's wrong and looks weird. Obviously that a pixel color usually can't exceed the 255 limit. So HDR shouldn't be just rendered as is, it should be converted to LDR with a color correction.

FYI: http://marcinignac.com/blog/pragmatic-pbr-hdr/

Share this post


Link to post
Share on other sites

Bloom is actually on a really low setting in that screen shot, and has little to nothing to do with the lighting of those houses. I don't think HDR does what you think it does.

Share this post


Link to post
Share on other sites
6 minutes ago, aeonios said:

Bloom is actually on a really low setting in that screen shot, and has little to nothing to do with the lighting of those houses. I don't think HDR does what you think it does.

I didn't mean the lighting from bloom, I mean a visual effect for players. HDR allows you to store a true brightness of each pixel, so on the HDR>LDR step you will get a more correct lightning.

Share this post


Link to post
Share on other sites

No, if you implement tone mapping correctly then shifting from HDR to LDR will give you the exact same result as if you'd used only LDR. In fact the reinhardt tone mapping algorithm in that link you gave was actually wrong. Exponential tone mapping causes non-linear hue shifting which cannot be corrected by any means, and leads to the sort of ugly "looking at the scene through polarized sunglasses" look that everyone associates with HDR. People claim that it has magical powers to make the lighting better or to "bring out details" but really all they've done is to distort the colors beyond recognition.

Share this post


Link to post
Share on other sites
9 minutes ago, aeonios said:

No, if you implement tone mapping correctly then shifting from HDR to LDR will give you the exact same result as if you'd used only LDR.

It's not correct. Just do a simple math: in case you have a very light color: (R:1e6, G:1e3, B:1e3), then with LDR it will be (R:255, G:255, B:255), but with HDR it will have a different distribution depended on the gamma. So you're missing a color itself with only LDR. (If you are using HDR/tone mapping as a separate step, not all things (model lighting, hdr, color correction, etc) together in a one shader).

Share this post


Link to post
Share on other sites
26 minutes ago, aeonios said:

Have you ever actually written an HDR renderer? :|

Yes. And I think we're talking from different sides and we don't understand each other. What I mean:

Rendering scene into a float (i.e. RGB32F) buffer with original brightness (vec3 color) > selecting a gamma (by a pregame setting or on the fly) (float gamma) > a simple tone mapping (like the Reinhard one) (color = color / (color + vec3(1.0)); > a gamma correction (color = pow(color, vec3(1.0 / gamma)).

Share this post


Link to post
Share on other sites

It'll more than likely get its own option in graphics settings one way or the other. The only reason I've got it set to always on right now is because I don't know how to configure user options.

  • Thanks 1

Share this post


Link to post
Share on other sites
57 minutes ago, vladislavbelov said:

Yes. And I think we're talking from different sides and we don't understand each other. What I mean:

Rendering scene into a float (i.e. RGB32F) buffer with original brightness (vec3 color) > selecting a gamma (by a pregame setting or on the fly) (float gamma) > a simple tone mapping (like the Reinhard one) (color = color / (color + vec3(1.0)); > a gamma correction (color = pow(color, vec3(1.0 / gamma)).

No. That is an incorrect implementation of reinhard. Proper reinhard uses luminance rather than color, like this:

Quote

vec3 toneMapReinhard(vec3 color){
    // float whitePoint = 1.0/exposure;
    const float whitePoint = 1.0;
    float lum = dot(color, vec3(0.2990, 0.5870, 0.1140));
    float ilum = (lum * (1.0 + (lum/(whitePoint * whitePoint))))/(lum + 1.0);
    return color * ilum/lum;
}

otherwise you get nasty non-linear hue shifting. With proper reinhard tone mapping if you input an LDR image in the 0..1 color range you get the exact same image back out, but with your implementation you don't.

If you simplify the above formula for exposure == 1 you get ilum = (lum * (1.0 + lum))/(lum + 1.0), and gamma is optional.

Share this post


Link to post
Share on other sites
21 minutes ago, aeonios said:

No. That is an incorrect implementation of reinhard. Proper reinhard uses luminance rather than color, like this:

You understood me incorrectly. I didn't said that my implementation is the correct Reinhard one, I only mentioned that the Reinhard is simple and can be used easily here too.

Lets return to the HDR. I said, that I prefer HDR > LDR than LDR > LDR for not one-pass pipeline. Because a loosing of high color values, that stops artists/modders to change exposure/gamma freely. Please, look at the example that send above: http://marcinignac.com/blog/pragmatic-pbr-hdr/305-exposure-basic/. For disabled gamma (doesn't make sense what it means in this context) and some exposure values all dark or light areas are losing details. So my point is to use float textures for g-buffer like data when possible.

Share this post


Link to post
Share on other sites

You understood me incorrectly. I didn't said that my implementation is the correct Reinhard one, I only mentioned that the Reinhard is simple and can be used easily here too.

Lets return to the HDR. I said, that I prefer HDR > LDR than LDR > LDR for not one-pass pipeline. Because a loosing of high color values, that stops artists/modders to change exposure/gamma freely. Please, look at the example that send above: http://marcinignac.com/blog/pragmatic-pbr-hdr/305-exposure-basic/. For disabled gamma (doesn't make sense what it means in this context) and some exposure values all dark or light areas are losing details. So my point is to use float textures for g-buffer like data when possible.

Using floats for color data is ridiculously expensive and unnecessary unless you want to write a professional image editing application or something. Floats do give you greater precision but that's not really needed in games. Gamma and exposure are probably unnecessary things for an artist to need to worry about. We already have full control over lighting and everything else. If the "exposure" is too low then make the lighting brighter, and if it's too high then tone it down. Simple stuff. You can control both the direct lighting and the ambient, plus sun overbrightness, which gives you a lot of options already.

That screenshot above was taken on bactria, but I modified all the lighting and fog settings to get it to look the way I wanted. If you have a complaint complain about the settings, not the totally unrelated shader.

Edited by aeonios

Share this post


Link to post
Share on other sites
16 minutes ago, aeonios said:

Using floats for color data is ridiculously expensive.

Only if you can't use it.

16 minutes ago, aeonios said:

unnecessary unless you want to write a professional image editing application or something. Floats do give you greater precision but that's not really needed in games. 

Most of all modern games use it (i.e. GTA V, 16bit float per component, the pretty fast game).

18 minutes ago, aeonios said:

We already have full control over lighting and everything else. If the "exposure" is too low then make the lighting brighter, and if it's too high then tone it down. Simple stuff. You can control both the direct lighting and the ambient, plus sun overbrightness, which gives you a lot of options already.

No, we don't have a "full" control yet in the pyrogenesis. Because in the first pass we render a scene into a simple RGBA buffer (8bit per component) and the "HDR" shaders works on the next pass with already clamped values. So the precision is low.

25 minutes ago, aeonios said:

That screenshot above was taken on bactria, but I modified all the lighting and fog settings to get it to look the way I wanted. If you have a complaint complain about the settings, not the totally unrelated shader.

I like changes, but there is a problem, we have many maps. And artists/modders may want to use different settings. So it'd be ideal to fully customise the shader.

  • Like 1

Share this post


Link to post
Share on other sites
9 hours ago, vladislavbelov said:

I like changes, but there is a problem, we have many maps. And artists/modders may want to use different settings. So it'd be ideal to fully customise the shader.

Well adding exposure and gamma controls would be pretty trivial. Setting up the options in atlas would be more difficult than the actual shader code. I guess the options in atlas need to be updated anyway so why not?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×