Any plans for physics support on the Job System?

My game logic is many based of decisions that depend on the result of some ray casting, but at this point you can only cast rays form the main thread, so I was wondering if there are any plans to support physics. In my case I won't be able to take advantage of the job system unless it supports Physics and Rigidbody.

 

I too am very interested in this

 

RaycastCommand has been a thing for a while. And in some cases that's all you need. I'm using it to drive projectiles and collision detection, ai movement, all sorts of stuff without even using rigidbodies in most cases.

 

Yes that has been in for a while, but it does not solve the actual question of whether rigidbodies are going to be integrated in some way or not.

How would you do say a rock that splits into smaller rocks when crushed, all of which scatter and collide with floor and each other? Because such a performance scenario is perfect use case for rigidbodies, but also for c# jobs and ECS if you want performance. For any physics interactions other than very basic things, the raycast command will not be sufficient and will require a lot of work added on top of it to provide decent physics.

 

Currently I use a ton of rigidbodies which I assign velocity for but not much else, each frame. I don't believe the assignment being single threaded is really that much bother, so my code remains, by far, the slowest part of this. I'm talking hundreds of character controllers here. This is because the rest of physx is threaded. So a few hundred Vector3 assignments in single thread is not going to slow any cpu down or make much difference since the heavy stuff is still threaded.

Just food for thought - is this actually your bottleneck?

In any case I heard that Unity do plan a lot more BUT after they finish upgrading Physx @yant

 

I don't think this is a viable solution at least in my case, to be efficient I need to know the result of a raycast before casting another ray, calling handle.Complete() just after scheduling a single raycast doesn't sound like a very efficient way of doing things. I need way to encapsulate all my raycasts synchronously on a single job, so I can schedule that job though IJobParallelFor. Additionally I'm also overlapping boxes and doing some sphere casting so clearly RaycastCommand is not enough, a full support for the whole Physics class is necessary.

 

You don't need to do that, you can just do a bunch up front then more in lateupdate, that's more than enough time for a round of threading to do some pretty decent work. Complete is a a bit of a train wreck used early.

I try to see the job as a train. It'll go fast with lots of carriages, stop at a station, do the passenger change and then go fast again. That's perfectly OK and likely still much faster...

 

Thats a really nice analogy!

Also @hippocoder i guess what I am trying to say is when trying to utilize ECS and Job system to make many 1000 of agents (rts style game is the test project we are using to learn this stuff), we are trying to use instancing etc as much as possible. So simple animations are gpu instanced using baked textures, shader has instanced properties etc etc.

The only part so far that is mostly stopping us from utilizing all that goodness from start to finish is the rigidbodies, they remain an aside from both systems. Being able to fully engage with ECS I feel would really benefit this use case.

And yes, I know its beta and I am not saying "hey devs why is this not done", as I know you will have thought of it already, just wondering if there's any news on this, and failing that, any discussion to be had on ways around this.

I did know that physx is threaded underneath but it seems that it is still a performance bottleneck at amounts over 4-500 rigidbodies (an insane amount of moving bodies, I know). Perhaps ultimately I am just expecting too much! But I was thinking that about the gpu instanced animations about a month ago and then BANG the instanced animation repo was released, so now I have high hopes for a more performant version of rigidbody.

Or alternatively, some kind of helper class that can be used from ECS style or job systems to determine collisions for multiple types (sphere vs sphere, cube vs sphere, plane vs sphere, plane vs plane, line vs plane, blah vs blah etc etc). Even if this required us to then actually implement the collision (move bodies back to collided position, then add forces relative to the collision etc)

I also feel like further down the line ECS and job system might be a good way to compute mesh collider < > mesh collider collision in a decent way for once, but again thats punching way above my belt!

 

Waiting on physx upgrade. That's what Unity staff told me. That they would want to ensure that all works well, then add features over time. I suspect they have quite a few plans here

 

I understand maybe I need to change my mindset, after all this is new stuff... however there's a catch: "Determinism". As far as I have tested, it is not crucial to do all your physics updates on the FixedUpdate method, a game runs just fine regardless if you do the physics stuff on FixedUpdate, Update, LateUpdate or even in a coroutine, however if you are aiming for multiplayer or film making you need a fully deterministic simulation, and the only way to get it (as far I as I have tested), is by doing all the physics on FixedUpdate, so LateUpdate is a viable option only if your game doesn't need to be fully deterministic.

 

I'm curious why you even need rigidbodies in an RTS? You don't need rigidbodies for raycasting FYI. And if you are using pathfinding then I'm wondering what it is you need rigidbodies for.

I have up to a max of 500 controllers in a scene. It's pathfinding based and I do a crapload of projectile hit detection without any rigidbodies.

But even with rigidbodies it shouldn't be an issue. It should be other stuff you are doing that is a bottleneck, like lots of the more expensive overlap calls or something similar.

 

