Hi - Pardon a really basic question, but that OOP part of my brain isn’t making transitioning to ECS easy…
I have a grid of nodes (structs), a node can be connected to any of its neighbors. Each node has a bitmask integer describing its current connections. So for a 3-axis grid, it would have 6 possible bit values.
In my OOP approach, a Grid class contains a dictionary storing all nodes by their grid coordinates. It also has FloodFill method for finding all connected nodes within some given bounds. Starting with a seed node, the method iterates over the seed node’s connections (bit values) and calculates the connected nodes’ coordinates. It then retrieves those neighbor nodes from the dictionary and puts them on a stack. The process is repeated for the stacked nodes as long as they sit within the given bounds.
Now going to ECS, I’m assuming my node struct becomes a component, and the FloodFill method should be jobified. What I’m not clear about is the role of the dictionary. If I make that a NativeHashMap, where exactly does it “live”? Should it also be a component? Thanks!
Short term: You can make it live in a system, or you can make it live in a ScriptableObject instance that lives in a shared component on some loner entity.
Mid-term: Once Unity releases the next Entities package, if they don’t already have good built-in support, I will be releasing a framework that allows for attaching components with collections to entities. Even if you decide you don’t want to use the framework, there’s a decent chance someone is going to figure out a way to rip out just that piece and expose it as a package.
Long-term: Unity will eventually wake up and realize Blizzard was right and support collections on entities. Hopefully sooner than later.
Other option is to use 3D indexing in a dynamic buffer.
I’ve turned to using either NativeArray of structs or Entities with DynamicBuffer as are the best practices so far. I have an AABB tree as a struct living on a system that updates and is built in an IJob, reading from ComponentDataFromEntity to update AABBs and reinsert them if they moved. At the end of OnUpdate the system copies the current tree to a read only version that other systems use for queries.
Not sure if this is the best way to go about it but writing a NativeContainer version requires more research on my part.
@DreamingImLatios
Did not know about using a ScriptableObject instance, is there any limitation to this? I’ve been converting Scriptable objects into IComponentData and DynamicBuffer of structs for use in systems.
Thanks @DreamingImLatios and @riskparitygawd .
Unfortunately, I can’t do 3D indexing in this case. But let’s say my NativeHashMap is stored in a system: I’m still not sure what my FloodFill job would actually be iterating over. It can’t be the map values - would a NativeQueue be a suitable stand-in for the node stack as described above? The assumption being that the job starts with a single seed node being queued and finishes once the queue is empty… I didn’t think this would be such a specific use case, but I’m having a hard time finding any concrete examples.
NativeQueue would work.
NativeQueue works. NativeList might also meet your needs. Or maybe recursion will do it too. Honestly it sounds like you are starting from an OOD (large dumb objects with batch processors) rather than an OOP approach. Usually OOD algorithms translate pretty easily into ECS, and I don’t see an exception here. You just changed the containers to use NativeContainers.