negative numbers in a texture for use in a fragment shader

I’m trying to do some computation in a fragment shader and have a texture holding input variables. Some of these numbers need to be negative. Can the texture format support negative numbers or do I have do convert a value in the range 0.0 -1.0 into e.g a value from -1.0 to +1.0?

It only works if the texture size is a power of 2 (for example 256x256). But you can solve that by using mod() see this post:

No, a texture can’t hold negative values so you have to rescale.

Actually you can, but only if the texture size is of base 2. Try -ElapsedTime in the first example in the thread above. Unless Codea fixes it somehow in the runtime.

@tnlogy I think we’re talking about different things here. I understood the question to be about the values stored in a texture, meaning the RGBA values of the colours. These are constrained to be between 0 and 1. You’re talking about the texture coordinates which are the lookup values. My reading of @bm212’s post was the former, based on the phrase “texture holding input variables”, but I may be wrong.

Ah, you are correct. I blame it on my cold. :slight_smile:

I was considering including support for this in Codea, however only iPad 3rd gen and above support floating point textures (as in each texture element is a 32bit floating point value), however the performance on these textures is pretty terrible and I didn’t want to fragment feature support across iPads in this way.

hi, sorry haven’t been looking at the forums recently. @Andrew_Stacey, your interpretation of my question is correct, I wanted to store negative numbers in the RGBA values of a texture. The reason was that I’m writing a GPU fluid dynamics simulation and want to store a velocity field In a texture. I’ve had to rescale each value from 0-1 to -1-1 which is a bit irritating but easy enough to do. @John, floating point textures would be awesome for this application but I think you made the right decision in not supporting them.

@bm212 A-ha! Snap!

I had a go at a full Navier-Stokes implementation but eventually came to the conclusion that Codea couldn’t handle the number of iterations required to solve the PDE. It may be that there’s a quicker way to do it. So the above was with a “steady state” fluid described by a holomorphic function (incompressible, irrotational flow). I’d be very interested in seeing what you have.

I have a fairly substandard implementation after Stam (; I changed his implementation to explicitly diffuse the solute and ignore viscous diffusion of velocity, and it still only managed 25fps on a 64x64 grid. There’s definitely scope for optimisation though. I’ve also started experimenting with a fully explicit scheme ( which would be much faster but as might be expected, numerical stability is a big problem in this case.