(click to enlarge)
Did a little bit more work on my water renderer but as far as I'm concerned its still both poor looking and incomplete.
The main difference from last time is that I now render a "depth texture" that computes the depth of the water across its surface. This can then be used as an input into the rendering of the actual water effect; the basic idea being that I can use it to scale any effects/contributions based on how deep the water is.
The problem, as shown on the right-hand image is that it now looks like theres "stuff" floating on the surface. Might just be because of the current implementation (just alpha scaled by depth) but it might prove to be a rather ugly artifact.
At a 512x512 texture (shown above) I get a 30fps hit (150fps down to 120fps) due to having to re-render all the geometry. Its a bit of a heavy-weight process but it is completely dynamic. Drop some objects in or change the landscape and the depth texture will update accordingly. I was thinking about having some fish (or a submarine) floating around underwater and this would Just Work(TM).
In other news... I found an unfortunate problem with smart pointers and the DXUT framework [headshake]
You may have noticed that, upon memory leaks, the DXUT framework will pop-up a message saying that the device was released with a non-zero reference count. If you've got the debug runtimes enabled you then get the 1000's and 1000's of lines of stack traces.
Now, if you declare a smart pointer at the global scope it doesn't always seem to get cleaned up before DXUT but it does get cleaned up eventually. Presumably just a characteristic of C/C++ scope rules.
Anyway, DXUT throws up a message complaining about memory leaks when, in truth, there aren't any. This is a bit annoying.
You can always hack away at the DXUT code and remove the warning but thats not so pretty. I've emailed MS about it to see if they have any insight but I doubt theres anything to be done to "solve" this.
In a related bit of profiling it seems that using smart pointers to make a defensive copy of the swap chain (see my original entry for details) is 22% slower. A difference of a whole 6 microseconds [smile]
That is all for now.
While this isn't as flexible as your system, it only takes one pass [smile].
OTOH, I've decided to completely scrap both this system and the terrain renderer and start over [headshake].