Jump to content

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
Link to comment
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.

Link to comment
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.

Link to comment
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/

Link to comment
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.

  • Like 1
Link to comment
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.

Link to comment
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).

Link to comment
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)).

Link to comment
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.

Link to comment
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.

Link to comment
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
Link to comment
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
Link to comment
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?

Link to comment
Share on other sites

  • 4 weeks later...

Welp, I ended up implementing percentage closer soft shadows. I wasn't originally planning to because I thought it'd be unworkable in openGL, but I got bored and made it work anyway. Sadly none of this will be in the game until a24, but at least it makes pretty screenshots. :P There are still plenty of things to do for graphics (mainly performance improvements) but for now I'm considering diving into the random map generator and improving the quality of the maps it produces. Right now the maps it creates tend to be boring or ugly, have bad lighting/environment settings, are often imbalanced, and so on. I think it could definitely produce some stunning maps that are well balanced and fun to play, it's just a matter of tinkering with the settings and generation scripts.

Some screenshots of PCSS+DOF:

screenshot0049.thumb.png.e8e1ebcf17f1c72cf6efb68705d114ef.pngscreenshot0053.thumb.png.87c98d68b0b66f8b2027fc0f78219613.pngscreenshot0054.thumb.png.85dbbca2d7f8e7f1aa1730d06e4a7be8.png

  • Like 3
Link to comment
Share on other sites

But... I like sharp shadows... at least for a "sunny" scene.

"Soft" shadows indicate a lot of ambient light, such as during a cloudy day. It would be great to be able to adjust this, maybe with a slider, so that a cloudy/rainy scene can have really fuzzy shadows, while a "high noon" desert scene can have sharper shadows.

Edited by wowgetoffyourcellphone
  • Like 6
Link to comment
Share on other sites

@aeonios Not to discourage you or anything but it's been ages since we last had a graphics programmer. We already have two people working on the random map generation and @elexis has done a huge cleanup on the codebase. Fixing shadow issues and adding some fancy graphic features would do the game a lot of good :) fixing the skybox too.

Link to comment
Share on other sites

4 hours ago, wowgetoffyourcellphone said:

It would be great to be able to adjust this, maybe with a slider, so that a cloudy/rainy scene can have really fuzzy shadows, while a "high noon" desert scene can have sharper shadows.

Probably it should go together with the "Weather" option.

4 hours ago, wowgetoffyourcellphone said:

But... I like sharp shadows... at least for a "sunny" scene.

"Soft" shadows indicate a lot of ambient light, such as during a cloudy day.

Yeah, obstacles should be far away to have such blurry shadows. Or a pretty cloudy weather.

47 minutes ago, stanislas69 said:

Not to discourage you or anything but it's been ages since we last had a graphics programmer.

We have @wraitii and Phillip. I'm not active currently in the renderer (I hope I will), but I review patches for it. So all graphic improvements are welcome :)

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...