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:
http://www.twolivesleft.com/Codea/Talk/discussion/2487/need-some-help-a-beginner-s-request#Item_8
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. 
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!
https://www.youtube.com/watch?v=qjGgmdqc1fk
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 (http://www.dgp.toronto.edu/people/stam/reality/Research/pdf/GDC03.pdf); 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 (http://hal.archives-ouvertes.fr/docs/00/59/60/50/PDF/PreprintSFFGuayColinEgli.pdf) which would be much faster but as might be expected, numerical stability is a big problem in this case.