Faking the physics

Ok so just a thought... if you are making a 2D game and you don't necessarily need your objects to rotate, but you want collisions, and maybe even inertia and gravity, and maybe even for objects to bounce off each other when they collide at their sides or above/below, you can do this much more efficiently by faking the physics. I understand Unity has provided a full physics simulation, based on the laws of physics, which requires quite a lot of calculations, and makes things easier because you can just set things up and let the system handle it, but really this can be a gross overkill for simple 2D games.

If you just need simple collisions, you can get far more objects colliding and reacting by writing some basic rectangle or circle collision code yourself. Then to speed it up, throw in something like a grid so that you only need to compare nearby neighbors. I know the physics engines do this kind of stuff too but they are designed to be general purpose, at the expense of much more calculations needed in simpler cases. Even on a 5-10 year old computer you can fake the physics for 10,000+ objects at 60fps. According to a recent Unity Learn post, Box2D maxes out at around 2000 objects at 30fps, on a fast quad-core i7 CPU! This is so `slow`. So if you're concerned about performance and you don't need the fanciness of realistic rotations and things colliding at odd angles, then I highly recommend rolling your own collision code. On a modern computer you should be getting 100,000+ colliding objects at smooth framerates, not 2000. It's one of those cases where as soon as more cpu horsepower comes along, everything becomes abstracted, generalized, and lazy.

I say this mainly because I think a lot of people enjoy using the built-in physics and how easy it is to just use it and forget about it, but when you look at the work it's doing in simpler 2D games it's such a gross overkill. You don't need to be running a realistic physics simulation just to move objects around or detect collisions. You only really need it when you must have realistic collision response animation. There is especially a case for faking the physics on mobile games if the situation works for you.

 

Sure, if you're just doing simple non rotated velocity and rectangle collisions, then its trivial to roll your own simple physics. What is the point you're trying to make? If you want to have shapes or perform physics with rotated rectangles then it becomes much more intensive computationally.

In our current game, I've rewritten the physics 4 times:

- initially (and this was fastest) I needed just 16x16 shapes, or 32x32 - simple with physics and collisions against a tilemap. This was very fast an even had sliding collision support across neighbor tiles.

- But then I needed to support shapes which weren't neatly fitting into a multiple of 16x16. So I wrote support for that.

- Then the game needed rotation factored in. I also needed robust raycasting, so I dumped my simple and fast physics in favour of box2D. This was great.

- finally we added depth to the game, so I had to rewrite it from raycast based player physics, to use Physx. All for essentially, a 2.5D game.

Therefore there is much reason to use built in physics, if only to save on development time. That's not lazy when you're an indie developing for years. Try making a game, you'll see how long you'll be tied up just doing a physics engine

 

I guess so, saving development time and offloading that savings into extra cpu resources at runtime is one way to go. And if you need the features, sure use the built in box2d. I guess my point is just that if you don't need to use that and you have time do throw some code together, faking the physics can be a huge savings on performance.

 

I agree, but that's not really faking physics - it is physics All game physics are just approximations, from simple inertia to complex joints.

Faking physics is when you bake the response or result to an array or animation.

 

Played with this over the weekend and had 10k planets floating around with good framerates https://www.assetstore.unity3d.com/en/#!/content/13241

 

Unity 5's physx 3.x is hard to beat though. It's also extensively multi threaded - something 4x doesn't have.

 

Ok so you're saying its not faked physics because all physics is fake. Ok, semantics. Faked physics is when you try to make it look like physics without doing `laws of physics` type of calculations.

 

Are Box2D physics going to get a multithreading boost in Unity 5 or is it already maxed out?

 

I don't think it's semantics. A physical reaction in code is pretty much spot on what real physics are like for the simplified velocity, drag etc these are all part of a hand written one. Since what matters is what you plug in. I mean, you're calling it semantics but I'm calling it still physics, with a simpler set of laws.

 

if i want to make a space-invader style game, i just make check the distance between each objects. If i want more than that, i will just use unity physics system.

 

Game physics packages are designed to look good and have high performance, realism isn't actually a high priority. Realistic physics (which, as Hippo says, is still just an approximation) takes into account all sorts of stuff that game/real time physics packages ignore, and are typically found only in dedicated physics solver software and/or CAD packages.

Even stuff like PhysX, Havok, etc. are routinely used to do deliberately non-realistic stuff. That's what I'd call "fake". The rest is just "physics" to a varying degree of fidelity.

 

I would certainly like to know how to make my own controller with my own physics, but the truth is there's some voodoo at work to make my own physics that I simply do not know how or what to do.

 

...the wheel is right there, already invented.

 

