Jump to content

View more

Image of the Day

Boxes as reward for our ranking mode. ヾ(☆▽☆)
#indiedev #gamedev #gameart #screenshotsaturday https://t.co/ALF1InmM7K
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

Terrain Multitexturing with Alpha Blend Masks

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
1 reply to this topic

#1 Naros   Members   


Posted 04 February 2014 - 10:55 PM

We have split our terrain out into logical sectors or pages that allow us to stream in portions of the terrain based on the camera's location.  Each sector of terrain is further subdivided into 256 cells in a 16x16 format.  Each of these cells consist of up to 4 color textures, generally 256x256 and an alpha blend map for each color layer past the first layer along with a light map.  


Rendering each of the smaller cells independently is quite easy by simply passing the color textures along with a RGB texture that combines the maximum of 3 alpha blend textures into a single texture and I do the shading inside a pixel shader.  While this works quite well, it is far from efficient mainly because this pushes the batch count extremely high since I am rendering on a small cell by cell basis and since that no material is shared between any of the cells due to their varying alpha blend map texture.


I did consider the idea of using a quad-tree structure based on texture counts to split the terrain sectors into quads that contained at minimum 1 cells but more like 8x8 patches of cells, dynamically generate a material that referenced the textures used by the given set of cells and then generate a dynamic runtime texture by combining the alpha blend maps for those cells into one larger texture.  In the case where a terrain sector was within limits and thus the entire sector was 1 leaf node, the alpha texture is only 1024x1024 but generally I would expect it to be 512x512 or smaller in more detailed texture-varying areas.


The problem with this approach is I am not sure how to control which 4 textures to sample and blend in my shader.  As a simple example, my algorithm determines that a 2x2 set of grid cells are within the texture limits to be combined into a single material.  So I bind lets say 8 textures and my blend texture.  The top left cell might need to sample textures 1, 3, 5, and 8 while the top right cell might need to sample textures 2, 5, 6, and 7.  Both cases, the same alpha texture is sampled and the where the red channel controls the blend weight for texture 1 in the top left grid while it controls the blend weight for texture 2 in the top right.


Is this even possible and if so, anyone have any examples or suggestions on how I could leverage this?  Or is there a cleaner while efficient way to do this without overly complicating the shader's logic?

Edited by crancran, 04 February 2014 - 10:57 PM.

#2 MaxDZ8   Members   


Posted 06 February 2014 - 02:23 AM

I did something similar years ago on much more restricted hardware and I had to go with sampling N textures. What I did at the time was exploiting the fact data was static, so I could categorize all the tiles in advance. Frostbite used a similar categorization in the past - I'm not sure it still does.


If the blending are to be controlled per-pixel with arbitrary combinations, I'm afraid only contribution masks will do, as I did at the time. Nowadays, I'd use a distance map. With highly coherent access of 512x512 textures it might still be affordable to sample them all. There's a DICE presentation showing a method based on successive applications of masks but I cannot find it right away.

I'm sure you could pull up textures dynamically on shader profile 4 HW using texture arrays, if you can drop support for SM3 and earlier, you're basically going to have no problem at all.

Previously "Krohm"

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.