Unity Unite Now Q&A - Stacking up the New Functionality in DOTS Physics

Thanks for the session!

I was surprised by the introduction of state into the Unity physics engine, as I was under the impression that "statelessness" was one of the core design goals. I can imagine users using the Unity physics engine believing that they can "just add" rollback networking to their game when the time comes due to the simulation being deterministic, but not being able to do so without (possibly a lot of) debugging and code changes because they used the trigger events system.

Was the introduction of state into the simulation the only way of solving this problem? And are there examples of properly saving the state for rollback anywhere?

And another question:
I've seen "rollback" and "GGPO" mentioned a couple of times in conjunction with Unity physics. Are there any official samples where any of those techniques are applied?

 

I'm doing my own (3d) motion planning, and for that I need to find out if a point is inside an object. Right now I'm doing that via very short raycasts using dots physics (much shorter than any of my geometry) and that performs really well! Is there anything I can do to have it perform even better?

 

Since there's simple state introduced now, could it be possible to add a simple sleep state as well for the RB simulation? That being said, I don't know how big gains there would be for that alone as I think that part of the sim is still relatively cheap.

 

Too bad about the asynchronous events breaking determinism. Wish you had a synchronized method callback. Or at least the option to run and rerun the sim synchronized.

 

Stateless doesn't mean literally no state, it just means no hidden internal state. You can still do rollback, you just also need to serialize the trigger events buffers in addition to the usual position, velocity, mass, etc... It really doesn't complicate rollback very much.

 

Great session, a lot of great new info! That stress test by @PhilSA is

Can you tell us more about the direct solver, mentioned at 22:26? I'm looking forward to this the most, as the "softness" with large mass ratios is a huge problem for realistic ropes. I am especially interested in what are the disadvantages of using it? Is it one of those "articulation"-type solvers that don't allow loops? Is force application and collision with individual segments possible?

 

I have never liked asynchronous events for physics system. Often you want to do a calculation immediately and feed that data back into the physics engine. Maybe it would be better to rethink how this all works and design a system that does not break determinism. Not only for roll back but because you can get odd behavior with events. C# events were never designed for real time applications.

 

Thanks for all the great questions folks. I'll try and answer each individually.

The main thing I want to address first though is that Unity Physics is still focusing on being stateless (or cacheless, or single state, or no internal state - do we need a better term for this?).

The approach taken to the events shown in the session, is that it is still code in the Samples project, sitting on top of the stateless core. i.e. multi-frame information is still something that the developer will add if they wish.

Another design goal has been to keep the core Unity Physics code as simple as possible. Adding cache for the likes of deactivation, makes for an much more complex web of code. So rather than significantly increasing the complexity of Unity Physics, instead we are planning on exposing functionality in the Havok Physics simulation backend to allow users to flush its cache and make specific points in time suitable to rollback.

If you choose to use the events example code that will be shipping along with in the next upcoming release, then you would also need to flush (or replicate) the event data at specific points to achieve rollback with Unity Physics as well.

I'll leave that as a high-level reply for the minute, and go an try to answer each post directly.

 

Hopefully my reply above addresses the continued focus on 'statelessness' within Unity Physics? Just to be clear though, multi-frame state has not been introduced into the simulation.

If you choose to add the extra sample event processing systems, then the entities will have DynamicBuffers holding the event state added to them (previously components were added and only dealt with single Trigger overlaps).

We should certainly add a rollback demo, which would be more focused than the pool demo with is looking forward in time rather than back. That said, an example saving a set of entities with components/buffers should be a generic ECS demo rather than a Unity Physics specific one.
The extra event processing systems save the previous Physics event streams so that it can compare them with the next frames stream. To rollback a simulation to a previous time when using this event system, you'd need to save the the entities (along with their associated data) and also reset the event stream double buffer, as suggested by Cynicat.

 

You could probably just use the CalculateDistance query directly, but can I suggest you open a separate thread on the main Physics forum so the question can be addressed independently?

 

Again, there isn't any extra state in the simulation code itself, just in the extra event processing code. My bad for not making that clear enough in the session.

Deactivation is one of the most complex pieces in the Havok Physics code base so there is no simple generic sleep option . Any specific application developer might have a clear idea of their own specific {de}activation heuristic though, and we are adding extra features to better enable the easy manipulation of the simulation. For example, the CollisionResponse.None option to quickly remove unnecessary collision detection overhead, or a new PhysicsExclude component tag which can be added to quickly remove an Entity from the simulation altogether.

 