Yah you might as well use the built-in highly optimized if you want it to be 'realistic'.

 

I'm not sure if there is sarcasm there or what's going on

 

"in simpler 2D games it's such a gross overkill" - @imaginaryhuman

On the other hand writing your own system is also an overkill on the effort side.

In a simple 2D game its pretty rare you have more than 50 or so objects interacting, and its probably more like 5-10. Most of the time everything will be sleeping. In this context Box2D works without any noticeable performance impact. So unless you do have very specific/complex physics requirements why bother rolling your own?

 

Yes of course you have a point, because some types of games just don't call for really basic movement logic. It's easy to just do the physics, let it gobble up performance and forget about it. Thats part of the beauty of Unity.

I guess what I was thinking when I wrote this post was that I'm working on a shootemup which DOES have a lot of individually colliding objects, and the physics is just way too slow so I'm having to resort to doing my own movements and collisions. Yes it does take some extra effort but it is not hard, and in this case the performance is definitely worth it.

 

Unwatching this thread...

 

Tota

Totally no value in me saying this, but hurray for shoot-em ups! You have a demo?

 

You seem overly fixated on performance for this. What practical performance impact do you think it's having on your game?

It's going to vary from game to game, and some stuff does need custom handling for specific use cases, but for the use cases it's designed for the built in physics is great. I certainly wouldn't rewrite standard collisions, rigidbodies or character controllers for "performance". On the other hand I would (and have) made my own where the current ones don't suit my functional requirements.

 

You have a shoot-em-up game with several thousand objects colliding and none of them are rotating? I'm struggling to imagine it.

But it could have it's uses for sure. Maybe an asset for the store?

 

For a shoot-em-up sphere-sphere collision is often all you need. Stuff can rotate, but it makes no difference to the calculations. I too have done it this way in the past.

Also, if they're all sprites and rotation is built into the image, you'd first do box collision then check a pixel mask. Again, rotation makes no difference (and isn't represented in the transform).

 

There's a problem in Unity 4 where if you put a collider on something but not a rigidbody, it causes poor performance. You can fix it by adding a rigidbody and setting it to "Kinematic" so that it essentially does nothing. That might be what you're running into. They fixed this in Unity 5.

 

Basically my shootemup spans multiple screens and moves all objects on all screens all of the time, including collisions, and there are like 7 screens possibly filled with tonnes of small objects including special effects and stuff, so using the physics engine is out of the question, it's just too slow even on a faster computer, and especially way too slow on mobile.

I also have this other game I started on which has an environment that includes lots of moving parts and rollers, with various objects moving around it automatically, and the framerate just sucked because it's too much physics. Converting all the movements and collisions to custom code saw a massive speedup. It really depends on the game and what it needs to do.

 

What kind of object count did you have in those, with what kind of interactions? "Lots of screens" doesn't really tell us anything useful about the characteristics.

In any case, it does sound like you had a potential case for custom solutions.

 

Interesting topic. I'm faking vehicle physics using splines for far away vehicles. The behavior doesn't yet look realistic, but I'm able to have more vehicles on camera since there are no wheel colliders or waypoint processing involved.

 

I would have assume that the physics would naturally optimise for a 2D game, or at least have some kind of binary switch for that.

I know a lot of math is simpler and faster when you only have to work with 2D vectors. There's only one axis of rotation, rather than three, for instance.

if unity isn't optimising that quite heavily, then maybe it's UTs problem, rather than individual developers'

 

Unity's box 2d is an `optimization` of physics versus the PhysX 3d physics, if that's what you mean.

 

Glad to see other people rolling their own. Was starting to think I was the only person because I never saw anyone else say anything about it. For me it is just a matter of game physics are simple stuff. I don't need something running NASA level algorithms (ok probably an exaggeration but you get what I mean) to make a good game. And I have a lot more control over the physics this way. I just see it as overkill the same as the Animator. It's cool you're seeing performance improvements. Just further reinforces my view of it being overkill.

 

Let's not forget there is still much optimisation you can do such as not having everything collide with everything else, with good use of layers. This is one of the more important optimisations to do.

 

Yes thats good to know, about the layers. I used to not realize that and left everything at its default. lol

I roll my own where it may make sense, because I'm old-school, heh.

 

Me too. For bullets and stuff I just do my own physics on them.

 

I am working on a game for a client where we have 3000 active rigid-bodies in a small scene. We had to do some optimization But that was more with enabling / disabling the items in queues and areas based on the game state and each rigid-bodies velocity.

 

For our game gunjitsu we do the same. Own physics with raycasting and timing stuff, but thats more to do with PhysX not being deterministic and controlling bullets locally in a multiplayer game.

 

Ha ha. yep same here.