Struggling With Understanding How Things Come Together

[granite trench]

I'm trying to familiarize myself with ECS, I'm using package version 1.2.4. There are so many different approaches in documentation and none are quite what I'm looking for in my use-case and many are deprecated.

I'm struggling to understand how things come together when working with Queries of all Components of a type.

I have a large number of Entities that I'm trying to calculate gravity between.

I've approximated the calculations successfully through a Quadtree. I know what forces should be applied to each Entity.

To build my Quadtree, I needed a full array of all "ForceEmitters", so I used an EntityQuery. This was problematic because it doesn't return a reference, so modifying the PhysicsVelocity component does not have any effect in game.

I was able to get the references to the PhysicsVelocity via SystemAPI, but this didn't seem to have a way to gather all "ForceEmitters" to pass into my quadtree.

I believe this is a flaw in my understanding of how to use ECS/Jobs in general. I am looking for suggestions or advice on how to approach such a problem. I am happy to show code or meet if someone is willing to.

[subtle geyser]

Not entirely sure what you want to do, but there's probably two steps to it:

• Build the quad tree
• Write to the physics velocity

So first you'd want readonly access to force emitters and build a quadtree, which you can do through an entity query
Then after you've done that you can use either SystemAPI.Query to loop through all your effected objects and modify the PhysicsVelocity component. If you have a lot of objects then you might eventually want to convert it to a Job that can run in parallel.

[subtle geyser]

The key takeaway is to not try to do everything at once, but split them up into sensible steps that can be done sequentially on a large amount of entities

[sinful shoal]

I concur with the above by ITR.

You can have random write access via ComponentLookup/EntityManager.SetComponentData or sequential write access (more efficient) access via reference parameters in IJobEntity/IJobChunk/SystemAPI.Query. If your data structure allows it and lookup for a given entity is inexpensive, you should use one of the latter mechanisms to perform modifications in a separate pass after creating your data structure, using a parallel job if you can. Better, if you set up the data to be based on the query order, you should be able to get the same order if no structural changes / enabled state changes are made in between, but you’ll need to use EntityIndexInQuery to get the index which has its own cost.

[granite trench]

Gotchya, so it is standard to use EntityQueries and SystemAPI together? I thought System.API was meant to be an alternative to EntityQuery.

My current workflow is:

1. Query all ForceEmitters.
2. Sort them into a quadtree.
3. Pass quadtree data to a IJobParallelFor. This job runs once for each Entity and determines the forces to be applied to that entity and stored it in an array.
4. After the jobs complete, I iterate through the array and apply forces (this is the part I am having issues with).

I think I might be misunderstanding how to use ECS/Jobs. I might still be a little too GameObject oriented. Currently these all happen at once in an ISystem. Its not clear to me how I could split these up into sensible pieces if the jobs are dependent on the quadtree being fully formed.

My concern about doing a Query then getting the same entities via SystemAPI, is that it isn't clear to me how I can query for a specific entity or a specific entity's PhysicsVelocity or if the order would be the same. I'm not sure I can rely on index here.

[granite trench]

I'm not sure how this would work since I need to gather all forces first in the quadtree before I can calculate the forces applied to each Entity.

Also, I tried EntityManager.SetComponentData and that didn't seem to work. Logs showed correctly calculated forces, but SetComponentData seemed to do nothing in-game.

This could also just be a miss on my part, though. Perhaps I didn't add something to the Entity that I should have. I just have a GameObject with an Authoring component and a Baker that adds a "PhysicsVelocity" component to it. Perhaps I need another component. I can check when I get home.

[subtle geyser]

SystemAPI is just a shorthand for most functions you need in ECS. EntityQueries are kind of different than SystemAPI.Query though, you'll want to check out the link in my reply.
Nothing here requires setcomponent, just do a query or job that takes the position as input and the physics velocity as ref. A bit difficult for me to know what you're doing without seeing your code

[sinful shoal]

That’s why I said to use a separate pass, very much like you’re doing now, where your first operation does the building with the all the information and the second does the writing in an efficient way using query order or a parallel job if possible. The disconnect may be that I called creating the data structure the first pass, I should’ve included the computation of per-entity data in that. The process of assigning per-entity data is specifically what I was referring to as the second pass, sorry about the lack of clarity there.

EntityManager.SetComponentData definitely has an effect if it doesn’t error out. It could be that there are other changes overriding it, the changes aren’t what are appropriate for you to see an effect, or you’re looking at or modifying the wrong entity.

[granite trench]

Thanks! I'm gonna give it another go. I appreciate your feedback.

[granite trench]

Also, turns out the authoring gameobjects don't move in scene view (which is what I was watching). That, plus the entire-too-small mass values made it looks like nothing was happening.

[sinful shoal]

You can deal with the scene view thing by setting scene view mode to runtime data under Preferences/Entities