Is it possible to read and write (i.e. not using Sampler) to a TOP from a POP Shader? (E.g. using imageLoad/Store/AtomicAdd etc)
Hi Memo,
I donāt think this is currently directly possible. You would first need to write to a POP buffer and use a POPtoTOP to convert it to TOP. Which is super fast though since both live on the GPU.
Cheers,
tim
Hello, as Tim pointed out, it is indeed not possible at the moment, though we might add support for it in the future to avoid extra copies.
edit: also wanted to point out with the GLSL Advanced POP you can write to multiple POPs, if you need to write to buffers of different sizes, independently of the input number of points/verts/prims
oh interesting, ok thanks for the advice.
So is this the best way to do this for Particle-Cell systems? (like PIC/FLIP/Ant/Physarum etc)?
POP TOP.toe (6.0 KB)
I generalized this to 3D. I think it works (though took a while to make sure there are no off-by-one errors).
It is awesome to be able to write to arbitrary POPs from a shader, but this does feel a bit cumbersome for particle/cell interactions. Reading/writing to 2D/3D TOPs could simplify things a bit. Please do let me know if there is an easier way to do this!
POP GRID 3D.toe (6.4 KB)
(Switch the geometry viewport to wireframe, this setting doesnāt seem to be saved).
Nice examples! yeah that would be the way to do it currently.
A couple notes: so we have this concept of Dimension to help work with grids in POPs
But just realizing weāre missing a couple things in GLSL, so Iāll make a note to add that
- make the dimension info available for all inputs and not just the first one
- add helper functions that take coordinates and output 1d point index
also it seems the Dimension get lost in the feedback loop or somewhere, will look into that
Writing to 2D/3D TOPs directly you would still have to select the modified ones with a render select TOP + separate feedback, but yeah you could manipulate coordinates directly and save extra copies when you need textures for fast interpolation etc
But you would also be more limited for atomic operations (no uint32 in TOPs and float atomics are nvidia only)
Shouldnāt be too hard to add support though, so Iāll make a note
Thanks for the feedback Vincent. Yes I saw the Dimension stuff and it looks like a great idea, but I couldnāt fully get my head around it (or at least, how to use it for my purpose) :P. For one thing, the info was indeed lost somewhere along the graph, and I had to reconstruct it. That was helpful for converting to a TOP. But Iām also curious, can I use Dimensions to for example:
- read/write to a specific point in the grid from another shader without doing:
vec3 npos = pos/Dims; // normalize to [0, 1]
npos = fract(npos); // fractional part
pos = npos * Dims;
vec3 ipos = floor(npos * Dims); // integer position in pixels
uint targetId = uint((ipos.z * Dims.x * Dims.y) + (ipos.y * Dims.x) + ipos.x);
e.g.
TDDimIdFromCoords(ipos)
I believe this is the opposite of TDDimCoords
(And we would still need to convert world position to indices manually. So this would potentially replace only the last line?)
-
Easily apply / create convolution filters? Obviously TOPs already have Blur which is handy. And this is something we have to do in almost all sims to diffuse energy or material. How expensive is it to convert between POP->TOP->POP?
-
Also, I think the
TDDim*functions are only available for the first input of a Shader? In the case of this example (and I think many particle<->cell systems like FLIP, Ants, Physarum etc.) a shader is running on an unstructured particle system, and that shader wants to read/write to a structured grid. Would that shader have access to the Dims and related functions of this extra POP? E.g. Attached is a simple āTrail Diffuseā sim. Is there a better way to do this in TD with POPs (currently requires two feedbacks and POP-TOP-POP conversion, and I guess Extra POP output is also a copy)?
POP GRID 3D.103 - Trail Diffuse.toe (7.4 KB)
Thanks!
Hey Memo,
Ah it seems our messages crossed ![]()
so
- and 3. yeah I made notes to improve that.
yeah the dim info would be made available for all inputs, including extra (inputs) outputs
itās essentially a copy, so reading + writing + memory usage, so the bigger the grid the more expensive, not particularly expensive otherwise (well copy x2)
Otherwise:
Not an extra copy, or not more than any POP makes a modified copy of the input
I was thinking about that and it could be nice to have more facility to ācombineā multiple POPs (what happens in the GLSL Advanced POP) and feedback that with a single feedback, something to think about
We have it on our list to add an Attribute Blur POP, which would act similarly as the blur TOP for grid POPs (but would also blur using distance/connectivity for generic POPs)
Probably it will be cheaper to do with TOPs though since sampling texture is more optimized (free interpolation, extra cache I think etc)
So regarding your initial question, is this the best way to do this right now - I think it is with current features set, but will definitely keep that kind of setup in mind when expanding GLSL features (was just thinking we could also approach it the other way around and allow GLSL TOPs to write to POPs hehe, but prob better to focus on the GLSL POP side for now - makes me think it would be nice to have some kind of container abstraction that could combine POPs and TOPs and run compute shaders on that :D)
All in all I think your initial request might be the most straightforward to improve the setup indeed.
ah thanks for confirming! Yes I somehow missed those notes in your message! Answers everything clearly thanks. Looking forward to it!
On a note above, in the next Experimental, the Dimension in a feedback loop is preserved.
Hi @memo
So GLSL dimension helpers are more complete in latest experimental 2025.31310, see
Dimension info and helper functions
Since dimension can be more than 3, the functions return and take arrays as argument, which make them more cumbersome to use though it should be straightforward to write a little 2d or 3d wrapper.
Also TDDimPointIndex() takes integer coordinates and itās up to the user to convert from world space position (in case the grid is not at the origin)
Otherwise I revisited a bit the setup above, see attached toe with a few different approaches, I forgot to mention another way to approach it was to run a GLSL TOP and access the POP from there, which might be the most efficient. Itās in 2d to make it easier to debug/visualize and understand but easily extensible to 3d.
POPRasterTrail.toe (11.3 KB)
Cheers,
Vincent