So I have got particle based flamethrower. (quite a lot particles that don’t penetrate colliders)
I cannot use on Particle Collision (because I want particles to penetrate characters a little).
I have tried to do OverlapSphere for every particle but it is quite slow. And unfortunately we do not have OverlapSphere Command.
You could use a raycast depending on your flame. You don’t notice the difference if your flame is very directional. Also if you do that scale your ray with your flame.
well last thing I can think of is picking some random particles, like 30 or 50, and using them as the ray end. That would solve the problem with the performance I think, though I can not give an example on how to do that. If that doesnt help then idk what to do.
The only solution I can think of is just to gether all colliders in a bounding sphere of all particles.
Turn them into structure and then push all position and rotation of particles with this new representation of colliders onto job.
But it would cost me a lot of work and I see some problems with mesh colliders.
The question is how performant it would be in the end.
Pics of your flames would help us understand what specifically we’re dealing with.
Surely you don’t need every particle, or every frame? I imagine that ends up doing a heck of a lot of redundant checking of the same space. I would consider checking either X particles per frame or every Xth particle. You could do that with your sphere checks, ray casts (from previous position) or sphere casts.
I also wonder if there might be benefit to doing something such as a BoxCastNonAlloc to get “potential” collisions yourself and then manually querying against those? The physics internal culling is hopefully faster than anything we can write in C# land, but it’s probably repeating it for every cast you do.
The other thing I would consider is flipping the problem around. Have it deliberately calculate the shape of the flames (eg: by doing a bunch of ray or sphere casts) and then have your particles follow the results. I imagine it’s far easier to match visuals to collision info than the other way around, which is what you’re trying in the current approach. This probably also gives you far more control to deal with things when you start getting player feedback about it, because the hit detection and the visuals are less intertwined.
still use the particle collision in main particle system, and spawn sub particles (to penetrate) from collision point… *but sub emitters might be slow too
or have 2nd smaller, and possibly lower resolution collider, only for particles inside those target objects? (so that it looks like it penetrates surface…)
or using few primitive colliders (not 100% accurate, but maybe looks good enough) to check if particle enters inside them or collides (they are placed inside target objects…)