Official Unity Physics Discussion

I'm actually trying to create a quick networked test that shows server authoritative movement with client-side prediction. Since this physics engine is designed for networking I was wondering how much of this is going to be built-in or if I should start building my own features now.

I am currently concerned about serializing and deserializing the physics world state. I'm not sure what the best practices are to achieve this. I am planning to implement this on my own if it will not be a feature built-in (or if it will take a long time), but I'm not sure exactly where to start. It seems like I should just be able to accomplish this by serializing and deserializing Translation, Rotation, and PhysicsVelocity components. If this is true, at what point in the player loop (or simulation lifecycle?) is the best place to serialize and deserialize?

 

So looking over the samples, I noticed that dynamic bodies that collide with other bodies, seem to have no ability to settle or find an equilibrium. The mass demo in the samples is the best one to demonstrate. If left to play after a few moments the cubes on the left demonstrate motion that eventually breaks down the example. Is this a bug for the current version?

 

Yes it is bugged at the moment.

 

I tested some raycast methods, and found that the direction of Ray in Unity Physics must not be normalized. Does Ray behaves like line segment actually?

 

You are correct, stack instability is a currently a 'feature' not a bug.

• The Havok Physics variant will certainly support stable stacking out of the box, however....
• A major part of the design philosophy of Unity Physics is to provide a simple core, while ensuring open access to the data following through the system. So while at present the stateless nature of the Unity Physics preview doesn't support the likes of stable stacking, welding or deactivation, there should be nothing in the way of users adding and sharing the likes of contact caching themselves.
  The demos under '5. Modify' try to illustrate some of the potential for manipulating the data. For example, 'ModifyNarrowphaseContacts' tweaks contacts normals as an example of welding.

I will log you suggestions though.

 

Two points on this:

1) I get that the point is to have a simple core (and it's really nice codebase atm) but I don't really see why the caching etc couldn't be optional here in the stock package. People who need stateless setup could just disable it, instead it feels like the people with special case get the default here now. Most engine users don't even know physics engine architecture well enough to even begin implementing the improvements they need. Also fairly certain most users would expect the default solution to do the basics already out of the box (and stacking few dynamic objects is still very basic need).

2) Having the Unity Physics on github would let users on expand it easier, having source code only shipped through package manager is one certain way to prevent voluntary collaboration on improving this Technically the Unity Companion License doesn't directly forbid us from putting the code in github ourselves but it's bit in the gray area since it should be Unity who puts the sources there first.

 

Thanks. I think the whole community would benefit immensely from having a built-in option for caching/welding/sleeping in UnityPhysics, because the very very very large majority of projects will need stable stacks and performance much more than they need having simple-to-understand sources or determinism.

I really don't want to sound like I'm not thankful for determinism and modifyable sources, because I really have wanted those things for a long time and I definitely plan on making good use of them, but I think the non-stateless option is still needed for most people. And complexifying the source code is a fair price to pay for this

 

This is important to us as well. We're not doing multiplayer or replays, so determinism is not very interesting. It's completely fine if a block bounces slightly differently on two different CPUs.

What is important is that physics objects come to rest properly, because the alternative is that the game looks bad. Which means that if we go with DOTS, we'll have to create DOTS bindings for PhysX, and that sounds like a major bummer.

Of course, everything here depends on the havok license terms. It's very hard to have an opinion on this when we don't know if the Havok integration is free or costs $100.000 per game.

 

I disagree strongly with "automatic networking" Unity has tried this twice before and it failed. We need the opposite maximum control. Networking has many many different ways in which it can be executed. Each will have its own use case. You may as well ask for an auto game creator.

Each bullet from each client may have a different time stamp. I guess you would just need to rewind back to the oldest and then add each as you reach each time stamp time.

 

"Automatic" networking is not as far-fetched as it sounds. Not if it uses a Quake3/CSGO/Overwatch-esque architecture with automatic full world rollback and resimulation and with only inputs being sent.

