Monday, August 10, 2009

Water Warps!

An acceptable non-HLSL solution for water warps has been found! I can't claim any credit for this - what I did was go through a few different engines and examine their implementations. The FitzQuake "old water" solution, with a non-power-of-2 subdivide size less than 32 was very very good indeed, so I plugged it into my 1.0 codebase to see how it looked there (just in case metlslime had made any changes elsewhere, I wasn't ready to modify my live codebase yet) and the end result was perfect. Some testing on various ID1 maps that are known to have bad water warps in certain areas followed, and confirmed the robustness of the solution.

So that has now migrated across to DirectQ, and the full fixed path has become viable. I made some changes to it, such as calculating the old gl_warpsin.h table in the engine rather than storing it in a header file, and cvar-izing a lot of the parameters for better flexibility and user control. I don't know yet if I'll expose these in the menus, they are really there for "fun" rather than anything else, and messing too much with them could have undesirable effects. The casual audience won't want to know about them and the hardcore audience will find them through the cvar system and examining the code anyway.

One further change is addition of more granularity to the sin table. The old GLQuake default was 256 values; I'm intending to go up to 1024 or 2048 here. This will result in much smoother warps overall, which - as always - can only be a good thing.

Performance wise, which is important, it's quite a bit faster than the pixel shader method (because sin calcs come from a lookup and are per vertex, rather than being "raw" and per pixel).

Speaking of performance, one odd effect of moving back to fixed functionality is that things in general have become a coupla percent slower. I'm assuming that this is because I now have state change overhead rather than just being able to do calculations on raw data in shaders. On the other hand the fixed functionality path is not optimized at the moment, so there is room for some gains.

Anyway, credit and thanks to metlslime is very much due here.

0 comments: