VERY good water shader here... DirectX but theres a PDF paper on it so maybe a GLSL version could be made...
http://graphics.cs.lth.se/theses/projects/projgrid/
good water shader... VERY VERY GOOD WATER SHADER
eye-poppingly good!
-
Eternl Knight
- Posts: 313
- Joined: Tue Nov 01, 2005 5:01 am
I gave the paper a quick once over after downloading it. I'll look into it in more depth tonight when I get home, along with the code.
From the brief overview I read - this would not bee too difficult to implement in OpenGL as the paper mentions the implementation using HLSL (i.e. should be relatively easy to convert to GLSL).
On the other hand, it may not be so easy to implement an efficient version without some changes to Irrlicht's mesh handling. One of the advantages of the algorithm seems to be the use of a "semi-static" mesh, whereas Irrlicht pretty much recreates the mesh everytime it needs to be sent to the video card. Perhaps after merging some of the IrrSpintz GPU-side vertex buffer code this will be simple.
As I said, this is from a brief glance over the paper. It may be simple to do in current Irrlicht, or impossible without major changes. But at least I have determined that OpenGL is not an issue
--EK
From the brief overview I read - this would not bee too difficult to implement in OpenGL as the paper mentions the implementation using HLSL (i.e. should be relatively easy to convert to GLSL).
On the other hand, it may not be so easy to implement an efficient version without some changes to Irrlicht's mesh handling. One of the advantages of the algorithm seems to be the use of a "semi-static" mesh, whereas Irrlicht pretty much recreates the mesh everytime it needs to be sent to the video card. Perhaps after merging some of the IrrSpintz GPU-side vertex buffer code this will be simple.
As I said, this is from a brief glance over the paper. It may be simple to do in current Irrlicht, or impossible without major changes. But at least I have determined that OpenGL is not an issue
--EK
-
Eternl Knight
- Posts: 313
- Joined: Tue Nov 01, 2005 5:01 am
OK, having reada the paper in depth and looked at the code - it shouldn't be a MAJOR hassle to implement. However, there are a few things that I would need to change in Irrlicht for it to be "plug & play". And it has some limitations that may make it a little less appealing than it originally looks.
First of all, the algorithm relies on a second "camera" object that changes position based on the "real" camera, but with a variety of limitations imposed. This second camera is used to transform a grid of points so that they are space out equally in "screen space" (unlike the usual grid which is spaced out equally in "world/object space").
To make this simpler for the algorithm - there are a few limitations on the second camera that need to be considered if one is going to use the "shader" (which is more accurately a scene node & processing algorithm). Firstly, the camera cannot go "underwater". That is, when the camera goes below the waves (or the waves rise above the camera), the rendering is not so good (in fact - it's terrible). The reason for this mentioned in the paper is that the author did not want to worry about "triangle winding". A more "correct" implementation would be to check the camera's position in relation to the water object and reverse triangle winding/orientation if underneath the waves (and perhaps use an "underwater shader" to add fogging to limit visibility). There is also some stencil-mapping and/or scissor tests than need to be added if you want to limit the water to a small patch rather than an infinite plane (e.g. if you wanted to render a lake/shore rather than something in the middle of the ocean).
Also there is a lot of CPU-side calculations that need to be done. It uses a limited raster algorithm to interpolate across Perlin noise height-map textures (generated at runtime on the CPU) to position the vertices (also done on the CPU). This raster algorithm is also used to create normal maps on the fly to represent the high-level detail that cannot be captured in the geometry.
However, given these limitations, it is a good water renderer. The speed isn't top-notch (22-28 fps on my Radeon 9600), but this I think is more CPU-bound than GPU-bound (due to the software raster of the height & normal maps). I'm pretty sure you could send more the the GPU without large performance penalty. The issue is that your CPU allocation for AI, physics, etc is going to be adversely affected.
The HLSL is incredibly simple to implement in GLSL, so OpenGL implementation would not be a problem.
All in all, if I were making a game with a significant water component, I would add this to Irrlicht in a heartbeat. It would not likely make it into the "official" distribution though because it relies on the co-operation of a variety of components (a view camera, a "projection" camera, and a fast software rasterizer for positioning the vertices and creatinig the normal map). In other words, it doesn't really fit the "generic engine" concept as one would tailor it for any game it was used in. I estimate (for an intermediate programmer not directly copy & pasting) around two days effort to implement and test given the paper and code available.
--EK
First of all, the algorithm relies on a second "camera" object that changes position based on the "real" camera, but with a variety of limitations imposed. This second camera is used to transform a grid of points so that they are space out equally in "screen space" (unlike the usual grid which is spaced out equally in "world/object space").
To make this simpler for the algorithm - there are a few limitations on the second camera that need to be considered if one is going to use the "shader" (which is more accurately a scene node & processing algorithm). Firstly, the camera cannot go "underwater". That is, when the camera goes below the waves (or the waves rise above the camera), the rendering is not so good (in fact - it's terrible). The reason for this mentioned in the paper is that the author did not want to worry about "triangle winding". A more "correct" implementation would be to check the camera's position in relation to the water object and reverse triangle winding/orientation if underneath the waves (and perhaps use an "underwater shader" to add fogging to limit visibility). There is also some stencil-mapping and/or scissor tests than need to be added if you want to limit the water to a small patch rather than an infinite plane (e.g. if you wanted to render a lake/shore rather than something in the middle of the ocean).
Also there is a lot of CPU-side calculations that need to be done. It uses a limited raster algorithm to interpolate across Perlin noise height-map textures (generated at runtime on the CPU) to position the vertices (also done on the CPU). This raster algorithm is also used to create normal maps on the fly to represent the high-level detail that cannot be captured in the geometry.
However, given these limitations, it is a good water renderer. The speed isn't top-notch (22-28 fps on my Radeon 9600), but this I think is more CPU-bound than GPU-bound (due to the software raster of the height & normal maps). I'm pretty sure you could send more the the GPU without large performance penalty. The issue is that your CPU allocation for AI, physics, etc is going to be adversely affected.
The HLSL is incredibly simple to implement in GLSL, so OpenGL implementation would not be a problem.
All in all, if I were making a game with a significant water component, I would add this to Irrlicht in a heartbeat. It would not likely make it into the "official" distribution though because it relies on the co-operation of a variety of components (a view camera, a "projection" camera, and a fast software rasterizer for positioning the vertices and creatinig the normal map). In other words, it doesn't really fit the "generic engine" concept as one would tailor it for any game it was used in. I estimate (for an intermediate programmer not directly copy & pasting) around two days effort to implement and test given the paper and code available.
--EK
-
Eternl Knight
- Posts: 313
- Joined: Tue Nov 01, 2005 5:01 am
Well, as I mentioned - I do not have the need for the shader and hence, given my workload, am unable to implement it. I thought I would share my analysis for those that might be intimidated and/or think that Irrlicht could handle it "as is" (it cannot, there are a few features that need to be made specifically for the "shader" to work).
I apologise if anyone thought that I would be working on it. If it had already solved the (underwater issue), I might have done it for the hell of it. But as my needs do not include super cool looking waves - I cannot justify the time need to implement it and do something about the underwater issue. Especially given (due to the naturee of Irrlicht development & the changes required), the patch would need to be rejiggered everytime a new version of Irrlicht was released.
--EK
I apologise if anyone thought that I would be working on it. If it had already solved the (underwater issue), I might have done it for the hell of it. But as my needs do not include super cool looking waves - I cannot justify the time need to implement it and do something about the underwater issue. Especially given (due to the naturee of Irrlicht development & the changes required), the patch would need to be rejiggered everytime a new version of Irrlicht was released.
--EK