@jameswatt There is a global set of data for the wind fields that you can write into. Particle emitters by default ignore this field, so you need to opt-in to read it. Particle systems can read a bunch of data from the surrounding game world, but it’s not a user-defined set from the VFX end. It’s always data that I’ve asked the code team to provide. Things like terrain or water position, world wetness from rain, etc. Emitters themselves don’t communicate with each other outside of wind or displacement - it’s something we might pursue on our next project if need arises.
We used wind emitters around hero/npcs to scare away particle animals as well as things like the fire example. The wind was used in conjunction with our event system, which can do things like set animation state on a bird (idle, takeoff, flying) or add turbulence to leaves based on wind speed. Because of the way our expression system works it’s really easy to do something like make a threshold test and have on/off switches, map values so it’s gradual or create a keyframe graph that controls a particle input after the condition is met.
In terms of the river flow, we’re reading from a set of flow data baked to textures. It’s not the highest resolution and there are still plenty of cases where a particle will flow through rock/ground, but it’s good in most of the cases. I like to call 80% functionality “good enough for massive open world.” Like, it’s good enough on balance to do it vs not doing it over the minority of smaller visual bugs. We’re not using any realtime SDF data or anything here, though that’s the direction I’d like to pursue for the next project so we can get more accurate rock deflection. Potentially a mix of artist painted flow + SDF would give a good combo using current tech.