29-01-2018, 10:59 AM
Thanks for the reply! I didn't know how the simulation worked internally regarding collisions, but this approach actually makes sense performance-wise. That's an interesting topic 
Then, maybe it would make more sense to be able to get the neighboring particles at least from different phases. Of course, that would still need to be "flagged" in the docs as a low-performance approach, but depending on the use case, it might be actually reasonable (ie: in my project, I'm replacing colliding particles from 2 phases into a new emitted one, as they flow in each other, so it ends up having only a reasonable operations per second, as the mix of the two liquids occurs progressively, and each particle can only collides once into another phase before being replaced).
But anyway, in my case, I cheated a bit and added a trigger where the mix is supposed to take place, and the collision detection is performed against this collider and not the other phase. I don't know if there would be a more precise approach, but at least is works roughly
Then, maybe it would make more sense to be able to get the neighboring particles at least from different phases. Of course, that would still need to be "flagged" in the docs as a low-performance approach, but depending on the use case, it might be actually reasonable (ie: in my project, I'm replacing colliding particles from 2 phases into a new emitted one, as they flow in each other, so it ends up having only a reasonable operations per second, as the mix of the two liquids occurs progressively, and each particle can only collides once into another phase before being replaced).
But anyway, in my case, I cheated a bit and added a trigger where the mix is supposed to take place, and the collision detection is performed against this collider and not the other phase. I don't know if there would be a more precise approach, but at least is works roughly