None of the popular solutions we've known in the past (UNET, Photon, SpatialOS, UE4 built-in networking, etc...) have used this architecture. But DOTS greatly simplifies the task of making this possible, so I think we should wait and give it a chance. I've been working on an online game framework that uses ECS and the aforementioned architecture, and the results so far show a lot of promise. By following simple rules, I can program my game almost without thinking about how to network it, and it gives me a completely cheat-proof, lag-compensated, delta-compressed online game. (can't share the project, unfortunately. And there's tons of work left to do anyway)

Based on the "Simulation" and "Presentation" worlds that the ECS has, I'm pretty sure this is Unity's plan in the long run. The only downside is that this architecture is CPU-intensive (due to the "8 frames in 16ms problem"), but this is an unavoidable problem if you want quality networking. We haven't yet figured out how to increase the speed of light afterall

---

Side note: I don't think "rewinding" should be a feature of the physics engine itself. It doesn't need to be. You just need a system that collects all the pos/rot/velocities of the rigidbodies, and one that applies them back. You'll need rewinding for everything that contributes to your game's simulation, including your custom game code. It wouldn't make sense to me if the physics engine has its own special rewind mechanic when you'll have to write a rewinder system for the rest of your game anyway. I think it's more coherent to have the same "Rewinder" system take care of everything across the whole project

 

You want people to move to the new DOTS style, which I'm all on-board for. But you're making it a really hard sell if they have to give up features (like stacking) that work well in the old system. There may be some edge cases you can ignore, but this is core stuff and needs to be there.

 

But in the new engine they promise two things which are nowhere to be found.
Determenism(between plaforms) and Rollback.
For other scenarios there are many other solutions...

 

Determinism is coming, it's mainly waiting for Burst update now as Unity Physics has already been prepared for this. Rollback itself isn't quite a physics engine feature (altho the stateless design will make this easier), it's more of a netcode thing in this context.

 

That's exactly my rationale, and Photon Quantum works like this too (which is also ECS based).

 

Well no stacking = not good enough. Simple.

I don't require major stacking. I just need to stack 3 objects high. That could be a bookshelf. It could be a table with a saucer on it and a cup on that.

3 is kind of a magic number and if it cannot do that, it's simply flat out not good enough for me to use as a physics engine. I will maybe find it useful for queries, raycasts, capsule casts and the like.

But 3 boxes high? if it can't do that I don't call it a physics engine. I call it a dynamics engine with queries.

 

Questions haven't been answered about whether there will be a separate 2D version of Unity physics. I am guessing there will be since Tiny has some basic 2D physics stuff, but it would be good to know.

 

Also another bonus to a stateless or near-stateless would be the "free" origin shifting, but only on the assumption that there is no perf impact for static colliders.

I think everyone here will pause at the mention of origin shifting and have a little think.

 

What I want is to separate physics with collision once and for all, when needed ...

Also I want to know if this can support "dynamic building update" like in fortnite

I mean let's give unity some challenges now they seem able to pick them up

 

We've started from the simpliest foundation, ultimately aiming to evolve the engine with the community's feedback and contributions. Hence, no major complexities in this initial preview.
The 3 box high minimum stack size, or Baumgarte Stabilization / Contact caching, or convex decomposition VHACD are all great first impression suggestions. The first few preview iterations will still likely focus on making sure there are no barriers for the community to understand and extend the engine themselves, before adding specific extensions and complexities.

 

Determinism doesn't solve a problem that we don't already have pretty good solutions for. It's not something you would trade much for. It's just too easy to compensate for the differences that players can actually see. And in the end that's what matters the most.

So to trade for things like stability or performance, I don't see how that's a good trade off for the vast majority of use cases.

Even if you solved for those, you still have the paradigm of it just takes one thing that's not deterministic to make it all come crumbling down. Depending on how heavily your core systems rely on determinism. With the nature of games being what they are, an iterative process of discovery, it seems pretty risky to bank on determinism. I know there is just no way I would sleep at night doing so.

 

