Official Unity Physics Discussion

Will

ScheduleStepJobs

ever require fewer Completes? Scheduling large numbers of PhysicsWorlds to update simulatenously has like, 50% idle time.

Edit: Oh, interesting, I wrote a custom Simulation implementation that lets me batch the sections that require Completes, but there's still about the same amount of idle time. Alas.

Double Edit: The completes are still the problem, though. 75% of my frame time is being spent in broadphase/pair generation, with really poor thread utilization during that time. Even with the various world data gathering jobs scheduled and completed as a group.

Triple Edit: If I'm maintaining multiple worlds and have to sequentially update each one multiple times (i.e., run PhysicsWorldA-Iteration1, PhysicsWorldB-Iteration1 together, then followed with PhysicsWorldA-Iteration2, PhysicsWorldB-Iteration2) the required .Complete calls make this even worse.

 

How long until the physics simulations are running within FixedUpdate? Can we manually step the physics world in FixedUpdate or will that break something?

 

see
https://forum.unity.com/threads/unity-physics-discussion.646486/#post-4337146

 

Perfect. This is exactly what I needed. Not sure how I missed it since it's in this thread lol. Must've been skimming too fast.

 

Perhaps I missed something, but there seems to be no support for terrain or any sort of static convex mesh shapes? This is pretty essential for most game-world use-cases.

 

PhysicsShape can be ConvexHull or non-convex mesh (which is probably what a terrain would be)

 

As @PhilSA pointed out, we have the Convext Hull and Mesh shapes. Do you feel those would satisfy your needs to terrain or large world use-cases? Anything we should absolutely focus in on or ensure is part of shapes to support large, open worlds?

 

Origin shift would be a big one, and important to get it implemented sooner rather than later (before it necessitates too big a refactor)

Games like Kerbal Space Program, No Man's Sky or Star Citizen could not work without this. Their physics would get completely screwed by decreasing floating point precision when at large distances from world origin

Some thought should be given to whether this origin shift system should affect the Transforms System and Rendering systems as well. Seems to me like it potentially should... maybe

 

Star Citizen runs their physics in doubles, KSP does too for bigger distances (their local simulations were in single precision floats if I remember right).

That being said, anything to handle large worlds would be nice to have.

 

I don't see a terrain collider type there. Terrains are being upgraded to officially support holes, and mesh collision type is not sufficient performance.

 

What I am interested with is, would it be feasible to give every mesh instance own colliders, as if Megacity example would have them? Even giving simple mesh as sphere, or box?

Meaning, potentially thousands, or millions of colliders in the scene.
And preferably dynamic colliders, as if for example collapsing buildings of megacity.

 

In PhysX 4.0 for example, the "terrain collider" (aka heightmap collider) just got deprecated. Non-convex mesh colliders are now the suggested way of handling terrain collisions (same performance as the old heightmap colliders, but better quality/consistency apparently). I think this will be fine

 

If networking is going to be a key focus, then any networked origin shifting system has to also account for global to local mapping. It's kind of a tricky design problem because you absolutely don't want to be doing that just on demand whenever you have game logic that wants a global coordinate but is calling an api that deals in local coordinates.

Also as far as Star Citizen, I highly doubt they are using doubles in their physics engine. Yes I know what they have said but remember that's for player consumption so they don't care about being technically accurate. More likely they are just mapping global doubles to local floats at key points.

 

Btw when I say mapping global to local, I don't mean literally just multiplying/dividing and copying floats to doubles or visa versa. More like you would have a partitioning scheme where you store the float with a partition number. So game logic can then use that to access the local or global position depending on what feature needs what.

That type of design you could actually make part of physics, you just adopt a global approach to dealing with translations for origin shifting and use it everywhere.

 

https://www.gamersnexus.net/gg/2622-star-citizen-sean-tracy-64bit-engine-tech-edge-blending

Of course the whole engine isn't using doubles, but they use them for positioning and physics. I wouldn't be surprised if they still did some individual physics simulations on single-precision floats where the precision doesn't matter but they haven't really been clear where they limit it. Transforms are the biggest thing here as they can bypass the origin shifting mechanism with it.

 

