   Pixelshading for terrain-texturing?
  Just an idea:You have about 8 different base textures (gras, rock, sand etc.).For each of these groundtypes you have a greyscale distribution map.Then the pixelshader mixes all ground types depending on the strength of their distributionmap at every pixel.So you have something like multitexturing with an infinite ammount of textures AND a distributionmap for each of them.What do you think? Could that work? Or is it already an old idea? 
  Yes, that will work......but only if you have graphics hardware that supports 8 simultaneous texture maps.Typically the "greyscale distribution map" is put into the alpha channel of some of the maps.It''s actually quite a common technique. It doesn''t require pixel shaders either. The non-programmable/fixed function Direct3D and OpenGL multi-texturing pipelines support that easily too.The main problem is finding graphics cards that support all 8 textures in one go. Many chips from as recently as say 2 years ago still only support 2 simultaneous textures.Getting round those hardware limitations is where things like multi pass come in and where clever techniques get invented (i.e. separates the men from the boys).   --Simon O''Connorex  -Creative AsylumProgrammer &Microsoft MVP;  But how can the distribution map be put in the a-channels? These textures will be tiled, so that would look strange...Or I got you wrong ;-)And one advantage of the shader approach is that you can add other effects like reflecting ice, bumpmaps or other stuff...Right?   ;  I''ve got an another idea for you Kurt. You could put the 8 different textures as different layers of a 3D texture and blend between them with the third texture coordinate (which could come form the vertex, or a second texture)..Obviously you can only blend to neighbouring layers, but I think it would be a good way to do it.. (although I don''t think pre-gf3 nvidia cards support 3d-textures if i''m not mistaken.) I haven''t tried it though. It''s just one of many algos floating around in my head.. =) ;  The image that gave me this idea is this one (from tribes3):The grass texture on the ground is VERY detailled, although the landscape is really big...And that isn''t possible with the common detailmap. ;quote:The grass texture on the ground is VERY detailled, although the landscape is really big...And that isn''t possible with the common detailmap. To get that effect, you blend between two equal textures per layer: one at a low tiling, the other at high tiling. The blending should be distance dependent. The texture content is the same (it''s actually the same texture data, bound to multiple units). You''ll probably need several passes, if you want multiple layers at the same time, especially on older hardware. Besides that, I''m going to re-post those two (pretty old) pics, because they use exactly the method you outlined. No pixelshaders involved (those were taken on a 3Dfx Voodoo, years ago), just simple multi-layer texturing. The distribution data is supplied per vertex.Terrain 1Terrain 2;  those pics look good :-)I guess I''ll implant my idea as I''ve got some time... ;-) ;  Wurks!!I''ve put together a little demo using this technique (with only 5 textures), but the framerate is HORRIBLE!!!I didn''t knew that pixelshaders are that slow ;-)Maybe it would be better to do that on an per-vertex (not per-pixel) basis...But how would that work?? ;  I''ve made up my mind and now I know how I want it to be:In a distributionmap a value for every vertex of the landscape is stored. This value indicates what texture type this vertex has (0=Grass, 1=Sand etc.).One way of realizing this would be multi-pass-rendering. One layer for each texture-type, and different vertex-alphas. Pretty easy but way too slow...Are there other alternatives on this per-vertex basis (maybe via using shaders)?Doing it per-pixel is easy but as mentioned above too slow either.thx ;quote:Original post by VanKurt  Are there other alternatives on this per-vertex basis (maybe via using shaders)?You can use a multipass approach, by using all texture units available. That will definitely speed it up. You supply the individual blend weights (those that were originally in the vertex alpha) encoded as colour components. You need to decode them perpixel, so the packing should be efficient for your target hardware. If you use real pixelshaders, you can pack each layer''s alpha into a separate colour component (all examples assuming OpenGL):primary_colour.r = alpha_layer1primary_colour.g = alpha_layer2primary_colour.b = alpha_layer3primary_colour.a = alpha_layer4...etc...In your pixel shader, you''ll need to read out the individual components, and use them as (additive) wieghts between your terrain texture layers.If you don''t have DX9 type hardware, you can use a slightly different encoding:primary_colour.rgb = alpha_layer1primary_colour.a = alpha_layer2secondary_colour.rgb = alpha_layer3implicit layer 4 = 1 - (alpha_layer1 + alpha_layer2 + alpha_layer3)Gives you 4 weights, that can be used on 4 texture units. This is very easy to implement on Nvidia''s register combiners, for example.