The length of the Ray.Direction vector is the length of the ray line segment. So the end point would be at Ray.Origin + Ray.Direction. I'll grant you, this is a little confusing.

 

The ConvexCollider.Create function takes in a NativeArray<float3> for the original point cloud. The final convex hull will have a maximum of 252 vertices. The hulls faces are not limited to triangles.

 

Yes, the CollisionWorld can be queried without requiring you to have dynamics at all. You can also create individual colliders (which implement the ICollidable interface) and query them directly without requiring the world either.

 

Determinism is useful for networking, so all you have to do is to send your input to the other clients. Another benefit is small filesizes for game-replay because you only have to store the input rather than serializing the full gamestate.

Deterministic Lockstep is still 'state of the art' when it comes to networking an RTS with thousands of units.

 

I'm fully aware of how that works.

The amount of data sent doesn't really matter until you hit certain thresholds. Ie if your game is handling say 10 players, you won't notice any difference between sending 3 floats for the position vs 3 integers at lesser precision. You won't notice the difference between inputs and an optimized scheme for position/rotation either. You can sync several hundred entities using non deterministic methods before space really starts to become a gameplay issue on PC games. Console/mobile have different thresholds naturally.

My point was determinism doesn't have much value for the common use cases. Not that it has no value, or that there aren't cases where it has a much higher value.

 

Kind of a basic question but is there a reason why a collider's position is based off the Translation and not LocalToWorld? Asking as if you have a system that utilizes CopyTransformFromGameObject you wont have any movement, unless you specifically update the Translation component(which used to be automatic).

 

But determinism in physics is very hard and may save much more than 3 floats. In my case its about 20k floats per tick =)
Determinism helps to make pear to pear games that are protected from cheaters

 

I'm happy for determinism just to reduce code and complexity in my games. This also lowers the barrier of entry for devs who want to make their games networked.

You're right though, for game studios that already have these kind of solutions robustly created it's not really as big of a selling point.

 

I am not quite getting how determinism helps for networking, since local changes go ahead of the user's input arrival to the other players. Consider two players pushing a single cube

 

You'd have to correct that manually the old fashioned way as it's impossible to simulate unknown (what other player did before you actually get the data) deterministically.

 

Wow, you really are missing out on this party then.

Example: https://www.photonengine.com/quantum

Explains better than I ever could.

 

Consider physics, which typically is unpredictable, unless synced. But if can be predicted on any hardware, that means less syncing required over the network. Hence saving bandwidth.

 

Which physics will be default one in Unity ?

 

This makes me feel a bit better. It's good to know it could eventually support stable stacks, contact caching, physics sleeping, etc... I'm already blown away by it's solver quality.

Everything seems to handle impossible situations much, much more elegantly than PhysX. eg: Objects that get mashed by kinematic bodies seem to just find the surface and try to penetrate as little as possible. This is awesome as a VR dev who has to make drawers and containers and such. PhysX would start adding tons of energy to try to find it's way out and cause tons of jittering X<. The new joints are also super stable, even with super long chains and such. It would be nice to see a projection feature at some point for when chains get snagged on stuff and i want it to teleport through whatever it got snagged on. But that can come later.

All in all i'm really liking this new physics and can't wait till it's production ready! =3

 

It depends on what kind of game you make. Determinism may not be a concern for lightweight networking requirement games, but is really a critical issue for multiplayer games with heavily physical simulation. It's hard to say how much value it has comparing to optimization and etc among so many games and developers. At least I have been looking forward to a deterministic physical engine for a long time, and Unity.Physics is really a exciting news to me.

 

Determinism is also useful for single player games and QA testing. Being able to accurately repro problem setups or use replays for testing issues great simplifies checking for regressions and running smoke tests.

Plus it'll be a lot earlier to verify correctness of unit tests for gameplay features.

 

