Editing and Updating 3D Texture in Shader

YaleO'neil's icon

Hi everyone,

I have been trying to find a way to dynamically edit and update a 3D texture within a shader file. Specifically, I'm aiming to translate the 3D position data of vertices onto the coordinates (array indices) of the texture. In short, I'm looking for a computing method somewhat similar to CUDA. Here's an example/breakdown of what I'm trying to achieve:

  • Creating a particle system in 3D.

  • Generating 3D grids where the coordinates represent the 3D space.

  • Checking the position of all vertices and updating the values of the grids based on the number of vertices contained within each grid cell. So in this example, the grids would hold density data representing the concentration of particles.

  • Performing all these processes within the GPU.

I thought of using a texture to store the data of the grids, but these are the issues I’ve encountered:

  • Working in 3D poses difficulties, as jit.gl.pix/slab objects do not support 3 dimensional coordinates.

  • The texture data appears to be read-only. While each vertex can access the data a desired cell of the texture contains, it doesn’t seem to be possible to update its data dynamically.

The reason for using a 3D texture to store and retrieve density data is to efficiently facilitate further physics simulations, without resorting to looping through all vertices. While this seems to be more of a CPU type of task, I thought there should be a GPU-based solution, akin to how a fragment shader stores color data based on position during rendering.


Does anyone know a method to achieve what I'm aiming for?

TFL's icon

In the Max menu bar, check Extra > glcore Examples and especially the transform feedback ones, and [jit.gl.tf] and [jit.gl.buffer].

YaleO'neil's icon

Thanks for your response.

Maybe I was not clear, but I’m already using transform feedback, and I am aware that jit.gl.buffer has the “texbuf” attribute, allowing it to send vertices as a texture, which also gets updated during the transform feedback process.


However, what I’m trying to figure out is a way to optimize its performance further. For example, if I were to check how many vertices there are in the area of each particle’s current position, I would have to use for-loop to check the position of all the other particles. And, this process gets very heavy, when a large number of particles are used in this simulation. 


On the other hand, if it’s possible to update the value in a particular array index (or the coordinate) of the texture buffer according to its position, which I believe is similar to the rasterization & fragment shader stage, it’d be possible to access all the data in the next frame. It would dramatically reduce the amount of required operations, by using its current position to specify the coordinates of the texture to retrieve the data from, instead of checking through the entire texture data.


Obviously, the size of the texture (dimension of the grids) shouldn’t be too large, if the purpose is to optimise its performance. I have seen people using a similar technique in various simulations, but not with jitter. So, I’ve been wondering how to implement this.

Hope my question is clear now. If you still think I’ve missed something, please let me know!

Rob Ramirez's icon

Are you on Mac or Windows? If Mac there is currently no solution for arbitrary write to a texture from a shader.

If Windows, we have an undocumented, untested, and unsupported (so not guaranteed it will exist in future versions) feature for jit.gl.texture to support GLSL Image load and store functionality. Setting @image 1 on the texture will allow you to access it in your shader as an image for imageStore messages.

We have a basic example of this usage that I've attached here:

imagestore-demo.zip
zip


YaleO'neil's icon

Thanks! I'm on Mac unfortunately, but this is very good to know, and hope you can keep this feature in future versions. I saw that the computing pipeline of Metal is kind of similar to CUDA, so I hope future Mac versions will have a similar feature as well.

Rob Ramirez's icon

yep, a very interesting space we are currently exploring!