#Dual systems as a convenient and efficient (possibly) architecture for hybrid projects.

1 messages · Page 1 of 1 (latest)

chrome geyser
#

Hi people! I want to know your opinion about one architectural approach for hybrid projects realization.

The idea is to create a ComponentSystemGroup of systems including one unmanaged subsystem. In the managed system we realize logic interacting with GameObject, and in the unmanaged subsystem we take out all computationally complex intermediate logic.

In abstract form, such a pair looks like this:

`partial class CharacterMovementSystem : ComponentSystemGroup
{
protected override void OnUpdate()
{
// logic that updates IComponentData by getting actual data from the GameObject
....
base.OnUpdate(); // start the child unmanaged system, calculate the displacement at the current step

// apply the calculated displacement, e.g. with the help of CharacterController.Move
....

}
}

[UpdateInGroup(typeof(CharacterMovementSystem))]
partial struct CharacterMovementSystem_Internal : ISystem
{
[Burst]
public void Update(....)
{
....
}

} `

I think this approach is universal, and it allows you to retain the maximum advantages of ECS thanks to a clear division into simple logic that uses managed data and complex logic that uses only unmanaged data (which means you can use Burst, EntityJob and other cool ECS things).

The advantages are clear, but are there any disadvantages? For example, because of regular alternation of execution of parallelized logic in subsystems and synchronous logic in ComponentSystemGroup (I mean a large number of synchronization points or something like that).

shell elk
#

hybrid systems should really all just be grouped up at end (or start) of frame just to sync data

#

you really don't want to intertwine them with entity systems otherwise they will cause sync points on your jobs

#

if you're going to require sync points, ideally there is only 1 in your frame

chrome geyser
#

Thanks for the answer. Now I'm thinking of making two hybrid systems. One is grouped up at start of frame, and the other at the end. Both invoke an event in their onUpdate that entity systems can subscribe to.

vale forge
#

The start of the frame is the end of the previous frame so having it in both place kind of doesn't make sense to me.
Having one at the beginning/end of frame and one between the simulation and presentation group would be a more logical compromise to me.

shell elk
#

i might argue having start and end actually does make sense because as you say, it's basically 1 sync point

#

but it's not at the same time when you factor in gameobject land updates triggering

chrome geyser
#

At the moment I have set synchronization points to the beginning and end of the SimulationSystemGroup.

There are two points, since in the case of one, it seems that there will be some lag between the game object world and the entity world:

data synchronization (point 1) => data update by systems => [there should be a second data synchronization here] => rendering.

kind veldt
#

end of simulation system group is before presentation, I think that makes perfect sense

you may want destroyed objects to be gone by then (so destroy at the end), and spawned objects to be taken into account by physics and other systems (so spawned at the start)

but that's just my version

#

there's a good argument for avoiding sync points, so the end of the simulation frame you may want to just disable objects instead of creating a sync point