Is it possible to somehow cache particle starting positions and once it dies it would start from the same position?
I spawn particles using a depth map to determine world height. Reading from this texture I assume is quite expensive todo per each particle when theres 100000s of them. So reusing the start position instead of calculating new one would probably help.
Hello.
First I would like to get a little bit more info about what you’re trying to achieve.
That should help us to better understand your problem and to give you more pertinent answers.
Caching/storing the the Starting Position is something possible but more context would help:
Is it a one time Burst of Particles and everytime that you Spawn your system you need the same starting Pos?
Is it an infinite Looping Particles system ?
Are you actually doing Rejection Sampling ?
How are you currently sampling the DepthMap ?
Is the DepthMap Static or does it need to be dynamic ?
Did you encounter performance issues or is it a concern due to the number of particles?
Those are some of the questions that need to be answered to get a better answer.
And to answer those questions, having a better and broader description of what you’re trying to achieve would help.
I’m trying to make rain effect that occludes with the scene. It works well, and the performance seems decent enough while sampling the depth map with a million particles too. Though looking at best ways to optimize this fully. Particles could just loop from start to end once spawned.
- infinite looping.
- not sure what rejection sampling is.
- using a sample2d and set position on initialize particle. offseting position based on depth.
- depth map is prebaked.
- the only performance issue I encounter is changing the constant spawn rate on Update(), which actually drops my fps from 100 to 50.
8505365–1132949–VFX_Rain.zip (16.2 KB)
Thanks for giving me more infos and for sharing your VFXGraph.
By looking at it here are some suggestion regarding performances:
Shrink “Capacity” to the best fit:
Capacity is used as Memory Allocation for your max Particle counts, so you need to keep it as tight as possible.
Depth Map Resolution:
Try to play with the Resolution of your Depth Map and go with the lowest possible.
Culling/Killing particles:
You can use the “SetAlive” attribute to Kill the particles based on their Height.
Here I’ve reproduced your setup, where I sample the DepthMap at the initContext and Offset it on the Up-axis.
I store the initHeight, and compare it to the CurrentPos Height to Cull the particles.
To get better performance you can also lower the Particles Count. Less particle count = less memory , less sampling etc…
By looking at your setup I think that you could get the same density with a lower particles count.
You’re drawing a Box centered Around the Camera. By doing so you’re simulating a lot of Particles Behind the Camera. So you can try to offset your initialBox in the Camera Forward direction. This way most of what you Simulate and “pay for” are in front of the Camera.
Other Solutions, might be to try to loop the Particle at their InitPosition instead of killing them.
So you’ll have a Number of “infinite” particles that would make a modulo between their initPos and the Depthmap.
Wish you a great day.
Great! Thanks for the tips, I already managed to do some density optimizations and spawning at random position, so I only need to render them in front of the camera. Also I noticed a really weird behaviour. I made a compute shader to read depth values from the same map as the particle system uses to do rain audio. And it appears to drop the performance really badly while the compute shader itself runs at 0.007ms from dispatch to reading the buffer value out. Could it have anything todo that the texture is shared between the vfx and compute shader? Will play around with duplicate texture2D next.