Suggestion / Idea ECS Physics/Graphics Support

[Jawsarn]

Hey!

Wondering if there's any plans to support ECS Physics and/or ECS Graphics?
Would be great not to have to add a GO per entity for those we want to add Oi Colliders to, and also if we can keep the rendering on ECS side.

[josemendez]

Hey!

Wondering if there's any plans to support ECS Physics and/or ECS Graphics?
Would be great not to have to add a GO per entity for those we want to add Oi Colliders to, and also if we can keep the rendering on ECS side.

Hi!

There's no immediate plan to support ECS. The main reason is that under the hood, Obi already works in an ECS fashion (both for physics and rendering) so switching to Unity's ECS would yield absolutely no performance gains - the only improvements would be UX related.

Regarding UX, Unity's "ECS for all" initiative involves unifying GameObjects and Entities under the hood - so that you can have mixed hierarchies involving both. If materialized (big emphasis on the *if*, I'm looking at you Unity), I believe this would largely solve the UX friction.

Let me know if I can be of further help,

kind regards

[Jawsarn]

Hi,

Thanks for the reply.

... so switching to Unity's ECS would yield absolutely no performance gains - the only improvements would be UX related.

- GameObjects will get entities, this does not mean entities based project will need to have GameObjects afaik.
- The update of e.g. ObiSolver Inertial Frame fetches transform.position and cause transform jobs to cause a sync point and wait, this _can_ be big performance sink if you run a lot of jobs.

I understand the hesitation to do anything since it doesn't seem to be too _far_ away and a lot of things might be unecessary.

It would however, give us who use ECS a bunch of neat functionality to e.g. optimize what colliders we enable for Obi efficiently through jobs etc.
(I don't think this would be solved by unity when it's unified, but would instead have to be you to move the implementiaton to ECS (if you want to improve the UX here that is))

Anyway. You are not the only stakeholder in my issue here to get rid of gameObject dependency.

But I have another issue I would want support with;
My case is to have a character on a platform, I think my end goal is would be to have 100% wind linear + angular velocity from movement and interta from local movement on platform,
and only have partial from platform the playform.

