Texture Precision

Scripting Issues
#1

Hi all,

I’m trying to create a dynamically generated Heightmap.
My values range from 0 to ~8000 (generated from shaders), which forces me to scale them to the range 0-1 in order to store them in a texture (just by dividing it by my max value).

My issue is that I can’t find how to have the correct precision for this :
When using a DepthComponent texture to store the results, the heightmap seems fine :

http://postimage.org/image/vcd0ezwbx/full/

but when using a regular one (Luminance or even RgbXX), I get this result :

http://postimage.org/image/r7dmx4us7/full/

I think the “lines” that are visible come from a precision issue.

my result texture is initialized with the following code :

tex = Texture()
tex.setup2dTexture(512, 512, Texture.TUnsignedShort, Texture.FDepthComponent) //(first image)

and 

tex.setup2dTexture(512, 512, Texture.TUnsignedShort, Texture.FLuminance) //(second image)

I tried replacing TUnsignedShort with TFloat, and FLuminance with FRgbXXX with no effect. The only difference between those two pictures is the component type during init.
I can’t just use the depth buffer to store my heightmap because I actually need it to do some tests for flattening some areas (buildings, roads…).

Am I missing something during the texture initialization, or even after that, maybe during my scaling ?

Chooosing precision/representation in auxiliary buffers
#2

So you mean you are rendering these textures to an offscreen buffer in a shader? Hmm, I’m not 100% sure we support 16-bit render-to-texture at this point. There might be a need for some more fiddling in the texture buffer setup code.

David

#3

I’m not sure either. zhao has been working on floating-point texture support in the trunk, so you might want to try the devel builds.

Anyway, if all else fails, you could use a regular RGBA texture and separate the values to different channels (eg most significant bits in red, least significant bits in alpha or so), and put them together again when sampling the texture.

#4

Exactly; The goal is to have a procedural terrain almost entirely generated on the GPU, mostly via the FilterManager. The entire process works quite well, and this would be the finishing touch.

I’ve indeed read Zhao’s post, I’ll try his changes as soon as I can. Is there a list of the changes linked to this ? Zhao’s post mentioned it, but it was hosted on Megaupload :stuck_out_tongue:

Right now, I’m doing pretty much what you describe here rdb, i.e splitting the value into some modulus 256 and use different channels in the texture to store it, but that makes linear interpolation impossible each time the heightmap comes close to a “256-modulish” value (a huge peak appears due to that interpolation).

Thanks for the quick replies !