It would be nice if we could do bitwise logical texture lookups in a fragment shader. This would be useful for terrain. Most terrain algorithms store four terrain layers in the channels of an RGBA texture, so you’re using 8 bytes per pixel. If each byte was a bitwise value, you could store 32 texture layers in an RGBA texture, instead of just 4. Each pixel would just have a “true” or “false” value for each terrain layer, but that’s a tradeoff I would be happy making given the memory savings.
//Check if texture contains flag '8':
float alpha = textureAnd(texture0,texcoords,8);
When using linear filtering, it would return a value between 0.0 and 1.0, depending on what the results from the closest pixels were. (I tried doing this in a fragment shader with my own logic but it was too slow to be practical.)
Each pixel would just have a “true” or “false” value for each terrain layer, but that’s a tradeoff I would be happy making given the memory savings.
Um… how? If you’re using these to blend between different textures to produce an appropriate color, I fail to see how a boolean value is an acceptable value for this process. Generally, people want subtle gradations between different layers, not hard on/off boundaries.
I tried doing this in a fragment shader with my own logic but it was too slow to be practical.
1: That rather depends on your hardware. And how you implemented it. Did you properly use
textureGather when doing your filtering?
2: Why do you think that a hardware implementation will be any faster? Especially since that probably no existing hardware fetching and filtering logic currently can do it. Indeed, nowadays a lot of the texture filtering logic is handled by shaders.
I would be happy making given the memory savings.
Often you cannot ask for speed and memory savings at the same time. You can already do bitwise logic in the shader and I’m with Alfonse on this, there is no guarantee that a hardware implementation will be faster.
What are you doing in your shader? Also, looking outdoors, when do you ever have up to 32 different kinds of matter in one place? And what about compressed layers? Did you check that and compare the decompression overhead to your bitwise logic? Also, what are your target plaforms? Do you have a tiling terrain algorithm or just one big chunk? Did you have a look at the assembly code generated by, at least, AMD’s and NVIDIA’s compilers?
There are a lot of places to look to and optimize before introducing a new hardware and language feature.
I’ve tried this with just linear filtering between “on” and “off” values and the results look good. The feature reminded me of Shadow2D lookups.
[quite]The feature reminded me of Shadow2D lookups.[/quote]
You mean the free 4-tap PCF?
Yes, the texture compare function is another kind of logic with linear filtering.