Hi there, I’m trying to create compute shader that grabs position coordinates based on a binary image. I’ve taken heavily from @DavidBraun 's particles compute for this and basically tried to simplify it for a single unmoving image. The goal is to use this to implement particle, attractor, emitter, coords for simple things like logo’s etc.
I have attached a file with 2 versions:
Version one maintains DBrauns approach with atomic counters and the random lookup, but has two problems. I can’t figure out how to get this random approach to stop cooking every frame because of the random lookup, but still look through the image randomly. If you disable the uOffset lookup parameter it does stop cooking, although It crashes TD a lot more than I’d like and i’m not sure why. The other issue with this method is that any undeclared space in the output texture of the shader creates problems. Obviously its easy to just crop that out and remap it, but i’d like to find a real solution. see attached image
The other version in the file is what DBraun called the naive approach, Where I tried using two for-loops to look through every pixel and write the ones above the threshold, but for some reason it will not gather the whole image. I figured since it only needs to run once, might not matter if it looks through each pixel?
any help or guidance mega appreciated : )
cellCoords-Compute-clean.toe (16.5 KB)
Hi, thanks for your question.
Can you clarify what’s cooking? I don’t think I see anything actively cooking in your project. However, I did notice that /project1/compute_coordinates/null1 is set to cook selectively. That was my choice. If null_random_offset is exported, then the shader will cook. In what situation does it crash? Can you figure out how to do it reliably?
About the empty space, those pixels are (0,0,0,0) so you can use any TOP method to replace them with other values, or set a different Clear Value parameter on the glsl_compute_filter. If you make the banana a little bigger with a Transform TOP then you won’t have empty space. You could also modify the shader to add 1 + any number more of randomly offset particles. This would make it look less grid-like in the end, which is probably a good thing.
I think the two for-loops would be too slow, so let me know if tips above help first.
My apologies David, I accidently disabled the "null_random_offset:uOffset " CHOP export for the uOffset parameter of the Compute Shader. When this is enabled the compute shader cooks continuously and I was wondering, since I am only planning on using it for still images, if it is possible, and advantageous, to do a random offset that ends when the compute shader has filled all its pixels?
When using the file above as an input into the new ParticlesGPU COMP I encounter a lot of crashing. I cannot recreate this on your original filter_points COMP. So obviously not a fault with ur program. And these crashes were not an issue in my project, involving an altered ParticlesGPU comp, before trying to use this technique. In testing, simply inputting my compute shader into a fresh new Particles GPU comp, emitting 5 particles every frame, crashes the system. I tried saving and attaching a file with this, but it crashed every time.
Thanks for your time.
The crash alert:
‘Vulkan Device Error’ The Vulkan Device has returned a fatal error code. This usually happens if a GPU operation runs for too long or is stuck in an infinite loop…
cellCoords-Compute-clean.toe (16.6 KB)
tested in versions
TD version 2022.24200 comercial
TD version 2022.25370 non comercial
If it’s just for still images, you can either
- replace
null_random_offset with something that isn’t cooking/changing in value.
- use the TOP->CHOP and process the data in some other way. If it doesn’t need to be fast, this could open up more creative possibilities.
I see the same crash by connecting your tox to the first input of particlesGPU.
Thanks again David.
I put in a Hash function and remapped it to the size of the total pixels to replace the random offset chop.
I managed to stop the crashing. Which I think came from disabling the random offset chop. It seems stable now.
I know there are tons of easier ways. I just wanted to understand atomic counters and compute shaders a bit more, especially iterating through a texture and outputting some of that data in a different sized texture. There are not many examples on that so thank you for sharing it.
cellCoords-Compute-share.toe (504.5 KB)
