Looking for something that probably doesn’t exist as usual.
Is there any way to trigger some effect when a material function value reaches a goal without having to replicate that value calculation in CPU?
Basically I need to look for a single pixel changing in a 4k image. If I were to pass that kinda of data off to the CPU for checking purposes it would probably grind the engine to a halt… Since the GPU already knows the value is 0, I’m hoping there’s already some way (niagara?) to have it toggle a particle effect or similar…
I suppose if this was a thing, even water could actually be queried for current wave position without replicating the code, so let’s go with a no then…
Not sure, if it´s possible to look for a specific pixel (especially because you wrote material function value, and not texture), but you can sample textures and use them as input for particles.
Here is an article about how to use flowmaps for Niagara particles, there that texture sampling happens too. Maybe that gives you a starting idea, because at first glance, this texture sampling seems to be useable for many things.
Maybe you can force/alter it to just look at your specific UV coords, where your desired pixel is located.
It’s too much data to process either way, 4k texture is 4096^2 rows of data.
Running it at 1 pixel per frame assuming 60FPS means 4096/60 seconds: around a minute per texture row.
I’m just going around it entirely by making an accumulating brush that paints the whole texture over time for this specific use-case.
And I’m going to get niagara to read this texture in order to pick the particle spawning point based on UV location.
The only other way I can think of that would allow running loops of 4096 items without grinding to a halt is a dedicated thread. And it’s not that I won’t do that too in a minute, it’s that I think it’s still going to be a massive drag on an already bad performing engine to actually do with with multiple assets at the same time
Changing a single texture overall is probably much faster for all aspects.
Ps:
Would still love it if they actually made some sort of an interface call possibele from the material computation. Don’t really know what would be involved in getting an event to fire out of a calculation result on the GPU, but it shouldn’t be impossible…
What exactly do you want to do or achive? Do you “just” want trigger a particle effect if one specific particle in the whole 4k texture goes above a certain value, or do you want check every pixel and trigger this effect in every pixel, that reaches this value?
Just wondering because yeah, one pixel per frame take ages, but if the tutorials usually process 1k textures in one loop then you probably can speed it up. The flowmaps from the tutorial f.e. is a 1024 texture, and the Niagara emitter is indeed able to spawn one particle for each pixel ( = 1.048.576 particles ) per second. 5 million particles after 5 seconds.
So if it happens, that a 1k is the limit, then you can get your effect in 16 seconds. Sounds somewhat better than a minute per row ^.^ What the real limit is, you would have to test that on your system
More than that on the end system. The development machine probabpy has no limit compared to a switch for instance.
Yea. The idea is to spawn at multiple spots depending on the pixel value.
It should work even on 4k textures with Niagara, its just deferred so it may have to wait a second and talk back to the material to activate a opacity trigger or update the texture again post execution.
That or, ofc, limit the systen to 1k or 2k textures. Im just buinding the system with the future in mind, so 4k seems like a good place to be.
In reality im only using 8 pixels in testing, so it doesnt quite matter
Still, having a way from whitin the material editor to generate a call and pass a variable would be a stratospheric improvement for the engine. Just think of all these workarounds being gone in an instance by just passing WPO and value into the call right from the shader…
Ofc, some things like water still would have to compute their own information since you need to query a specific location in world space for the specific value.
Other things, like a time sine reaching a value of 1, could directly trigger the event for whatever it is.
In my case, even acrually knowing that the event has occured once would be a drastic improvement on workflow… as it is, id have to pre-program the brighteat spot color value and manage the math in code.
Which isnt a probelm and is proabbly better off in the end. Still…
This should be more than possible, it´s just that you seem to have to analyze the texture in Niagara to tell the Emitter, which pixel value do they have to look for to spawn something.
I guess, you want to bypass that part, and a direct way of communication from material to emitter. No waiting for the texture to finished being created, then having Niagara to analyze each pixel to check, if the spawning should happen.
Whelp, until that happens, we have to go the more cumbersome way with all those extra steps
Haven´t looked to deep into that, but controlling emitters via textures created some results on youtube:
In the latter one i personally would have changed the order on how the particles spawn. As far as i understood, they first spawn particles everywhere, then use the texture to erase all particles, that do not have the desired pixel value. Sounds unnecessary, if you could simply use the rule in the very first step, check the value to let particles just spawn where the value reaches the desired height.
At least that should be possible, i think.
