1d float texture for a shader

I have an idea for a shader that needs a bunch of float values per vertex, and I’d like to be able to change these values on the fly.

I’ve had an older system that adjusts vertex information every frame, but that tends to be really slow when there are allot of vertexes.

Another way to use this information seems to be a texture lookup in the vertex shader. For each vertex, there is a pixel of information in the texture. This way, instead of uploading a new geom every frame, all I have to do is change the texture.

So I create a ram image of a 1d texture using the following code:


self.positionTimeRamImage = self.positionTimeTexure.modifyRamImage()
numComp = self.positionTimeTexure.getNumComponents()

then use setElement to set each a position value into the rgb and a time value into the alpha.

for texelIndex in range( particleCount ):

		texelIndex + 1,
		texelIndex + 2,
		texelIndex + 3,

Then in the vertex shader I get that information with:

tex1D( k_positionPosTime, vertexIndex / numberOfVertexs );

So what I’ve found is that the texture lookup is always transparent black, or 0.0, 0.0, 0.0, 0.0.

Am I creating the texture wrong? Is there a better way to create a float texture like this?


I’m not sure that float textures are implemented.

I’d be somewhat surprised if uploading a texture and uploading a geom had different throughputs.

Well… theres quite a bit of somewhat static information that is also in the geom and if this works, I wasn’t planning on having a one vertex to one pixel ratio.

This all would lead to a significantly smaller texture upload than reuploading a bunch of data that I don’t updated. The significant slowdown I would see is in translating the ramImage into a texture.

I guess I’ll look into the implementation of the float texture.

Thanks for the response.


Wait, before you go any further…

You say that there’s a lot of static info in the geom. But this is actually the common case - when animating a character model, it’s the vertex positions and vertex normals that are changing. The texture coordinates and vertex colors are not. So maybe David has already optimized for this case? I wouldn’t be surprised, he’s good about that sort of thing.

If your data consists of some static columns and some animated columns, you may build a GeomVertexFormat with the animated columns in a separate array from the static columns, and that data will be uploaded separately, at least on OpenGL.