As I mention above determinism is still ensured.
I'm not sure what you are asking for though, can you elaborate? Are you just asking for the OnTriggerEnter style callbacks?

 

Is Kinematic Character Controller gonna be a free standard feature?

 

The direct solver was added specifically for Havok Physics games customers wanting to have better support for physics puzzles without having to resort to mass ratio tweaks and/or increasing the simulation iteration count. There is a lot we can talk about here.

First the direct solver only works on holonomic constraint atoms, i.e. a constraint atom with no freedom of movement. So for a Fixed Joint the direct solver could work on all 6 DOFs, and for a Ragdoll Joint the direct solver would only be working on the Ball/Socket element. Where constrain atoms can't be handled by the direct solver, then they are handled by the default solver instead. For example, with a Limited Hinge Joint, the 3 fixed linear degrees of freedom and 2 fixed angular degrees of freedom would be handled by the direct solver, however the 3rd limited rotation constraint atom would fall back to the default solver.

>> Is it one of those "articulation"-type solvers that don't allow loops?
There is no limit to the topology, though in terms of performance, a chain is an ideal scenario for the direct solver, while a worst case topology would be a single central body with all the other bodies attached to that one. In short, you can have loops.

>> I am especially interested in what are the disadvantages of using it?
The main disadvantage to the direct solver would be a performance cost around 3x more expensive compared to the default solver. You also have to designate bodies to belong to constraint groups, so there is slight cognitive cost in terms of management but much less than say, messing with mass ratios etc.

>> Is force application and collision with individual segments possible?
Individual elements of a chain will still receive impulses from the application or a collision response, though now we should consider the nuances.

Constraints can still be violated. Consider a chain of 10 capsules each weighing 1kg each. The first is attached to a static body and the last attached to another dynamic body that weights 1000kg. If you drop the ton weight or drag it with the mouse spring you can still separate the elements. So a chain of Ball Socket Joints under extreme stretch will introduce rotational errors which, when a averaged out over the iterations, results in linear separation. As the end mass decreases the chance of separation decreases dramatically, so a 250kg end mass might not lead to separation at all.
Another example of rotation error creeping in in a slightly unintuitive way would be with a similar chain of bodies connected with Hinge Joints rather than Ball Socket Joints. This time the hinge axis is setup so that the chain to stick out perpendicular to the gravity vector. With the directly solver, the end mass won't sag down with gravity, however if is closer to the static body than the full extent allowed, then the rotational errors can lead to the chain elements moving when you won't expect them to.
Finally, collision responses are also solved last i.e. they take highest priority. This means that a dynamic body hitting the torso of a ragdoll will lead to the limbs getting separating, even if the constraints are being solved by the direct solver. The separation will be handled much better on subsequent frames than if they where solved by the default solver but they will still separate.

So the direct solver will be great middle ground between firmer joints, performance and flexible setups. We will look at adding more features (e.g. limits) for the direct solver in the core Havok Physics SDK in the future but we need to expose it to the Havok Physics for Unity simulation backend first

 

There will always be a sample Character Controller with Unity Physics that handles the basics and is open for developers to extent for their specific use-cases. However, just as Havok Physics for Unity has a commercial element and handles more rigid body simulation edge cases than Unity Physics, the Kinematic Character Controller, developed by @PhilSA, will always have more features and handle more edge cases than the version in the samples.
We do hope the open nature of Unity Physics will allow other developers to build extensions for release on the Asset Store.

[Edit: Thanks again to Philippe of being part of the Unite Now session]

 

Just to clarify a little bit, this specific character controller I've presented at the end of the talk is a project that I'm doing independently, so the plan is to sell it on the asset store

However I'll most likely find a different name than "kinematic character conttoller" this time, because that is quite a mouthful

 

@PhilSA - How close to a beta are you with this? I've been working on something the last couple of weeks, but you've already got the main features I was looking to implement. I'm more than willing to get on the paid beta train if that's possible.

 

I expect this to be about 2-3 months away from a beta release where sample content will be scarce but the core project will be useable

Just keep in mind that this is a very vague estimate that could change depending on all sorts of factors

 

Got it, I'll roll my own for now using a previous project's (non-DOTS) code for prototype, but I'll keep an eye on this.

 

You can also try to use the character controller implementation in the physics samples, it might not be as advanced as Phil's, but it can get you started for sure until Phil gets his stuff out. And you can tweak it the way you like it.