When I move things with ECS and interpolate it with physics, I get a lot of jittery impulses from world velocity and linear inertia. (I think also for rotation, but I'm not rotating that fast to make it noticible) My guess here is that it happens by inaccuracies in deltas + interpolation between physics and obi. I tested to set 0 inertia, sim space local, and apply delta movement as wind, and it had same issue.

So first thought has been to apply the velocities manually through the wind property (I think applying physics based velocities would remove the jitter here) - but inertias makes it tricky.
I like the effect of inertialWind of having Simulation space in World. So I think optimal would be having custom methods to be able to specify the current delta translation/velocity (linear+angular).

Happy to hear your thoughts.

[josemendez]

- GameObjects will get entities, this does not mean entities based project will need to have GameObjects afaik.

More like GameObjects will become entities under the hood, according to their description of how they plan to make it work internally.

- The update of e.g. ObiSolver Inertial Frame fetches transform.position and cause transform jobs to cause a sync point and wait, this _can_ be big performance sink if you run a lot of jobs.

Transforms will be unified between GameObjects and Entities and there will be no sync /data copying between them whatsoever. This is mentioned in the discussions thread I linked:

Transforms will also be evolving to reduce the considerable time spent to read/write/sync Transform data between GameObjects and Entities. Unified Transform will merge ECS and GameObjects Transforms so we no longer have to copy data between two different representations. [...]  You will also be able to manipulate the Transform of a GameObject directly via ECS APIs, fully Burst-able.

I understand the hesitation to do anything since it doesn't seem to be too _far_ away and a lot of things might be unecessary.

Using Unity's ECS system instead of our own would essentially require rewriting the entire asset from the ground up, which is probably not worth the effort given that Unity is planning for tighter integration of ECS and GameObject workflows in the near future.

But I have another issue I would want support with;
My case is to have a character on a platform, I think my end goal is would be to have 100% wind linear + angular velocity from movement and interta from local movement on platform,
and only have partial from platform the playform.

When I move things with ECS and interpolate it with physics, I get a lot of jittery impulses from world velocity and linear inertia. (I think also for rotation, but I'm not rotating that fast to make it noticible) My guess here is that it happens by inaccuracies in deltas + interpolation between physics and obi. I tested to set 0 inertia, sim space local, and apply delta movement as wind, and it had same issue.

How/when are you moving things relative to Obi's update? Could you give a bit more information about what you're doing and how?

Interpolation (as in physics state interpolation) doesn't affect physical behavior, it only affects visuals. The thing being interpolated is object positions/orientations resulting from two different physics steps, but the interpolated results are not fed back into the simulation - unless you're using a physics simulation to move the solver itself (eg. drive solver movement using a rigid body's interpolated position), in that case you will likely have issues caused by the interplay between interpolation and simulation.

So first thought has been to apply the velocities manually through the wind property (I think applying physics based velocities would remove the jitter here) - but inertias makes it tricky.
I like the effect of inertialWind of having Simulation space in World. So I think optimal would be having custom methods to be able to specify the current delta translation/velocity (linear+angular).

The world-space inertial delta is calculated by subtracting the solver's position in the last update from its current position (same for angular, but using quaternions instead). This is done right at the start of each physics step, so it should always be correct as long as the position of the solver is consistently updated.

kind regards,

[Jawsarn]

Transforms will also be evolving to reduce the considerable time spent to read/write/sync Transform data between GameObjects and Entities. Unified Transform will merge ECS and GameObjects Transforms so we no longer have to copy data between two different representations. [...]  You will also be able to manipulate the Transform of a GameObject directly via ECS APIs, fully Burst-able.

My take of this is that the GO Transform will just be propety backed by a ECS transform. You can interact with it directly from GO without going through hoops of managing Entity reference and belonging World yourself - and it will be faster. But, it may still cause sync points, because systems will still mutate it - and if you don't want to end up with race condition, and still keep scheduled jobs from systems, there's not much of a choice.

How/when are you moving things relative to Obi's update? Could you give a bit more information about what you're doing and how?

As stated before; I use ECS with a presentation gameObject.
This means that I don't use PhysX, but the Unity Physics (ECS) for the physics world.
ObiSolver is set up on the presentation gameObject of the Player. In the child hierarchy I have Obi Bones, but will later have cloth as well.
ObiSolver is set up with Asynchronous mode, Burst (CPU), Interpolateion.None. I've tried different options here but none seem to improve the issues.

The game loop looks like this;

Frame
Fixed Update
- ObiSolver FixedUpdate (Only Completes)

Simulation Update
- Prediction tick
---- Fixed Step (store state to interpolate)
- Interpolate Position From Physics (Both platform and player interpolates here in sync with eachother)
- Update GameObject transforms from entities

Late Update
- ObiSolver Updates

Rendering

So the Obi Solver is moved by a physics simulation that is interpolated.

I think either driving the update manually;
- Being able to call the contents of LateUpdate with my own FixedDeltaTime and Steps from the ECS Fixed Steps, this means I can set the transform temporary to "fixedState platform localPosition" before manually calling the previous mentioned function
Cons;
- It needs the same physics fidelity rate as the simulation
- Inertia is only from local platform position, no custom % inertia from platform

Or
- Have an override/callback for InertialFrame to set custom Velocity and Acceleration (ignoring Transform translation).
I think the angular velocity form VelocityAtPoint is a bit more problematic to solve here since I don't think I can override the Transform to e.g. latest fixed state platform "localPosition" as I think it would be jittery? But not sure.

Thank you for your time.

[Jawsarn]

Hi, just checking in if you had time to read the message above and have some comment. I've dealt with a few other problems to solve so comming back at this soon.

Thanks again.

[josemendez]

Hi, just checking in if you had time to read the message above and have some comment. I've dealt with a few other problems to solve so comming back at this soon.

Thanks again.

Hi,

As previously mentioned, the problem likely is that you're feeding interpolated values back into the simulation:

Interpolation (as in physics state interpolation) doesn't affect physical behavior, it only affects visuals. The thing being interpolated is object positions/orientations resulting from two different physics steps, but the interpolated results are not fed back into the simulation - unless you're using a physics simulation to move the solver itself (eg. drive solver movement using a rigid body's interpolated position), in that case you will likely have issues caused by the interplay between interpolation and simulation.

So the Obi Solver is moved by a physics simulation that is interpolated.

Depending on which synchronization mode you're using for the solver, a possible solution would be to move the solver using the uninterpolated position instead. (in Unity's built-in PhysX physics, that would be using rigidbody.position instead of transform.position to move the solver).

- Being able to call the contents of LateUpdate with my own FixedDeltaTime and Steps from the ECS Fixed Steps, this means I can set the transform temporary to "fixedState platform localPosition" before manually calling the previous mentioned function
Cons;
- It needs the same physics fidelity rate as the simulation

Unless I'm misunderstanding what you mean, this is exactly the same as setting the solver's synchronization mode to Synchronous Fixed. This guarantees the solver will update exactly once per fixed update, matching the rigidbody engine's (PhysX or Unity Physics) temporal fidelity. (see the manual for details, specifically the last section called "Bolting Obi onto Unity's time stepping").

Note that since you're using ECS, you should set your project's fixed timestep in the Time settings window (which is the value Obi looks at) to match your FixedStepSimulationSystemGroup value.

kind regards,

[Jawsarn]

... matching the rigidbody engine's (PhysX or Unity Physics) temporal fidelity.

This is not correct. As I noted above the Unity Player Loop, PhysX runs on FixedUpdate, while Unity Physics runs in Simulation Update->Prediction->FixedStep.

But that one idea is similar otherwise. I just can't assume that FixedUpdate and Unity Phyiscs FixedSteps match up.
Maybe one could do a longer delta for multiple fixed instead of looping it, but that's just optimization.

For that option I think in the end one would want a Synchronization type of Manual and be able to call the methods manually, and some of the LateUpdate to be extracted to a method to be called with custom delta times.

[josemendez]

As I noted above the Unity Player Loop, PhysX runs on FixedUpdate, while Unity Physics runs in Simulation Update->Prediction->FixedStep.

That’s why I pointed out:

Note that since you're using ECS, you should set your project's fixed timestep in the Time settings window (which is the value Obi looks at) to match your FixedStepSimulationSystemGroup value.

I just can't assume that FixedUpdate and Unity Phyiscs FixedSteps match up.

Unless you’re using both PhysX and Unity Physics simultaneously (I’m not even sure if that’s possible) I fail to see why you can’t just set both to the same value? This is by far the simplest and most robust fix.

Maybe you’re using FixedUpdate() for non physics related stuff?

Maybe one could do a longer delta for multiple fixed instead of looping it, but that's just optimization.

This is what asynchronous mode does: it accumulates all fixed updates triggered during the last frame and takes a single, longer step with a multiple of the fixed timestep (note that substepping still applies).

For that option I think in the end one would want a Synchronization type of Manual and be able to call the methods manually, and some of the LateUpdate to be extracted to a method to be called with custom delta times.

This should be already possible by calling StartSimulation() and CompleteSimulation() manually. I’ll whip up an example and share it with you.

Kind regards,

[Jawsarn]

Unless you’re using both PhysX and Unity Physics simultaneously (I’m not even sure if that’s possible) I fail to see why you can’t just set both to the same value? This is by far the simplest and most robust fix.

Maybe you’re using FixedUpdate() for non physics related stuff?

I have tested this, and it does not fix the issue just out of the box. The positions will still be interplated from "Interpolate Position From Physics" system, and then there will be one or multiple physics steps next frame that cause inaccurate impulses by translation deltas.

This is what asynchronous mode does: it accumulates all fixed updates triggered during the last frame and takes a single, longer step with a multiple of the fixed timestep (note that substepping still applies).

Yes, but this out of the box for me uses my interpolated positions. I could try to set the positions to fixed ones temporarily before LateUpdate to update them right before rendering, but it's a bit of a hack and not really fool proof. Using this mode without my setup, does it not cause inaccuracies in impulses from world inertia as well? Additional question to that; does rigidbody interpolation happen before Obi Updates, i.e. are positions based on rigidbody interpolation or the fixed position if one would use those?

This should be already possible by calling StartSimulation() and CompleteSimulation() manually. I’ll whip up an example and share it with you.

Somewhat, yes. I can of course modify it all (probably how I will proceed to keep it as package and add a patch on top), but would be nice if the asset provided more customization so that could be avoided. LateUpdate e.g. contains the interpolation by accumulatedTime that would be nice to use.

Best regards