Hi. Sorry hippo I gata rain on your parade a bit here. This kind of networking is often absurdly performance expensive. It requires rolling back and simulating time of the latency. This is extremely expensive, as it will often involve simulating 100-500ms of gameplay in one frame.

This is fine for stuff like RTS's, since it's just a bunch of agents on a navmesh, no physics are involved in the gameplay tick. Most RTS do not use input replication either because it's super easy to cheat. Replicating input for RTS requires a full knowledge of all of the units. Meaning Fog of war cheating is trivial to do. So lockstep state replication is generally used. Where you can send the player only the units they can see. Input rollback is only used generally on servers.

For things like overwatch, it works because they have a max of 10 synced actors in the scene and the scene is mostly static, meaning they usually have less than 16 actors to tick per simulation frame. Which are all generally either on a set path, or are entirely query driven. They can easily resimulate large chunks of gametime to compensate for latency, and even then they still do a ton of lag compensation. Determanism is great, it could save a ton of time and make it far simpler, but it's not a solve for latency. Expecting it to just "Automatically do multiplayer" is naive for the majority of games sadly. =<

Multiplayer isn't a switch. It's a system, it has to be built for your games rules and requirements. Each of which varies wildly between games. Even just the physics part. =<

 

Sorry but you are wrong.

Zero-K

Spoiler

, for example is an 3D RTS. It uses decade years old lua engine (not Unity). And uses deterministic physics for its 3D engine, where each projectile can hit submerged, ground and air units, if on the path. Hence collisions are utilized as well. Not only that. There can play 32 players easily on single map. And all is mainly driven by users inputs, with occasional syncing.

I am talking about possibility of playing with thousands of units on the map, for average gameplay duration of 45 min each.
Also, determinism allows easy replay and track reported cheaters, by giving simply time stamp of the give game play.
Replays are recorders as users inputs. And any can download, and view whole gameplay as spectator, with possibility of rotating camera.

This is example power of determinism.

 

They're using queries... that's not physics sim... Determinism doesn't remove latency. Input rollback is awesome and It provides a really accurate way to validate your mechanics, at a very large perf cost. Yes determinism is awesome but it isn't magic.

On validation: There is no way to check if the player has modified their client to visibility hack: because whatever watch system you have in place can easily be spoofed, or will run the risk of false flagging real players. Yes, you might have a replay of a player who cheated, but how do you then check for that systematically? You also haven't stopped the player from cheating. You have moderated them which is different.

Again, i'm not trashing determinisms usefulness but it's not a magic bullet that lets you have automatic multiplayer. They're great, but far, far from the solution to everything. Some games it will be exactly what you need, many it will not. Hence, automatic multiplayer would be an ill fit for the wide majority of multiplayer games. Not even to start on the performance cost of just doing the floating point determanism itself, which often multiplies the instruction count of most math by several times.

[Edit]
I'm also referencing an earlier hippo post which is here:

 

Spoiler

Top down map, after using super weapon and terrain deformation.

Small units will have issue moving over terrain.

Nope, is not query. Is physics. Altitude and orientation matters. And can obstruct even radars, with hills.

"Simulated unit and projectile physics is used to a level rarely found in a strategy game."
https://zero-k.info/
I know Zero-K (previously spring) game from near decade, if you ask me.

Simple. Players use report functions, if they think someone plays none fair play. Then any player and mods can validate claim, by running game and watch again. That is thanks to using exactly determinism. Chat is recorded as well. And I can assure you, that cheater and abusive actions are not welcome and are punished adequately. With extreme cases perma-bans.

Hence what you claim later regarding determinism and performance, don't add up, comparing to already +10 years old single threaded zero-k.

 

