YaleO'neil

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:

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

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? 

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...

editing-and-updating-3d-texture-in-shader

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

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!

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 

 on the texture will allow you to access it in your shader as an image for 

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

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.

yep, a very interesting space we are currently exploring!

Editing and Updating 3D Texture in Shader