Im not sure why you seem to think using pathfinding does not mean I need rigidbodies?

Perhaps in your example you are never allowing collisions due to flocking pathfinding.

Also yes it is an RTS, but even if it wasnt why would you assume to know its featureset enough to say "you wont need X"? We absolutely do need rigidbodies as we have many accurate real time collisions and real time destruction.

And yes I know you don't need rigidbodies to "raycast FYI", I have used Unity since 2010 and use it professionally for my job so I am aware of how to profile an app, and all I can say is it is 100% the rigidbodies that are the bottleneck here. I am not sure why you would think rigidbodies have anything to do with raycasting, I didnt say anything that related the two together other than saying job based raycast via raycastcommand is not sufficient.

If you are saying you have 500 controllers in your scene, you are not at all at the same use case as us. We have thousands of units on screen, all actively pathfinding and colliding, while there is a ton of other stuff going on such as mesh generation etc.

We have managed to greatly speed this up using compute penetration, but ultimately we need for rigidbodies to do a lot of the complex collisions we do (ones that we cannot prerecord with gameobject recorder) and as such, we need a more performant version.

Again its probably best to iterate that these are the bottleneck, in no way are they "bad performance". Rigidbodies are very well optimised for a mono style component, but not enough for usage in ECS land at scale. Which leads back to the question of what will happen about this, which @hippocoder answered already.

Thanks for your reply however, it is appreciated.

 

I never said you won't need X. I said I don't see how you would and I asked what are you doing.

WHich is a perfectly valid question in light of the fact that most rts games don't use your approach, it's generally considered too heavy.

 

Approach to what though? It still sounds like you think rigidbodies and pathfinding are in some way linked?

My usage of rigidbodies has nothing to do with anything but collisions in my game, (like a boulder flying through a destructible house).

I would like to know how these "most rts" games that have realistic real time collisions and destruction do such if not using collisions?

So I am very interested to know if you have any specific examples of games that have given post mortems to confirm they are doing this via another method, it would greatly help our research into the problem! If what you mean is "they dont use rigidbodies for standing on the ground", then yes I know, and neither are we

EDIT: think back to games like black & white where you could throw rocks into cities, but on modern day scale in terms of scope

 

Here's the latest news for physics in Unity. They are working on PhysX 3.4 upgrade, making the whole Physics.* namespace jobifiable, and supporting multiple simulation worlds. Seems like there's good chances we'll start seeing these things in 2018.3

https://forum.unity.com/threads/spherecastcommand.523540/#post-3438844

https://forum.unity.com/threads/cas...-dont-return-any-results.527651/#post-3468815

https://forum.unity.com/threads/calling-the-physics-simulation-from-c.444659/page-3#post-3422818

https://forum.unity.com/threads/calling-the-physics-simulation-from-c.444659/page-3#post-3478741

 

This is fantastic phil, thanks so so much

Very detailed response, again thanks for taking the time for this!

 

You won't find postmortems on rts games generally. They are one of the most complex games you can make and there are still trade secrets in that genre.

But information gets out and just observation tells you a lot. Modern rts games generally use less bandwidth then the average mmo, while at the same time managing thousands of actions per second. This almost requires a deterministic approach where what is sent over the network is just the commands.

Ask yourself how can an rts that moves thousands of units have a replay file that is so small and contains no unit positions or anything related to specific collisions.

I'm not an expert on rts games so undoubtedly they have techniques I'm not aware of. But google combined with deduction and maybe a bit of reverse engineering (especially at the network level) tells you at the very least what they are not doing. And that then points you in the right direction for what they most likely are doing.

A lot of the techniques they use I think are well known. For example projectiles you don't need physics in most cases. Even outside of rts games a lot of the time you just calculate curves and project where it will hit using fairly simple math.

Movement in rts games is where it gets complex. Making that deterministic on every client. I know in the past one approach I've used for that is seeded random numbers. That let's you generate numbers that are predictable. I've also gleaned that rts games prefer to avoid floating point math in a lot of places. Which makes a lot of sense. You can still have floating point numbers but you need to use integers where it could make things get out of sync over time.

 

I feel like one thing that would greatly help make unit movements deterministic in an rts would be to make everything based on a grid. That way, instead of positions being float Vector3s, they would be just two uints representing coordinates on a map. It would make positions and pathfinding easily determinstic-able. And with uints, the grid could be so high-res that no one would notice there's a grid at all. You could make it up to 4 billion X 4 billion

 

That's probably what most of the large scale rts's do. I would think they would be using some variation of flow fields along with that, or something other then traditional A* navigation which wouldn't scale very well I don't think.

 

Say for instance I am not adding any networking into the game, would you still think its as important for movement etc to be deterministic?
Because the only reason we have not gone for grid based movement or an octree based position storage or something similar is because we are not doing networking and currently don't care about determinism, we don't need to replicate the same things across two pcs.