Sorry your browser is not supported!

Does anyone know how to get shaders working correctly with advanced terrain?

The upgrade5_8.txt file says:



That statement may be true - but does anyone have a simple example of a shader that can access the textures that are already applied to an advanced terrain object?

This question has been asked before by various people but no answer seems to have been given.

I know this doesn't answer your questions directly, but maybe provide some insight on the difficulty of using Shaders on Advanced Terrain.

I've always assumed that Advanced Terrain cut a lot from the terrain object so as to cut down on the resources needed to manage it. For example (and I mean example, I don't "know"); if AT does not have normals data because the light source is calculated during creation, that could save on graphics resource use. If this is true, then I would not expect most shaders to work properly on AT, unless they were specifically desinged to work with AT.

With that in mind, perhaps the statement that "Terrain - tested shaders with terrain, not come across any problems" is technically true, but may not be practical. You might be better off creating a real-object duplicate of the terrain, shading that, and placing it over a hidden AT. A bit of a resource waste, but I think AT ground collision might be worth it.

I've tried various simple shaders which do no more than output the texture colour - almost as simple shader you can get. If you look at the UV vertex data for advanced terrain the required UV values for looking up the texture are actually there - but I can't seem to access them in the shader for some odd reason. All other objects I've tested seem OK (although I haven't tried other objects with limbs yet - that's on my list to check). What might work - and I haven't tried yet - is to use the XZ position coordinates as a surrogate for the UV value. This might work because I know the position data is correctly accessed in the shader - it's just the texture UV coords which are off for some reason.



I tried that - but it caused a 3D memory crash when I tried to apply the shader (I tried to make a duplicate object from the terrain's mesh data which might not be the best solution).

If I haven't sorted it out, I'll post a simple example of the problem later today in case someone can spot a simple solution.

[Edited XY to read XZ.]

OK, sorry about the double post, but I think it's worth highlighting this. I've got some promising news.

I've got a shader working with Advanced Terrain by getting the shader to calculate the UV coords from the XZ position coordinates as I suggested in the previous post. The problem with this is the need to take control of all the texturing and lighting in the shader so a bit more work needs to be done to blend the two texture maps. Things are looking hopeful though. Also, I'm not sure whether update terrain will interfere with the shader (I've got update terrain turned off for initial testing).

I think this is a clumsy solution - it ought to be possible to access the terrain's UV data directly within the shader, and I'm sure it can be done if someone at TGC would kindly tell us how.

Edit: got a demo working using the XZ coords. Posted on the "Learning to write shaders" thread:

http://forum.thegamecreators.com/?m=forum_view&t=91453&b=32&p=2

Shaders and Advanced Terrain - some good news.

Ok, I've bumped this to the top of the list because people are trying to get shaders working with Advanced Terrain and other objects and might not be aware of the significance of some recent bug fixes (U6.3). (Well, I wasn't anyway.)

The new flag on the "load effect" command allows the terrain's stage 0 and stage 1 UV coordinates and texture data (the main and detail textures respectively) to be accessed directly within the shader. If you want to apply a flashlight texture, lightmap or some other texture that you want to blend with the stage 0 and 1 textures, then you can apply these to stage 2. The new flag would need to be set to one as in the following example:



So the workaround I mentioned earlier is no longer needed. I'd like to thank Paul Johnson for explaining this to me.

The same flag allows you to specify your own normals via set vertexdata normals - if you don't set it the shader will use recalculated normals whenever the shader uses tangents or binormals (don't ask me why) - unless your shader code calculates them itself of course.

So good news all round.