Jump to content

aeonios

Community Members
  • Content count

    47
  • Joined

  • Last visited

  • Days Won

    4

aeonios last won the day on February 12 2016

aeonios had the most liked content!

Community Reputation

48 Excellent

About aeonios

  1. 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?
  2. 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.
  3. No. That is an incorrect implementation of reinhard. Proper reinhard uses luminance rather than color, like this: 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.
  4. 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.
  5. Have you ever actually written an HDR renderer? :|
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. I actually got into graphics programming in 0ad as a break from AI/unitAI programming in zero-k. 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):
  11. I just got finished tuning up the new combined postproc shader. I posted some screenshots up here: https://code.wildfiregames.com/D1454 It's pretty epic.
  12. Well yeah, it'd break 2.x support. Cascades are awful and don't even do what they're intended to. If you want something like that then lightspace perspective shadow mapping is a far better solution, but it makes shadow filtering trickier due to the non-constant scaling. Cascades just turn the shadow map code into unreadable unmanageable spaghetti, and are also expensive for little to no benefit. Unit cube clipping would also be nice for shadows, as I don't think we're doing that already. I haven't really implemented any of that myself though so I don't know how to make it work. It also requires depth prepass. R11G11B10 is kind of bad since it results in undesirable hue shifts, in particular yellowing. If there's a 10/10/10 format that'd be better, but as I said we have no real use for HDR and if we did then a 10b format would probably not have sufficient bits of precision. Trust me, I've done work with that and there were overflows that resulted in some really weird artifacts. Of course you can fix that by conditionally applying tone rescaling during lighting but I dunno if you can get away with less than 16 bits even then. Again though, that's not anything we have real use for since we're not stacking lighting so we'll never see >1.0. Real HDR is seriously overrated even for bloom, and bloom looks better when it's applied in LDR anyway. Deferred rendering is also only useful if you're using lots of lights, and forward+ is generally better since it lets you use MSAA and translucency. I don't see much case for having tons of lights in 0ad, although there are more than zero cases of flaming projectiles that could possibly use dynamic lights it's not exactly something common. I also did some camera responsiveness tests for comparison and didn't notice much difference between filtering and no filtering.
  13. Yeah I got it. I built wxwidgets the last time I cloned the repo but that was a good while ago so I forgot. I'll just copy over wxwidgets from my old repo and then rebuild. edit: correction, I'm going to have to update and rebuild wxwidgets because the version I'm using is outdated and atlas needs newer. :[
  14. Ah wxwidgets. I totally forgot about that. GL3 would also make soft particles practical, which 0ad badly needs.
  15. Win7 Not really. Most of the performance improvement comes from various rendering functions that reduce the number of draw calls, and all of those are present in GL3.x. The speedups that are possible with GL4.x don't really apply to 0ad since the situations that would allow such speedups simply don't occur. For reference my bargain gfx card supports GL3.3.
×