indexed splatting

This is sure a frustrating topic. Using fixed-sized textures even starts to look good.

However I have another working idea I would like to throw out for comment: changing the sampler state in a fragment program.

With code like:
float4 color = tex2D(state, coord);

one can in effect select the texture associated with state. I started looking into this in an attempt to perform dynamic array access of a state array. While state arrays are allowed, they need to be resolvable at compile time, so cannot be used for lookups. However changing these sampler states via if-then tests could still be performed.

With a binary search, the swap should be log(n) in time, and I think better performing than multiple passes.

I need to leave for an appointment in 15min, so I don't have time to think this through completely. But feedback would be appreciated.

How many splats do you want?

You can actually do as many as 7 splats in one pass assuming you have 8 texture units and don't need any other textures (lightmap, normal map, etc.)

How many splats do you want?

The more you have the better the terrain looks, right? Unless you're playing on a golf course or something, and only need a few.

KungFooMasta

I really don't have a specific number in mind, rather I am trying to open up some options for offline texture generation. I would like to see what 256 textures per page would work like.

Then there is a saying I tend to live my life by: If a little is good, a lot is a lot better!

But my concern now is to see if there are any obvious downsides that I am missing.

A related question is: how many passes can one reasonable do without hurting performance too much. A rather subjective question, I realize. But one I'd like to know more about. I can experiment with my 7800gt, but that is only one (perhaps non-representative) data point.

But my concern now is to see if there are any obvious downsides that I am missing.


Memory consumption might be a concern. 256 textures at 256x256 resolution is about a 128mbs of textures compressed using DXT1. Not even sure you can compress 3d textures though. If not it'd be about 1gb of memory You could probably get away with smaller sized textures though.

I am anticipating newer generations of cards will have even more texture memory. That 1G probably won't be an issue in 3 years.

I have 256K on my 7800GT, which can hold a lot. And I can use very tiny textures to test the limits.