I think you're misunderstanding what i mean by "Physics" I'm talking about using an iterative physics solver, like Unity Physics is and what this thread is supposed to be talking about. Queries are things like raycasts, spherecasts, etc.. These can be used in conjunction with the projectile trajectory formula:
newPosition = position + velocity * deltaTime + gravity * deltaTime ^ 2 * 0.5
to create the effect of bullet trajectories. These only require queries to test if they hit something. Not a physics solver

As for units adapting to the terrain that is most likely just using the A* path they are already calculating (since they need to go where you tell them). Both of these techniques are much cheaper to run than an iterative physics solver. As a result this is pretty standard for most RTS, yes even you ones that advertise as being "Physically simulated" usually are not using a physics solver. Just approximating with other, cheaper bespoke solutions.

This was how "physics" was for years. Queries, clever animations, making the right assumptions, etc... This is still how RTS work, due to the scale they operate at. Old stuff had to fake it. And often it was advertised as "Physics" because it was about creating the gameplay. I'm talking about a physics solver, which is a specific solution to general physics sim.

I've worked with determanism and yes, input rollback is much simpler than most replication strategies but it is just that a replication strategy. It's tradeoff is resimulating frames. This is how it works, i don't know what you expect to change by saying it's a game from 10 years ago. It doesn't suddenly make input rollback replication(which is what determinism enables) a viable one button multiplayer solution. It's cool, but it's not for everything.

Anyway, i'm done discussing this, it doesn't feel very constructive to keep repeating myself. Have a good day and i hope your projects go well. =3

 

Thanks for highlighting this. Physics really wants to have translation and rotation (and uniform scale) rather than decomposing a float4x4 for every body, every frame. We'll look into this pattern.

 

I don't exactly understand what a "stateless" physics simulation means and why it would prevent implementing certain things like stacking.

Does stateless simply mean that none of the physics systems track any personal state inside themselves or does that include not using any entities/component data either?

I thought the implementation of a rollback would essentially be to revert the ECS world and its component data to some previously saved version. If this is the case then why can we not store physics state inside the entities/components themselves so that this could all be rolled back at the same time?

I didn't think we would have all this so quickly, thanks for the incredible work on the systems so far.

 

Stateless means it only storing one frames data to compute the next frame. So no long term caching, histories, etc... It would be more accurate to call it single state physics, but hey, physics engineers have never really been good at naming things ;3

 

Does it have air physics?

Like in this game

https://www.reddit.com/r/Unity3D/comments/b254rh/air_resistance_physics_im_working_on_in_unity/

 

That's something you'd usually build on top of the actual physics engine.

 

It, sort of, does. Take a look into PhysicsDamping. You may alter this component's values based on the body's orientation. It's also noticed here with some code sample.

Edit:
On the other hand, it's not y-axis damping, so it may require some more coding on your end, than you would expect

 

This is just same as old Unity physics "drag", they just this time called it with the right name. It never was really a drag if you think what people think drag would mean in physics. Linear damping is basically just linearVelocity *= (1 - linearDamping). When people model air (or any fluid) drag, they usually use this: https://en.wikipedia.org/wiki/Drag_equation. You can implement this on top of any physics engine, most vehicle simulations do this for air drag for example.

 

Yeah it's been a drag for so long...

 

I wanted to also add that it might be useful to be able to do three things:

• (internally) "automatically close holes" in the input mesh via a checkbox option
  
• for extremely thin meshes (like flat planes), an input box for a "min/max thickness", and an option to stick to front or back of faces / normals upon decomposition
  
• reposition/tweak/insert/delete individual hulls/verts as well (in the case of something like, say, terrain (like in the video below), where you want the player to be able to grab a rectangular box-shaped ledge while otherwise keeping the same or similar surface topology as the generated collision decomposition).

Here's an example of a slightly bad (but simple) v-hacd implementation -- this problem would be common for me (as I rarely work with closed meshes for terrain):

This is a faster / better job (with backside filled-in / closed manually in modeling program -- I'd prefer Unity do this "closing" automatically though, as long as I click a togglebox to tell it I want it to. )