Shorelines....
by Melv May · in Torque Game Engine · 06/29/2002 (7:56 pm) · 59 replies
Hi,
I managed to get some time this weekend to go back to some previous work with the fluid rendering code.
I have been trying various techniques to get a better shoreline from the code. The way the existing fluid intersects the terrain is crude (looks like mercury in a cup someone on the forums once said) so I have attacked that problem.
What I've produced is an alpha map for the surface textures based upon height from the terrain. I found that the alpha function for shallow shorelines was completely different from the steep-shores and so I eventually came up with a nice 'sigmoid' function which allows me to control the slope with one simple parameter.
The other problem is that the terrain height-map is low-res and the waterblock mesh is dynamic according to the LOD. This leads to really coarse depth calls at undetermined locations. I got around this by simply convolving the alpha-map through a few interations. Note that the standard terrain lightmap looks much better after a similar interative convolution.
Here are some examples of the alpha-map in action. Note that I'm not texturing here as it distracts from the fade itself.
Shoreline#1
Shoreline#2
The second image clearly shows the alpha falling-off as the depth increases.
Another property I have managed to get working is that I encode the per-pixel terrain normal (again, convoluted) to produce a DOT3 texture with alpha (RGBA). Using this information it is possible to do all sorts of stuff like have a directional shoreline texture for shore-wash.
The first use though will be to simply fade in the standard surface textures into the shoreline to remove the hard-edge and then I will attempt to incorporate the shore-wash textures.
This method though will need multi-texturing as the alpha-map will be modulated against the surface. A single surface will need two TMU's for a single-pass. To do both surfaces four TMU's will be needed for a single-pass or two for a double-pass.
The next step for me though is to parametise the code I have got, package it up and submit it. Hopefully, this should only take a few more days.
- Melv.
I managed to get some time this weekend to go back to some previous work with the fluid rendering code.
I have been trying various techniques to get a better shoreline from the code. The way the existing fluid intersects the terrain is crude (looks like mercury in a cup someone on the forums once said) so I have attacked that problem.
What I've produced is an alpha map for the surface textures based upon height from the terrain. I found that the alpha function for shallow shorelines was completely different from the steep-shores and so I eventually came up with a nice 'sigmoid' function which allows me to control the slope with one simple parameter.
The other problem is that the terrain height-map is low-res and the waterblock mesh is dynamic according to the LOD. This leads to really coarse depth calls at undetermined locations. I got around this by simply convolving the alpha-map through a few interations. Note that the standard terrain lightmap looks much better after a similar interative convolution.
Here are some examples of the alpha-map in action. Note that I'm not texturing here as it distracts from the fade itself.
Shoreline#1
Shoreline#2
The second image clearly shows the alpha falling-off as the depth increases.
Another property I have managed to get working is that I encode the per-pixel terrain normal (again, convoluted) to produce a DOT3 texture with alpha (RGBA). Using this information it is possible to do all sorts of stuff like have a directional shoreline texture for shore-wash.
The first use though will be to simply fade in the standard surface textures into the shoreline to remove the hard-edge and then I will attempt to incorporate the shore-wash textures.
This method though will need multi-texturing as the alpha-map will be modulated against the surface. A single surface will need two TMU's for a single-pass. To do both surfaces four TMU's will be needed for a single-pass or two for a double-pass.
The next step for me though is to parametise the code I have got, package it up and submit it. Hopefully, this should only take a few more days.
- Melv.
About the author
#3
--KallDrexx
06/29/2002 (8:21 pm)
*wonders where/how melv obtained nearly godly knowledge about OpenGL...*--KallDrexx
#4
As I showed Torque lately to a friend of mine, he was like: "Yeah, looks really cool, but the shorelines are ugly!"... guess I'll send him the links to your pics, hehe... :-)
06/30/2002 (2:19 am)
Melv, that's just beautiful!! Please, please submit it ASAP!! ;-))As I showed Torque lately to a friend of mine, he was like: "Yeah, looks really cool, but the shorelines are ugly!"... guess I'll send him the links to your pics, hehe... :-)
#5
06/30/2002 (8:26 am)
Looking very cool :) Getting a smooth shoreline would make a big difference in the look of the water. I've always hated that sharp line...
#6
I've got a little more experimentation to do first then I'll work-up a CVS patch for it.
- Melv.
06/30/2002 (8:37 am)
Thanks Tim,I've got a little more experimentation to do first then I'll work-up a CVS patch for it.
- Melv.
#7
I'm finishing up for the day so I thought I would upload a few images of where I am at...
Shoreline#3
Shoreline#4
Shoreline#5
I've just about finished with my experiments so I should be able to package it up early this week.
- Melv.
06/30/2002 (11:55 am)
Ok,I'm finishing up for the day so I thought I would upload a few images of where I am at...
Shoreline#3
Shoreline#4
Shoreline#5
I've just about finished with my experiments so I should be able to package it up early this week.
- Melv.
#8
06/30/2002 (11:59 am)
Those last three are incredible Melv!!!
#9
As long as the framerate hits aren't too bad I think this would provide a huge boost to the overall look and feel of the water rendering within this engine that ALL projects wouldn't mind having.
Great work Melv!
06/30/2002 (12:06 pm)
Is there a chance that we can get this submitted into the official CVS repository?As long as the framerate hits aren't too bad I think this would provide a huge boost to the overall look and feel of the water rendering within this engine that ALL projects wouldn't mind having.
Great work Melv!
#10
Robert, there is little loss of framerate due to the way it's rendered.
At the moment there are four rendering passes taken for the fluid ... eeek!!! Also, backface culling is *not* enabled which hinders performance. The only time you wouldn't want culling on is if you had large waves where there is a potential to see the other side of the surface.
What I do is have culling on and flip the winding according to the whether you are under the fluid or not.
The current rendering is ...
Pass#1 -> Surface#1
Pass#2 -> Surface#2
Pass#3 -> Environment Map
Pass#4 -> Fog
This will now happen differently depending on how many TMU's you have on your card, basically reducing the number of passes for improved performance.
4 TMU's ...
Pass#1 -> Shoreline / Surface#1 / Surface#2 / Environment Map
Pass#2 -> Fog
2 TMU's ...
Pass#1 -> Shoreline / Surface#1
Pass#2 -> Shoreline / Surface#2
Pass#3 -> Environment Map / Fog
You could even find that the performance improves depending on the GPU you have. 8)
- Melv.
06/30/2002 (12:16 pm)
Thanks Mike/Robert.Robert, there is little loss of framerate due to the way it's rendered.
At the moment there are four rendering passes taken for the fluid ... eeek!!! Also, backface culling is *not* enabled which hinders performance. The only time you wouldn't want culling on is if you had large waves where there is a potential to see the other side of the surface.
What I do is have culling on and flip the winding according to the whether you are under the fluid or not.
The current rendering is ...
Pass#1 -> Surface#1
Pass#2 -> Surface#2
Pass#3 -> Environment Map
Pass#4 -> Fog
This will now happen differently depending on how many TMU's you have on your card, basically reducing the number of passes for improved performance.
4 TMU's ...
Pass#1 -> Shoreline / Surface#1 / Surface#2 / Environment Map
Pass#2 -> Fog
2 TMU's ...
Pass#1 -> Shoreline / Surface#1
Pass#2 -> Shoreline / Surface#2
Pass#3 -> Environment Map / Fog
You could even find that the performance improves depending on the GPU you have. 8)
- Melv.
#11
Either way it will be sometime soon. ;)
- Melv.
06/30/2002 (12:19 pm)
Forgot to mention that I will hopefully be submitting it as a CVS patch, if all goes well, later this week. Either way it will be sometime soon. ;)
- Melv.
#12
Sorry for the newbie question but I have to ask as it has been bothering me for quite some time actually.
I'm, admitably just getting my feet wet into the actual graphics part of game programming and I've been struggling with what the term "pass" actually means. :)
Color me pink and call me stupid but I just don't know what you mean by pass?
I know the basics, and I know that OpenGL is a state machine and all that good stuff. Hell, I can even render a spinning multitextured box now :p but every time I hear, "I did this in two passes" or something along those lines I really don't comprehend it.
Thanks for providing any info :)
06/30/2002 (12:31 pm)
Melv,Sorry for the newbie question but I have to ask as it has been bothering me for quite some time actually.
I'm, admitably just getting my feet wet into the actual graphics part of game programming and I've been struggling with what the term "pass" actually means. :)
Color me pink and call me stupid but I just don't know what you mean by pass?
I know the basics, and I know that OpenGL is a state machine and all that good stuff. Hell, I can even render a spinning multitextured box now :p but every time I hear, "I did this in two passes" or something along those lines I really don't comprehend it.
Thanks for providing any info :)
#13
06/30/2002 (12:48 pm)
two passes means it renders the texture two times to achieve the final effect.. (basically)
#14
Or essentially something similar?
06/30/2002 (12:56 pm)
So programmatically speaking your telling OpenGL to render a texture over the same primitive in two different spots in your code?Or essentially something similar?
#15
Sorry if you already know some of this....
Essentially what you have on modern graphics cards is a Graphics Processing Unit (GPU) which is comprised of (amongst other things) multiple Texture Mapping Units (TMU's).
Each TMU is essentially a pipeline which can read incoming pixel fragments, process them and then spit them out the other side.
It's difficult to explain the whole rendering pipeline here but essentially the TMU's don't get hold of pixel fragments until a certain amount of processing has been done on the vertices like clipping etc.
This is the crux of the matter. If you have 100,000 vertices which eventually get rasterised and end up as pixel fragments, you can do some processing on a single TMU and then send it to the screen. This would be known as a single pass.
If you wanted to use the same vertices and blend another texture on-top of the previous 100,000 vertices rendering you would set your state and render again. This would be a second pass and involves processing all the vertices again from the beginning to the end of the rendering pipeline.
If we could do multiple texturing in a single pass this would be faster right? Well that's exactly what you can do by assigning each TMU to a task you can get each to do some processing. You essentially set them up into a chain so that TMU#0 runs which feeds it's output to TMU#1 which runs which feeds it's output onto TMU#2 etc.
Different cards have different TMU counts and therefore certain cards may have the advanatge that they can do lots of work in a single pass.
If you've heard of the OpenGL extension (It's actually now part of OpenGL 1.3) 'GL_ARB_multitexture', it actually refers to the ability to give TMU's texturing tasks so that you can do multiple-texturing in a single pass.
If your card supports GL_ARB_multitexture then you must have a minimum of 2 TMU's. If you've got a geForce4 Ti4600 or a Parhelia then you've got 4 TMU's.
Hope this helps. There is much more to multi-texturing than this but I was trying to keep the post to a minimum, honest!! 8)
- Melv.
06/30/2002 (12:59 pm)
No problem Robert,Sorry if you already know some of this....
Essentially what you have on modern graphics cards is a Graphics Processing Unit (GPU) which is comprised of (amongst other things) multiple Texture Mapping Units (TMU's).
Each TMU is essentially a pipeline which can read incoming pixel fragments, process them and then spit them out the other side.
It's difficult to explain the whole rendering pipeline here but essentially the TMU's don't get hold of pixel fragments until a certain amount of processing has been done on the vertices like clipping etc.
This is the crux of the matter. If you have 100,000 vertices which eventually get rasterised and end up as pixel fragments, you can do some processing on a single TMU and then send it to the screen. This would be known as a single pass.
If you wanted to use the same vertices and blend another texture on-top of the previous 100,000 vertices rendering you would set your state and render again. This would be a second pass and involves processing all the vertices again from the beginning to the end of the rendering pipeline.
If we could do multiple texturing in a single pass this would be faster right? Well that's exactly what you can do by assigning each TMU to a task you can get each to do some processing. You essentially set them up into a chain so that TMU#0 runs which feeds it's output to TMU#1 which runs which feeds it's output onto TMU#2 etc.
Different cards have different TMU counts and therefore certain cards may have the advanatge that they can do lots of work in a single pass.
If you've heard of the OpenGL extension (It's actually now part of OpenGL 1.3) 'GL_ARB_multitexture', it actually refers to the ability to give TMU's texturing tasks so that you can do multiple-texturing in a single pass.
If your card supports GL_ARB_multitexture then you must have a minimum of 2 TMU's. If you've got a geForce4 Ti4600 or a Parhelia then you've got 4 TMU's.
Hope this helps. There is much more to multi-texturing than this but I was trying to keep the post to a minimum, honest!! 8)
- Melv.
#16
I appreciate it. Hopefully some day I can speak of such things with as much confidence as you have, let alone having the ability to code it.
06/30/2002 (1:10 pm)
Thanks for the quick reply :)I appreciate it. Hopefully some day I can speak of such things with as much confidence as you have, let alone having the ability to code it.
#17
Enjoy.
- Melv.
07/11/2002 (8:27 am)
There first version of this has now been submitted as a resource.Enjoy.
- Melv.
#18
Bah, anyway, was eager and found it :)
http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=2952
The file download link doesn't work melv!
07/11/2002 (8:39 am)
Can you post a link here melv? takes some time to approve resources...Bah, anyway, was eager and found it :)
http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=2952
The file download link doesn't work melv!
#19
I don't know why that link is not working. Perhaps it's still in the GG works......
- Melv.
07/11/2002 (9:15 am)
Xavier,I don't know why that link is not working. Perhaps it's still in the GG works......
- Melv.
Torque 3D Owner Xavier "eXoDuS" Amado
Default Studio Name
Great work melv.. hopefully we'll have nice shorelines in torque soon :)