It occurs to me that I've talked a lot about the new HDR lighting mode, but I haven't actually shown you anything. Let's change that.
Here's a few shots of a pretty standard Quake rocket explosion. Nothing fancy, the kind of thing that happens all the time in regular ID1 Quake. I've tinted the explosion orange so that you can see the results better, especially in the second case.
First up we have overbrighting disabled. This is what GLQuake looks like. The light saturates to white all the way to the edges, where there are some small fringes.
Next we have standard 2x overbrighting; this is what most modified engines use (either as a default or available as an option). It's getting better, but notice the way the light starts to turn green towards the center. (We also lose a bit of precision.)
Finally we have HDR lighting. The green is gone and we have the full colour range all the way throughout the light radius. We could achieve similar with 4x overbrighting, but then we'd be losing two bits of precision.
The HDR method completely avoids any precision loss up to a value of 287, beyond which it scales down gracefully with no abrupt transitions, retaining better precision than either of the other two methods up to around 546 (beyond the point at which 2x overbrighting would have clamped).
Sunday, September 25, 2011
HDR Lighting - Screenshots
Subscribe to:
Post Comments (Atom)
21 comments:
Yup, HDR wins, I'm in favor of adopting it :D
very nice, HDR and relatively cheap too!
This is, in principle, a really great thing.
For rocket explosions, that is.
If the price for using this to light an entire map is that the overall quality of the lightmap is decreased, then I'm not so sure. Quake's lightmaps are already utterly low res.
Also lightmaps seem to generally be displayed wrong on my hardware (nvidia 6x) because of the half float usage or something like that.
It's hard to light your map with this when you can't see the results as they look for other people.
Unfortunately.
But as I said, in principle it seems nice. Why can nothing ever be easy.
Well having gotten it working, the key point is that the overall quality is not decreased.
Between values of 0 and 287 the quality is the same as GLQuake (no overbrights) and twice as good as a modded engine with overbrights (as it doesn't need to lose a bit of precision).
Between values of 288 and 500-odd the quality is on average better than a modded engine with overbrights.
Above that range the quality drops off, but a modded engine with overbrights can't handle that kind of lighting range anyway, so one could say that it's still better.
What you saw originally was an earlier (and wrongly done) version of this that did have drop off. It's been fixed now.
I don't want people getting the idea that there is any kind of overall quality loss on account of this, because there isn't.
next step - replace or replace that ugly sprite. lighting looks great!
replace or delete :-)
"next step - replace or replace that ugly sprite."
The sprite stays. ;)
DirectQ isn't that kind of engine.
MH,
I sent Lord Havoc a bug report for the Mac OS X PPC version of Darkplaces, and this was his response to the supported Music locations in Darkplaces, even though his documentation is not updated to reflect all of this:
"The supported locations are:
QUAKE/id1/sound/cdtracks/track002.ogg
QUAKE/id1/music/track002.ogg
QUAKE/id1/music/cdtracks/track002.ogg
QUAKE/id1/sound/cdtracks/track02.ogg
QUAKE/id1/music/track02.ogg
QUAKE/id1/music/cdtracks/track02.ogg
Similar for track003, track004, etc." -LORD HAVOC
Music is not playing at all in his stable 6/28, PPC build under Mac OS X 10.4.9 Tiger
Thought this music info would be of use to you concerning our last discussion. BTW, when I turn on HDR in Darkplaces in Window it appear like the same blurry looking mess as when bloom is enabled on it. An I was a professional photographer for 30 years so I know what HDR is supposed to look like, at least in photos I believe my games,Fallout 3, Oblivion and Bioshock all have HDR lighting, if I'm not mistaken.
In my Darkplaces it looks like the effect I would achieve if I use one of the following on my camera:
a soft focus filter, a very dirty lens, a very, very poor quality lens water droplets, a filter smeared with petroleum jelly, a piece of a metal window screen etc.
These are all things that diffuse the light source. It is hard to tell how they look in your screen shot even when clicked on, because they don't enlarge very much, but I hope the result is better than Darkplaces. I am going to test it again to confirm the blurry, look with HDR enabled.
Regards,
MF
I need to proof read before I send Ha! Especially since my degree was in Photojournalism!
MH
about the sprite
it's your engine so you surely have the last word, but seriously... you like it? i understand you want to make mhquake as faithful to the q1 origin as possible, but this is beyond my comprehension. you want to leave the sprite intact because that's the way how it looks in the old q1 no matter how ugly it it? what's the difference between changing that green light into something more explosion-like-effect and changing /or at least deleting/ that ridiculous sprite?
please, don't take this as an personal insult.. it's just a question :-)
"you want to leave the sprite intact because that's the way how it looks in the old q1 no matter how ugly it it?"
That's a very important reason. I'd love to replace it with something better for sure, but think about the side-effects. What if a mod provided their own custom explosion sprite and that ended up being replaced too. The mod author would be fully justifed in saying "don't use DirectQ because it doesn't respect mod authors content". What if the replacement was considered a cheat by the multiplayer community? What if the new one dragged performance down on Intel graphics?
Every new feature has consequences that are often not understood until a long time after. The aim is - original game, original content, no messing, no nasty surprises for anyone.
I feel justified replacing the particle dot because that was procedurally generated in the engine anyway. I feel justified doing HDR lightmaps because that's just a way of overcoming hardware limitations. Replacing a sprite is the beginning of a slippery slope.
Besides, DirectQ has spr32 support which could be used to provide your own replacement.
MH,
I take back what I stated about the HDR in Darkplaces. He calls it HDR Bloom and I'm no longer experiencing the extremely blurry, diffused look in the newest autobuild. I don't know if it is the new build, or the fact that I deleted the Darkplaces .config file a few days ago, but now it looks good. Plus he has so many setting and undocumented settings, that it is sometimes hard to tell for sure. Don't take this the wrong way, it is intended to be positive. many of Darkplace's new features are in the autobuild change logs, but it is hard to keep up with what is changed and I fully understand that the fixes are much more important than keeping up with the documentation.
In fact, I just looked again, and with bloom and HDR bloom, with the the re-texturing project's Hi res and normal map textures, DarkPlaces looks great, so I'm sure DirectQ will also, without the huge performance hit that DP takes on my old, outdated system.
I can't wait to be able afford a new, duel or quad core system.
The Geforce 7600 GS 512 I'm sure has a lot to do with that, also.
It does support SM 3 and OpenGL 2.1, I believe, though.
Great work on the HDR Lighting in DirectQ. As always, I am looking forward to the next release.
Regards,
MF
SM3 is good; that's another thing on my wish-list for everyone to have (I could dump a lot of horrible code if so).
I don't do bloom and am very unlikely to ever do it. It has no visual appeal for me, always looks very artificial, and is normally overdone.
My HDR lighting just extends the dynamic range of textures so that we don't need to clamp them.
what's the difference between changing that green light into something more explosion-like-effect and changing /or at least deleting/ that ridiculous sprite?
The sprite is an original Quake/GLQuake art asset. The color clamp shifting artifact wasn't present in the original renderer because the original renderer had no colored lighting. Thus it seems quite justifiable to address that issue, as it relates not to the original game and its assets but due to the introduction of visual features not present in the original renderer.
thanks for answer regarding my "sprite issue". i didn't notice that mhquake suport spr32. will try it.
-
jakub
"I don't do bloom and am very unlikely to ever do it. It has no visual appeal for me, always looks very artificial, and is normally overdone.
My HDR lighting just extends the dynamic range of textures so that we don't need to clamp them."
MH, I agree with you totally on this concerning bloom. I guess if you have cataracts, major astigmatism, or dirty glasses on the world does look like the overdone bloom that you describe.
I like my games sharp but with some anti aliasing.
BTW, I was using FXAA in Bioshock 2 and it looked pretty good if tweaked properly, but had to much of a performance hit when using also their postprocessing effects such as bloom and the other optional ones. It was in very active development until about the time that University students went back to school, then it totally stopped, or they learned that Nvidia will, for certain, turn that bit on in their drivers for DirectX. I didn't notice much of a performance hit with just FXAA turned on, though.
Here is the developer that works for Nvidia that has also released his code to the public:
http://timothylottes.blogspot.com/
Here is the original German site that used his code, in Google Translate:
http://translate.google.com/translate?js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&sl=de&tl=en&u=http%3A%2F%2Fwww.forum-3dcenter.org%2Fvbulletin%2Fshowthread.php%3Ft%3D510658%26page%3D26
http://www.forum-3dcenter.org/vbulletin/misc.php?do=showattachments&t=510658
SVN for FXAA with postprocessing effect:
https://www.assembla.com/spaces/fxaa-pp-inject/documents
http://www.realtimerendering.com/blog/fxaa-rules-ok/
http://www.hardocp.com/article/2011/07/18/nvidias_new_fxaa_antialiasing_technology/
I tried it in DirectQ about a month ago and it blue screened my system, unlike other games I had tried it in, I'm not sure why, though.
When FXAA, only, is more mature and actually incorporated in the drivers by Nvidia and AMD, it might be a light weight solution for DirectQ. BTW, it works with AMD cards, also.
Just some food for thought.
Marty
MH I forgot to point that DNF used a very early (I would call beta), poorly implemented version of FXAA code. You can actually view Timothy Lotte's early code in the shader folder of DNF. This may be well beyond your project goals of DirectQ, but again, food for thought.
Here is also a link to Nvidia's white paper on FXAA:
http://developer.download.nvidia.com/assets/gamedev/files/sdk/11/FXAA_WhitePaper.pdf
Marty
Post-processing isn't cheap, unfortunately. There's a lot of fillrate cost in doing a render to texture pass, then drawing that again to the screen. The only way I could reasonably justify it would be if I was doing so much PP that it was always on anyway, but right now the only PP I do is for the underwater warp (which is quite heavily optimized but can still cut framerates almost in half).
I also use render to texture for mapshots. Quake's varying 3D viewport size does complicate things a lot more than should be necessary though.
I did have an idea to do cheap-n-cheezy AA by means of render to texture to a texture larger than the screen size then sampling it down. No idea what it would look like (or what the perf would be like).
Overall my preference is to just use the AA supplied by Direct3D. It may not be the best, but it's there, it's going to be optimized and it's going to stand the best chance of working everywhere.
FXAA only with no post processing add ons, is supposed to be much less intensive than standard FSAA.
http://timothylottes.blogspot.com/2011/03/nvidia-fxaa.html
http://www.techspot.com/review/436-deus-ex-human-revolution-performance-test/page6.html
http://forums.anandtech.com/showthread.php?t=2179075
That is the whole idea of FXAA, to reduce the performance hit over traditional AA at an only slight reduction in image quality. I agree though that the extra postprocessing effects in the user code on the 3D Center website does have a performance hit. That is from my own personal experience using them The extra ones are:
"#define USE_PRE_SHARPEN
#define USE_BLOOM
//#define USE_TECHNICOLOR
#define USE_TONEMAP
//#define USE_SEPIA
//#define USE_VIGNETTE
#define USE_POST_SHARPEN
#define USE_FINAL_LIMITER"
that is from the actual config file.
Like I said just food for thought maybe when Nvidia and ATI actually enable it in their drivers.
Right now it is a hidden setting in the Nvidia drivers and is only implemented at the driver level for OpenGL games. It can be enabled with Nvidia Inspector.
Rumor has it that Nvidia may be just around the corner in implementing it at the driver level for Direct X. Of course I am not a programmer I just thought it might be useful for the future.
Regards,
Marty
I've read the FXAA whitepapers and it is dependent on being plugged into an existing PP pipeline. That you are using PP all of the time is an assumption of the technology. Based on that it's not going to be an option.
Thanks for clarifying that.
Post a Comment