Underwater Terrain Shading
by Jacob Dankovchik · in Torque Game Engine Advanced · 02/17/2007 (11:01 pm) · 54 replies
This is the shader code for the stuff posted in the topic here: www.garagegames.com/mg/forums/result.thread.php?qt=39336
There are a few things I need to mention though. Unfortunately, I can't get it to work with Atlas2. I've not the time to learn the ins and outs of Atlas2 to get this working smoothly, so I'll just post the code here that I used in the past and let someone who knows the Atlas code better try to work it in. If someone out there does get it working, at least please post the solution... Otherwise I'd rather not you use it at all if you don't share your help.
Anyhow, the way this was setup to work was as a second pass called through the Atlas material with a multiply blend function. It would work out the shade value for the terrain underwater and just times that by the actual color.
It starts with a small engine change. I know this could probably be done better. And i've no clue the effect multiple waterblocks has. But this is to get the waterblock's size and position into the shader so we can check if the pixel is underwater. This goes in waterblock.cpp, in setShaderParams:
The shader requires 2.0, so assemble any material def's with it with that in mind.
And now the shaders itself. These aren't modified or cleaned up, this is just the stuff I used that works. No big deal to clean it up anyhow really. You get the idea.
There are a few things I need to mention though. Unfortunately, I can't get it to work with Atlas2. I've not the time to learn the ins and outs of Atlas2 to get this working smoothly, so I'll just post the code here that I used in the past and let someone who knows the Atlas code better try to work it in. If someone out there does get it working, at least please post the solution... Otherwise I'd rather not you use it at all if you don't share your help.
Anyhow, the way this was setup to work was as a second pass called through the Atlas material with a multiply blend function. It would work out the shade value for the terrain underwater and just times that by the actual color.
It starts with a small engine change. I know this could probably be done better. And i've no clue the effect multiple waterblocks has. But this is to get the waterblock's size and position into the shader so we can check if the pixel is underwater. This goes in waterblock.cpp, in setShaderParams:
reg[0] = mObjScale.x; reg[1] = mObjScale.y; reg[2] = mObjScale.z; GFX->setPixelShaderConstF( 9, (float*)reg, 1 ); Point3F pos = this->getPosition(); reg[0] = pos.x; reg[1] = pos.y; reg[2] = pos.z; GFX->setPixelShaderConstF( 11, (float*)reg, 1 ); reg[0] = mBaseColor.red;///mBaseColor.alpha ; reg[1] = mBaseColor.green;///mBaseColor.alpha; reg[2] = mBaseColor.blue;///mBaseColor.alpha; reg[3] = mBaseColor.alpha; GFX->setPixelShaderConstF( 17, (float*)reg, 1 );
The shader requires 2.0, so assemble any material def's with it with that in mind.
And now the shaders itself. These aren't modified or cleaned up, this is just the stuff I used that works. No big deal to clean it up anyhow really. You get the idea.
#42
img512.imageshack.us/img512/7493/water1ta4.jpg
img516.imageshack.us/img516/1985/water2rc5.jpg
By the way, the fully white terrain only exists for demonstration purposes. Just so nobody asks, and everybody understands, these pics here are showing that the water is now once again in full working order for Atlas. I'm going to tweak the code up and clean things and should have a fixed release out in no time.
And no, military hasn't been workin me too hard. ;) I'm done with the first half of my schooling and now I get to spend a couple months waiting to begin the second half, during which I do insane amounts of pointless busy work. I work way harder and have way less time then before, but I'm not using my mind at all. So I basically have more energy to work on other things, which is why I finally found the time to fix this.
And to think.. Last night was the first time I thought to try to fix this since I made this thread... And in about 1 hour total of work, I found the solution. Amazing what you can do with mental rest.
06/09/2007 (1:09 pm)
Hows this?img512.imageshack.us/img512/7493/water1ta4.jpg
img516.imageshack.us/img516/1985/water2rc5.jpg
By the way, the fully white terrain only exists for demonstration purposes. Just so nobody asks, and everybody understands, these pics here are showing that the water is now once again in full working order for Atlas. I'm going to tweak the code up and clean things and should have a fixed release out in no time.
And no, military hasn't been workin me too hard. ;) I'm done with the first half of my schooling and now I get to spend a couple months waiting to begin the second half, during which I do insane amounts of pointless busy work. I work way harder and have way less time then before, but I'm not using my mind at all. So I basically have more energy to work on other things, which is why I finally found the time to fix this.
And to think.. Last night was the first time I thought to try to fix this since I made this thread... And in about 1 hour total of work, I found the solution. Amazing what you can do with mental rest.
#43
06/09/2007 (1:48 pm)
It's really awesome. Can't wait for it to be fixed! 
#45
the only issue that atlas has is the Statis Shadows issue.
06/09/2007 (4:00 pm)
@Mark I have been using L3DT and have had not one issue with Atlas2the only issue that atlas has is the Statis Shadows issue.
#46
And interestingly, halfDepth can be changed in realtime. Basically, this entire shading addition is proving to be fully realtime, no need for restarts or reloads, nothing. It positions in realtime, colors in realtime, its good stuff. :D
Here is an example, using some color to dirty the water up. Of cource, this is totally untweaked. You would have to adjust this for a while to get it right before you would use it. The bottom line though is you now have full, realistic control over your water. Control over light absorption of your liquid, and the color of the liquid itself, either naturally or by impurities.
06/09/2007 (7:04 pm)
I'm getting this to come together very well indeed. Finally decided to do the simple task of integrating baseColor with halfDepth. I mean, afterall, muddy or algae filled water carries a color with it, as well as normal absorption. And interestingly, halfDepth can be changed in realtime. Basically, this entire shading addition is proving to be fully realtime, no need for restarts or reloads, nothing. It positions in realtime, colors in realtime, its good stuff. :D
Here is an example, using some color to dirty the water up. Of cource, this is totally untweaked. You would have to adjust this for a while to get it right before you would use it. The bottom line though is you now have full, realistic control over your water. Control over light absorption of your liquid, and the color of the liquid itself, either naturally or by impurities.
#47
Great job either way. Keep up the good work :)
06/09/2007 (7:44 pm)
Sexy stuff, if i understood the shader pipeline better I would port it to the legacy and atlas2 meself, but I'm useless when it comes to how the shader system works (it lost me so many moons ago). Any plans to port this to to the newer... things? OR better yet is there anyplace that I have been too blind to notice where I can read how the system works so i don't have to waste your time :PGreat job either way. Keep up the good work :)
#48
Easy thing to do, run in windows mode, open up a text editor with the vertex and pixel shader for the shader you want to work with. Start with something small like adding this to the second to last line of your pixel shader, right above the return OUT;
That would make everything drawn with that shader be blue. But to make it work in realtime you'll have to call ReloadMaterials(); through the console (alt-tilde). Map that to a key, edit your files with an editor and just reload them and you can see the results in game pretty quickly. Or use a program like rendermonkey and just convert over what needs converting later. There's a decent article here someplace that gives an example from rendermonkey to TGEA.
This of course is assuming your modifying a shader that is attached to a texture. To attach it to a texture you'll have to edit the materials.cs definition, which is documented on TDN. But basically for a really simple example if you have a DTS shape with the texture "mytexture" on it that you are using for your text object and you want to use a customshader that you called "myshader" then here's the setup for that:
In client/scripts/shaders.cs...
In the dts files directory where the mytexture.jpg or whatnot resides add a materials.cs that looks like this...
So now you need to add a MyShaderV.hlsl and MyShaderP.hlsl to your shaders/ directory so that they can be compiled when it compiles the shaders. You can use any of the existing ones as a base, just make copies as the new names, and then add something like the OUT.col.b = 1.0 or whatnot just to make sure it works the first time before you start modding away further.
06/09/2007 (8:05 pm)
What is giving you problems with the Shader Pipeline? Of all of the ones I've worked with it seems to be the cleanest and easiest to use out there. I design in rendermonkey and it usually takes very little time to then port that to TGEA. For smaller shaders I just do it with a text editor and manually reloading the materials from the console to get realtime editing. It's very easy to work with once you get past the initial hump of understanding the shaders. Easy thing to do, run in windows mode, open up a text editor with the vertex and pixel shader for the shader you want to work with. Start with something small like adding this to the second to last line of your pixel shader, right above the return OUT;
OUT.col.b = 1.0;
That would make everything drawn with that shader be blue. But to make it work in realtime you'll have to call ReloadMaterials(); through the console (alt-tilde). Map that to a key, edit your files with an editor and just reload them and you can see the results in game pretty quickly. Or use a program like rendermonkey and just convert over what needs converting later. There's a decent article here someplace that gives an example from rendermonkey to TGEA.
This of course is assuming your modifying a shader that is attached to a texture. To attach it to a texture you'll have to edit the materials.cs definition, which is documented on TDN. But basically for a really simple example if you have a DTS shape with the texture "mytexture" on it that you are using for your text object and you want to use a customshader that you called "myshader" then here's the setup for that:
In client/scripts/shaders.cs...
new ShaderData( MyShader )
{
DXVertexShaderFile = "shaders/myshaderV.hlsl";
DXPixelShaderFile = "shaders/myshaderP.hlsl";
pixVersion = 1.1; // or whatever pixel shader version this is
};In the dts files directory where the mytexture.jpg or whatnot resides add a materials.cs that looks like this...
new CustomMaterial(MyShaderMat)
{
mapTo = myshader; // this is the texture name that we are mapping this shader to
version = 1.1; // shader version
shader = MyShader; // our shader name name
texture[0] = "mytexture"; // texture
};So now you need to add a MyShaderV.hlsl and MyShaderP.hlsl to your shaders/ directory so that they can be compiled when it compiles the shaders. You can use any of the existing ones as a base, just make copies as the new names, and then add something like the OUT.col.b = 1.0 or whatnot just to make sure it works the first time before you start modding away further.
#49
I hope that this helpsClick here
06/09/2007 (8:41 pm)
Above someone requested information on the clipmap.I hope that this helpsClick here
#50
I'm not sure I understand. Those pictures I've been posted are all taken on Atlas2. It's all fully functioning, I'm now just adding extra bells and whistles. Its built to run on Atlas2, which is as new as Torque gets with terrain. ;)
06/10/2007 (1:54 am)
Quote:Any plans to port this to to the newer... things?
I'm not sure I understand. Those pictures I've been posted are all taken on Atlas2. It's all fully functioning, I'm now just adding extra bells and whistles. Its built to run on Atlas2, which is as new as Torque gets with terrain. ;)
#51
www.garagegames.com/mg/forums/result.thread.php?qt=63193
06/10/2007 (10:34 am)
Jacob wondering if I could pic your brain on this.www.garagegames.com/mg/forums/result.thread.php?qt=63193
#52
06/10/2007 (6:38 pm)
Jacob, I'm extremely interest in this. Let me know when you're ready to release the source. 
#53
01/01/2008 (12:13 pm)
Its been quite a few months. havnt really heard of any new updates on this post. has the resources been posted. I'm talking about the code that works with Atlas2? 
#54
I could be wrong though.
01/01/2008 (12:34 pm)
I don't think Jacob is actively working on TGEA shaders anymore. (See the lower parts of that thread)I could be wrong though.
Torque 3D Owner Marc 'Dreamora' Schaerer
Gayasoft
On the other hand, legacy in theory isn't great, but in praxis it works and does what it is meant and advertised to do unlike atlas and that without "retry loops" to get the stuff correctly into the engine.
right now I use legacy for creating stuff due to that (but that does not mean that I do not have heightmaps of my work etc to create atlas out of it when it works and features all the stuff it is meant to do as TGEA terrain)