Thanks to an urgent rush on a veg model, some tinkering and tweaking, the terrain module how has a better vegetation system which looks better, does not overhang cliffs, fits better on the ground and is faster for performance too.
Terrain Edit Cursor Highlighter
Thanks to the fact I am using a shader for my terrain, and I no longer need to save four texture stages for cascade shadow mapping, I have added three more diffuse texture options and a cursor highlighter texture as the last texture stage. Using some pokery, I am able to have the cursor render at the mouse coordinate during editing, and also reflect the radius of the brush which is now under shortcut control. It looks pretty snazzy too, as though a glowing light of creation spawns terrain from it's terrible orb of power :)
More Shader Fun
To combine the different textures coming into the terrain, I am using a control map (the veg shader map I mentioned in previous blogs) and rather that gobble up my useful channels, I can specify which of the five diffuse textures from a single Blue channel of the control map. Here some code which does it:
float texselectorV = tex2D(NormalSampler,IN.TexCoord/500.0f).b;
float texselectorcol1 = max(0,0.25f-abs(texselectorV-0.00))*4.0f;
float texselectorcol2 = max(0,0.25f-abs(texselectorV-0.25))*4.0f;
float texselectorcol3 = max(0,0.25f-abs(texselectorV-0.50))*4.0f;
float texselectorcol4 = max(0,0.25f-abs(texselectorV-0.75))*4.0f;
float texselectorcol5 = max(0,0.25f-abs(texselectorV-1.00))*4.0f;
float3 textpart1 = tex2D(DiffuseSampler1,IN.TexCoord).xyz*texselectorcol1;
float3 textpart2 = tex2D(DiffuseSampler2,IN.TexCoord).xyz*texselectorcol2;
float3 textpart3 = tex2D(DiffuseSampler3,IN.TexCoord).xyz*texselectorcol3;
float3 textpart4 = tex2D(DiffuseSampler4,IN.TexCoord).xyz*texselectorcol4;
float3 textpart5 = tex2D(DiffuseSampler5,IN.TexCoord).xyz*texselectorcol5;
finalcolor.xyz = textpart1+textpart2+textpart3+textpart4+textpart5;
Signing Off
The plan is to carry on and get the prototype so I can paint to the 'veg shader control map' by writing the texture directly from my program (performance alert) which can then reflect in the textures used by the terrain in real-time. This will lead onto being able to paint the veg color and at the same time the actual veg data which the vegetation system will use to populate the terrain. Right now the veg is being used for the entire terrain, which works fine and fast, but I dare say not everyone will want veg everywhere!
After that, I will add some quick 'randomize terrain' functionality and perhaps some 'save what I have done' code to make sure this edit can be reloaded and continued. The final step will then be to add it to the main FPSC IDE which is what I hope will occupy my Friday and have the weekend as an overflow buffer before the meeting on Monday. I still have to play S.T.A.L.K.E.R (deferred renderer) which is still in it's shrink wrap :)
Ooh that texture selector code chunk is neat! I'm going to copy and paste that for future use for my own shaders, I'm sure that will come in handy for something.
ReplyDeleteYou are dead right about the raw power of today's GPU's. I think you could hit the instruction limit for SM3.0 before actually running out of GPU power even on a modern midrange GPU!
I've been having great fun coaxing effects out of the terrain shader. My latest trick (about half an hour ago) was to use the red channel from the veg shadow map which was ONLY used to render a grass color in the distance beyond the range of the real grass. Well, I now read it into the veg shader to control whether the grass is rendered or not. Sure, the entire universe is covered in potential rolling grass, but it also means I am not storing individual grass coordinates, nor constructing the grass in a 'placed' way which means I could optimize the grass generator with some sort of procedural technique. Maybe 'procedural' for another version, but the potential is so exciting. I wonder what else I can put on the GPU :)
ReplyDeleteJust bear in mind that shaders tend to be a weak point on older GPUs performance-wise (but not so much that it's a problem normally, just don't go overboard with the shaders). Also particles. Massive overdraw totally kills older GPUs.
ReplyDeleteClearly there are always limits and though nice it would be if there were none. Sooner or later these will become apparent in Reloaded engine in real time application.
ReplyDeleteIts important not to end up with a situation again where performance for the end user game makers and game players is adversely affected due to overburden of the engine beyond limits that have such impact.
Reliable performance and stability during dev and gameplay is better than an engine or game which is not in balance and makes life miserable or impossible for both.
If Reloaded only aims for dev users and players at the higher end of the market it would be a shame and personally I doubt that would work anyway for anyone concerned but what do I know.
I have no idea what limits Reloaded will find but it already seems to me its unlikely to be capable of whats being asked for it. but then as said I know nothing of it of course. I hope to be pleasantly surprised.
At some stage it will as said become apparent.
I do hope all of the things we have seen and heard about from Lee get included and can be a benefit and not a drawback so that we can see some great games made with it sometime later.
All sounds good to me if it can be achieved.
Personally I think it would also be a great thank you for all those who have supported TGC and the products over the years and are now looking forward to Reloaded with great anticipation.
I thank Lee too for all the hard work going into these features which is very much appreciated.
:-)