I know the whole engine doesn't, it was physics specifically I doubt they do. It doesn't really make any sense compared to a mapping scheme.

 

It makes perfect sense in space sim IMO, but lets not start this debate again

 

A partitioning scheme lets you keep the entire engine using floats and doesn't leave you with any unsolved problems, even in a space sim. This is how Eve Online solves it FYI. What specific functionality do doubles solve better over a partitioned approach?

 

@smcclelland Yes, mesh would work (assuming it is performant). I didn't look at the implementation only the documentation and I'm not sure it was there.

As for other people talking about origin shifting... as important as that is, that may be out of scope for the physics engine. Instead that can be handled at a higher level, especially since this physics engine is stateless (so re-homing everything to a no local coordinate system is not a big performance disaster).

 

In this case we're seeing unity requiring this physics engine to have rollback, and that's unique already. Built in origin shifting is probably a few lines of code, because it's stateless and performing an add operation on all the colliders is not a measurable cost. Given probably all of Unity's other systems will have it (I can't imagine why not), stands to reason.

 

I don't think this physics engine "has" rollback as much as it provides a means for users to implement rollback simply because of the fact that it is stateless. You just feed it the "rolled back" state and tell it to do its thing. And by that same logic, you can feed it an "origin-shifted" state and it will still do its thing. And for that reason, I don't think the physics engine should be responsible for rollback or origin shifting or any of those special features that are generally required by other physics engines because with a stateless engine, that just isn't necessary anymore. State is completely controlled by us the consumers of the physics engine. We have complete control over the inputs and outputs and what aspects we want to modify. And quite frankly I hope that the engine stays that way and improves even more in that regard because that is what is driving me to use ECS.

With that said, I am going to call out any claims by the developers that it is impossible to do stacking or more stable simulations without internal state. Internal state is really just the state output of one physics simulation frame being passed into the next. There is nothing stopping the developers from calculating and exporting that "additional state" back to ECS and being able to collect it and integrate it in the next simulation frame. Sure you pay the cost of gathering and scattering this data in and out of ECS, but at the same time, some of us will find cool hacks to manipulate this "additional state" in ECS to implement some cool mechanics that might not even be possible in another physics engine. And for those who are building a large enough game where they want the state to stay internal for performance reasons, the Havok engine option sounds like a good solution.

Anyways, I wanted to thank the developers for giving us the code in C# so early in development and making the low level primitive queries public API. I would love to see a little more documentation regarding the internal data structures for colliders and the BVH as well as the inputs and outputs for simulating a few rigidbodies interacting without using the collision world. I have a custom collision detection system design that is specific to my game and I originally was not planning on using any sort of rigidbody physics simulation. But now I feel like I might be able to add some in "for the fun of it" once I understand how the code works.

 

Hey. I am pretty new to the whole ECS and would like to know if its possible to make a sort of "onCollisionEnter"/"onTriggerEnter". Would i need to make my own Component for that?

 

This is something that I've been struggling with for quite some time recently, but I do think I have an idea for how to solve this. Querying for a physics shape overlap should solve the issue for triggers, but I'm not sure what the ability is to check if certain colliders had collided. That said I think we still need some form of guidance to ensure that our interactions with the physics system follows an optimal route when querying. Luckily collision overlaps and trigger overlaps don't require the solver to process so investigating how that information is stored might yield some information with how we can consume it.

 

The height map terrain collider in physx was super limiting. We plan to switch to mesh terrain in order to facilitate improved graphics. Sounds like this should not be a problem.

 

In multiplayer it's far more complex then that. The server handles the entire world or at least larger parts of it then floats can handle. Which means entities at different offsets can be interacting in various ways.

Doing this at a higher level means you will depend on certain things working a certain way. Moving entitites between worlds needs to be fast. You need to make sure you can carry over all the necessary data. Some which if not designed for from the start might be internal and/or not easy to get out in a good form.

The approaches I'm aware of involve some type of overlapping partition scheme. So you can easily reason about what can possibly interact with what and you also end up with entities in more then one physics world. That's the approach I used, although there are likely some other good approaches also I haven't thought of.

If the engine design doesn't even account for what is required, even if it's implemented at a higher level or as a plugin, then it's likely higher level solutions will run into problems.

 

Well you are fine within about a 8 km space with floats and doubles take you out to solar system scales which is ideal for space sims. So the solar system gravity simulation can run at double precision, then you map ships to it and use a 8 km grid system for collision physics. Therefore an origin shift would move within the existing grid and not need two separate collision bodies to recalculate their origin offsets.

Of course very large ships or asteroids or large fast moving objects might need a higher scale collision space with lower precision e.g. 640 km

So adaptive scaling and accuracy as well as origin shifting will probably be needed to allow for a wide range of simulations.

 

Just wanted to pop in and say this is a great discussion and really helping us organize our thoughts around these topics. I'll be capturing a lot of these requirements and working with our engineering teams to explore various solutions so please keep these types of things coming. As you're using the system or playing with the samples, be sure to pop in here to give us direct feedback on how we can improve this or what we're missing based on your needs.

 

@smcclelland @steveeHavok It would be nice if the collision representations in Unity could be shared with physx too.

I certainly don't want to be anywhere near a situation where I need to have the same collider twice in memory, just because there isn't a full solution, and Physx will likely not support origin shifting in Unity anyway. So perhaps it would be better to look at a current feature comparison and ensure we don't need to do that.

Code (Boo):

1. ┌───────────────────┬───────────────────────────────┬───────────────────────────────┐
2. │ Physx             │ DOTS Physics                  │ Havok                         │
3. ├───────────────────┼───────────────────────────────┼───────────────────────────────┤
4. │ Fast              │ Performance WIP               │ Fast                          │
5. ├───────────────────┼───────────────────────────────┼───────────────────────────────┤
6. │ Non deterministic │ Deterministic                 │ Deterministic (only same CPU) │
7. ├───────────────────┼───────────────────────────────┼───────────────────────────────┤
8. │ Full featured     │ No stacking, limited features │ Full featured                 │
9. ├───────────────────┼───────────────────────────────┼───────────────────────────────┤
10. │ High network cost │ Low network cost              │ Low network cost              │
11. ├───────────────────┼───────────────────────────────┼───────────────────────────────┤
12. │ Free              │ Free                          │ Not free                      │
13. └───────────────────┴───────────────────────────────┴───────────────────────────────┘

*Physx technically deterministic on same CPU for local simulation from startup since 2018.x

Now I do understand the DOTS Physics are simple because rolling that back, it's trivial. It's stateless and can be done really cheaply.

But why does that also exclude the things we don't want to network and there is space for things we will not want to roll back. There is space for *limited* stacking that is deterministic across any CPU. The design of DOTS Physics should not be exclusively about rollback, because there is no solution that covers all bases in the above table.

 

Are we sure about that? (can't find a proper answer on google so far)

 

I'm sure an official answer to that will be forthcoming!

 

Well, technically PhysX is deterministic on same CPU too if you run the simulation on same parameters each time

 

Yes I'm very familiar with the problem. We've dealt with it in projects in the past. It's a problem for physics, rendering and everything in between. But rehoming the origin of stuff is not slow or difficult to do on a big scale. We had no issues doing it.

 

Yes and no... it calls itself deterministic given the same inputs, but inputs are everything including the scene itself. The latest PhysX (that they upgraded too) makes it easier to make it deterministic. See: https://blogs.unity3d.com/2018/11/12/physics-changes-in-unity-2018-3-beta/

 

This works for them because they have CCD. If you don't have CCD in Unity Physics and replace your heightmap with a triangle mesh, you will get good old tunnelling issues.

 

PhysX is deterministic on the same CPU provided you follow a few rules explained in the docs:

http://gameworksdocs.nvidia.com/PhysX/4.0/documentation/PhysXGuide/Manual/API.html#determinism

http://gameworksdocs.nvidia.com/Phy...l/RigidBodyDynamics.html#enhanced-determinism

Games like Crazy Machines relied a lot on this feature as part of their core gameplay, so it certainly works. I suspect it works to the same extent as Havok. But if you don't use the lib properly, sure, then you run into issues....

 

Can you explain why PhysX has a high network cost compared to the others? I didn't follow that bit.

 

FWIW you can do "stateless" physics in PhysX using the immediate mode API: http://gameworksdocs.nvidia.com/Phy.../Manual/RigidBodyDynamics.html#immediate-mode

The only thing you need for stable stacks in that mode is to cache a tiny amount of data for each colliding pair. So it is correct that technically it is not stateless anymore, but the data is stored and managed by the users' code so it should be easy to store that in DoD structures etc.

 

Its only a tiny demo, but the likes of a signed distance field could be implemented in a similar way the plane is added in 'AddNarrowphaseContacts'. This is definitely the sort of usecase that we hope anyone with a specific requirement might like to implement ;-)

The AddNarrowphaseContacts demo might be useful for this usecase as well, where you filter all Unity.Physics collisions and inject your own contacts instead.

 

Should be obvious. With rewind and determinism you only need to send inputs. Cost is night and day, plus determinism + rewind means you could be networking thousand objects with only the same cost as inputs being sent.

Some benefits to having built in rewind and determinism for networked "physics":

• extremely cheap
• scales to thousands
• very little network code

The downside is of course, you will incur more processing on the CPU, but the thing about DOTS is that it is very, very fast.

Overwatch uses deterministic physics and rewind, and apply this to a minimal amount of characters, so there isn't really much of a processing cost. I'll argue that Unity's DOTS will end up being faster, across different platforms.

 

Incorrect for the most common determinist architecture. Mostly lockstep-PTP is used. Often with a buffer. This results in a delay. A few games do use lockstep-server architecture, which can help with the delay.

http://www.gamasutra.com/view/feature/131503/1500_archers_on_a_288_network_.php

Rewind is normally used as anti-lag on a nondeterminist client-server architecture. But could also be used to rejoin a determinist game.

If client-server is too hard to program then you can always do a trusted client architecture. Which has some benefits.

You can have a hybrid determinist architecture. This is kind of very experimental I think a few game may do this but documentation is scarce. It will not scale like lockstep. It would be nice to have the option if it is free. Normally determinist code comes at a heavy cost. Stable stacks is a very small cost compared to the problems determinist code can have.

Do you have a link for Overwatch? I do not think it is determinist. I think it is client-server with rewind.

I think having a determinist physic engine is very good

 

Trigger and Collision events are definitely areas that need work. These didn't get a lot of love for the initial preview.
Currently the Simulation class in the StepPhysicsWorld system simply holds an array of trigger and contact events that you can hunt through for information after step completion.
I recommend digging through the DebugDisplay code for examples of digging information out of the system. Specifically DisplayTriggerEventsSystem.cs. At time of writing, this should be under:

EntityComponentSystemSamples\UnityPhysicsExamples\Library\PackageCache\com.unity.physics@0.0.1-preview.1\Unity.Physics.Authoring\Utilities\DebugDisplay

That said, there is also a bug in the Triggers at the minute where all contacts and triggers are not reported. If you can't absolutely can't wait for another package drop...

 

One question I have about the physics system is what the motivation was for storing the PhysicsWorld on the
BuildPhysicsWorld system. It feels like a much more elegant usage would be the a singleton component or some singleton entity that a system can query for in order to do collision calculations. Looking at the whole structure it does seem like the ComponentData limitations would apply, but personally I don't see a problem with having a special case where a system's state actually lives on the enity manager as a special type that can be queried for from a multitude of different systems. One could even go as far as putting limitations on what systems owns the data so as to not make it immutable to other systems. Blizzard mentioned that's the approach they took with the ECS implementation they built for Overwatch and it worked out quite nicely.

 

But that's pretty much all of Unity's customers. Terrain is a big deal in Unity land so I would also submit this as an official feature request.

Unless Unity thinks it's fine doing queries against full meshes for an object with strict highly optimisable limitations (planar terrain with only height queries, possible rejection of some for holes).

I guess it's possible to look into optimising the mesh collision with a bunch of early outs here. We can make a lot of assumptions for unity terrain.

But no, this is not "best left up to the user" because it's a core unity feature that has potential to have a barrage of performance problems (pretty much everything in game touching the same high poly representation?)

 

Thank you for the thoughtful response. I'm of the opinion that physics should not be rewritten to achieve architectural goals unless there is a quantifiable improvement in performance. While there are valuable features under discussion and I by no means wish to minimize them, if an improvement in performance is not obtained I question the value of the endeavor.

 

Yes an optimized terrain collider seems like a good idea. Terrian is basically a grid. Overhanging, terrain is really not needed in most cases.

 

For mesh colliders do they not store the triangles in the BVH?

 

I'm going to have to get better at my phasing I didn't mean that a heightfield isn't on the cards. Terrain support is logged, just not a priority for this preview.
The codebase should be at the state where anyone could add a necessary extension, like a heightfield, without hitting architectural bottlenecks. As an example, often the Unity Physics samples were our own experiments to prove we can build stuff on top of the package, before pushing things into the main package itself. The Joint editors and conversion system is an example of that (they are in the demo scripts currently). So, down the line you can initially expect a heighfield demo as proof of concept, before any ShapeType.DistanceField appears in the core.

 

BuildPhysicsWorld is taking the ECS data and converting it into a format optimized for the lower level Simulation code. There are effectively 3 representations of the Physics data optimized for different levels.

• Editor data (as in the Physics Body and Physics Shape components) is grouped to support easier scene setup.
• The Physics ECS Components like PhysicsMass and PhysicsVelocity focus on manipulation through ComponentSystems
• Then at the lowest level we are only dealing with the Job system. The Bodies, MotionData, MotionVelocities arrays are organised for streaming through the Simulation rather than at the ECS level.

So BuildPhysicsWorld sets up the Simulation from the ECS component data (which is why it holds onto it). ExportPhysicsWorld writes back to the ECS components.
You can create your own Simulations as well, independent of ECS (as in the ImmediateMode pool demo). Actually, I've just repeated this diagram from the blog!

https://blogs.unity3d.com/2019/03/19/announcing-unity-and-havok-physics-for-dots/​

So, if you wanted a procedurally setup Simulation (e.g. ponytails) or a clone just for projecting into the future you could make your own Simulation directly and bypass the ECS components altogether.
As to the singleton idea, its worth consider. And actually there is one already. The PhysicsStep component defines global values like Simulation type and gravity at the minute. Through these sorts of discussions this could well be extended.

 

Sorry my intention isn't to step the simulation, but looking at the examples in the Samples repository the PhysicsWorld property on the BuildPhysicsWorld system is what's used to query for raycasts and collider overlaps. While this works I'm only suggesting that instead of getting access to these queries through the BuildPhysicsWorld it makes more sense to me to have the PhysicsWorld be a singeleton component that can be loaded from the EntityManager. Having system state be consumable like this will mean if the system doesn't run the systems dependent on it's data won't run. You'll also not end up with the coupling between systems when querying system state data from the EntityManager instead of storing it as a public property.

 

I took a closer look at this, and it does not seem like a viable solution. Right now I have a heavily optimized game-specific collision detection algorithm. I cannot afford nor see the benefit to running the full Unity.Physics ECS solution which performs its own broadphase I don't need. I'm going to need something more low level and the API is not polished enough at that level yet.

Being able to completely modularize each piece of a physics step rather than rely on callbacks will make the system much more flexible. Right now I basically have to copy and paste the algorithms I want, and that feels kinda gross.

Just because the internal logic isn't ECS doesn't mean that the API should be allowed to break standard ECS conventions. PhysicsWorld is exposed state with some utility functions. It should live separately from the logic of BuildPhysicsWorld. If PhysicsWorld was internal state not visible from the other systems, than the other systems would only "see" logic in the form of an API likely with some form of "handles" to manipulate individual elements and perform queries without actually being exposed to the internal data structures. Partial exposure requires knowledge of the internals of both the ECS and non-ECS aspects, and that's just unnecessary mental overhead and can lead to ugly coupling problems. Blizzard wasn't the only company that learned that the hard way.