|
|
For the DoF: I interpolate the blur buffer and the "lighting buffer" (the one that contains the result of the whole lighting + fx).
On the picture, well, the DoF Power was high, and maybe the blur buffer is too blury for your taste.
I thought of that too, but it's easy to keep an intermediate "blur buffer" when doing the multi-pass bluring, to use a more "sharp" version.
For Shadows, yes I do care about the patent pending of the TSM.
For Codeg, I'd love to use something that already exists if it's good! :)
I've looked most of the papers about shadow mapping, the article of Kozlov in the GPU Gems is definitly the most advanced/concrete I've read. And the nVidia's Gary King sample is a good starting point too.
Transparency:
Yes, this is a good point...
For me, transparency is most of the time used for particles effects, and glass materials (cars, windows, ...).
For the first one, I prefer doing that in Post Production (as it's not really dependent of the lighting). Using deferred shading, as you have access to the pixels' Z, you can fix the graphic artifact that occurs when a particle crosses a solid surface, which is great.
For Glasses well and other stuffs (I didn't think about/accounter), I have two options:
1) Use a "standard rendering path", done directly on the lighting buffer. This is your call to support per-pixel lighting, one/many lights.
2) Create a second set of MRTs and having fun doing each "transparency part" one by one. Of course, the cost in term of memory and speed is high...Too high for the result in my opinion.
And of course there's a secret third option: doing a mix of the two previous.
When programming a DS Renderer, really think about you CAN and HAVE TO do a lot of post-prod, because it's possible, and that's the way to produce great graphics (just look at the importance of post-prod in broadcast rendering).
I'll write later on my log page about the system I made, which "shares" all the intermediate buffers in a post-prog plugin interface, computing one given buffer only when at least one plugin needs it. You quickly find yourself using a given buffer (like the blur one) for many things, and of course the MRTs database is very useful in that stage too.
One last thing about DS, I may be wrong, but for me this is the technique to use on future consoles, mainly because the screen resolution is smaller than on PC.
|
