Jump to content
  • Advertisement
Sign in to follow this  
JamesLewis

Texturing a terrain using effect (.fx) files

This topic is 4071 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a terrain editor that allows me to add different texture layers in the following format: Base Layers - a single texture stretched over the entire terrain. Alpha Layers - texture applied using an alpha map. Blend layers - texture applied using an alpha map and various blend techniques. Detail Layers - texture applied over entire terrain using blend techinique. What I need to do is write an effect file that will allow me to apply an unspecified number of these layers to a terrain. For example, I could just have one base layer, or I could have multiple alpha layers and a base layer etc etc. I have very limited knowledge of HLSL and am wondering how difficult this is going to be. Also, if anyone can point me in the right direction / give me a psuedo code layout of such an effect file, that would be much appreciated. Thanks, James

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by JamesLewis
What I need to do is write an effect file that will allow me to apply an unspecified number of these layers to a terrain. For example, I could just have one base layer, or I could have multiple alpha layers and a base layer etc etc.


If that's your goal, I wouldn't write an fx shader - I'd write a tool that makes fx shaders procedurally, given a set of inputs. What you describe is only difficult because of the permutation problem. Writing an FX file to handle that kind of flexibility would be annoying - and non-efficient. I'd go the tool-route.

ryan

Share this post


Link to post
Share on other sites
Keep in mind that the effect system is really just a glorified state manager, where each pass is a collection of states you want applied, and a technique is a collection of passes.

What you can do is have one pass for each layer type. This doesn't necessarily mean you apply each pass once and in order from 0 to N, but just that you have a unique set of states for each layer type. Then you can apply the passes in any order (which really just applies the states), any number of times, to render all the layers. Some psuedo-code might look like:
int nPasses;
terrainTechnique->Begin(&nPasses,0);

for(int i = 0; i < numBaseLayers; ++i)
{
terrainTechnique->BeginPass(0);
RenderTerrain(0,i);
terrainTechnique->EndPass();
}

for(int i = 0; i < numAlphaLayers; ++i)
{
terrainTechnique->BeginPass(1);
RenderTerrain(1,i);
terrainTechnique->EndPass();
}

for(int i = 0; i < numBlendLayers; ++i)
{
terrainTechnique->BeginPass(2);
RenderTerrain(2,i);
terrainTechnique->EndPass();
}

for(int i = 0; i < numDetailLayers; ++i)
{
terrainTechnique->BeginPass(3);
RenderTerrain(3,i);
terrainTechnique->EndPass();
}

terrainTechnique->End()

Share this post


Link to post
Share on other sites
Quote:
Original post by Zipster
What you can do is have one pass for each layer type.


Hrm. Sounds a bit fixed-function to me ;)
I'd much rather have a single HLSL file that composited n textures than submit my geom n times. Maybe that's just me.

Share this post


Link to post
Share on other sites
Quote:
Original post by vfetch
Hrm. Sounds a bit fixed-function to me ;)
I'd much rather have a single HLSL file that composited n textures than submit my geom n times. Maybe that's just me.

You don't submit all your geometry each pass, you only submit the part of the geometry that is covered by each texture. It's also a lot harder than you think doing multiple blend layers at once in a single pass. You have to manually expand all the alpha blending math so that it's the same had you rendered each layer at once, and you might as well forget fogging. Our lead graphics programmer managed to get two layers working at once in DX9, but the performance was actually worse than one layer at a time - we have no idea why, but we imagine it's because the pixel shader was so long what with all the lighting, bump-mapping, shadow-mapping, etc. I can't even imagine what kind if voodoo you'd have to pull to get more than two layers blending at once with better performance on PS 2.0 hardware :) Maybe it's more feasible on DX10 since you can just bind all the textures at once and just average!

Share this post


Link to post
Share on other sites
Quote:
What you describe is only difficult because of the permutation problem.
I completely agree. Run a few searches on "combinatorial explosion" and similar terms - results might not be in terms of terrain rendering, but this is a general problem that a lot of developers are having to tackle these days.

Using semantics and lots of techniques can solve a lot of the problems. Simple things like this:

VS_OUTPUT pixel_shader( uniform int layers )
{
if( 0 >= layers )
// Include base-layer
if( 1 >= layers )
// Include first alpha layer
if( 2 >= layers )
// Include second alpha layer

/* etc... */
}


the key point is the uniform qualifier - it allows for compile time dead-code elimination and removal of the branching operations. Basically you're writing one set of code that will be compiled differently according to the parameters provided via the technique.

Each technique could be:

technique my_tech_a
<
int layers = 0;
>
{
pass
{
// stuff
PixelShader = compile ps_2_0 pixel_shader( 0 );
}
}

technique my_tech_b
<
int layers = 2;
>
{
pass
{
// stuff
PixelShader = compile ps_2_0 pixel_shader( 2 );
}
}


You can then, via the effects framework, enumerate each technique and examine its 'layers' semantic and hook that up against any tool-generated data and then store the handle against whatever internal structures you're using.

The net result is that almost all the work is done at compile-time or load-time [grin]

hth
Jack

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!