Tutorial - representing grass as an agent or as a property of the environment?

[AshurstJ]

https://colab.research.google.com/github/FLAMEGPU/FLAMEGPU2-tutorial-python/blob/google-colab/FLAME_GPU_2_python_tutorial.ipynb

in the above tutorial the "grass" is represented by its own agent, would it be possible instead for the grass to be represented by a 2d array to represent the grass values across the x and y coordinates - and then use host functions to interact with this array (e.g update amount of grass in all coordinates within a specific distance to an agent)?

If it's possible/viable then would it be a good approach?

[Robadob]

We recently introduced a new feature of environment 'macro environment properties'. These sound appropriate for your described use-case.

Macroscopic environment properties are intended for models which require large amounts of environment data to be stored or to provide simple communication between agents (e.g. counting, exchanging data) without needing to send and receive messages across multiple simulation layers. However, it should be noted that macro environment properties are less efficient than the regular environment properties described above, as they reside in slower memory.

Macro environment properties can be defined similarly to normal environment properties. However they support arrays with upto 4 dimensions, and are always default initialised to 0.

Agent functions have access to a limited set of (atomically backed) operations, which can operate on macro-properties. However, care must be taken to avoid race conditions (e.g. by performing a non-atomic read of the macro property in the same agent function which atomically mutates it). If running with SEATBELTS enabled, exceptions will be thrown if potential race conditions are detected.

(Source)

Other relevant links from the userguide:

• Agent function access
• Host function access

As these are a feature new to FLAMEGPU2, not present in FLAMEGPU1, any feedback would be really useful. It's possible we'll tweak the API in future if users are finding it a bit too hard to use correctly, e.g. with the atomically backed agent function accessors.