This is sort of a general and specific question… How important is setting realistic scale with Unity’s 2D physics implementation?
I’ve read the Box2D documentation and googled excessively on the topic and the data I’ve found is helpful but not necessarily definitive and sometimes contradictory (shocking I know! :)). The most specific recommendation I’ve found is that Erin Catto suggests that when using Box2D objects should be between .1 and 10 meters for the most realistic simulation.
We’re creating a top down 2D space game with ships ranging in size form a fighter jet to a large battleship or cargo ship. It’s a mobile game and gameplay is heavily physics oriented. Think Angry Birds, Pool, etc. but with spaceships. Currently I’m using scale and mass in a somewhat arbitrary manner. I’ve been tweaking those values manually to get the right feel even if it’s not “accurate”. For example, the asteroid is moving too much so increase mass or drag til it feels right. The fighter ships is bouncing and spinning too much so do similar adjustments and maybe tweak the physics material, etc. You get the idea.
So the specific part of my question is… how much should I strive for realistic scale? Or is it a case of if it feels good and works good then it is good and don’t worry about being “correct”? I guess I’m asking if there are any potentially negative repercussions of creating this hodge-podge of values.
Any and all thoughts are welcome and I’d especially love to hear your take on this @MelvMay since you implemented the 2D physics. And as a side note, I’ve been using your physics implementations since the days of Torque2D!
Thanks in advance for any thoughts/suggestions no matter how anecdotal.
The reason it’s not definitive is because neither is physics stability or more to the point, instability. If you scale everything up too much then so will the forces. This introduces huge forces and any simulation errors are also huge. If you use joints then those too need to produce huge forces. In the end, a simulation isn’t real and has to be “tuned” to give best results for a certain CPU overhead at a certain scale. That’s not to say you can’t make things large and do certain things but it’s saying (vaguely) that it can introduce various instabilities.
That’s why Box2D states it uses MKS and is designed to simulation “typical” game-scale things i.e. people/limbs, balls, missles/projectiles and not mountains, planets etc.
Of course Metres could be light-years or Seconds could be years in your simulation by just changing their meaning but it’d prefer stuff less 100 meters but in your sim that could be 100 lightyears. The thing is, you’re not then going to be able to simulation things at all scales i.e. lightyear scales and football scales.
So in short, a lot of this comes down to the scale of the impulses the solver has to work with resolving contacts but to a lesser degree also the accuracy of floating-point at huge scales.
Ok, super helpful. So it sounds like I don’t necessarily need to strive for realistic scale, but rather keep the scale within the optimal working range of the physics engine? That makes things a lot easier. I just wanted to be sure I was making some systemically bad choices by tuning mass and scale ad hoc.
So far my approach has resulted in the type of gameplay and results I expected but just wanted to do a sanity check to make sure I wasn’t missing something that might cause issues that reveal themselves over time. Thanks much
Pretty much but to be honest, it really depends on what the simulation is doing. If it’s a huge stack of boxes, each with the mass of a mountain with various joints (etc) then it’s not going to be easy to make stable. If however it’s nothing as as complex as that with a handful of bodies occasionally interacting then it’ll make no/little difference.
I’d play it safe and go with fairly balanced scales based upon real life. At least then it’s more intuitive when you get odd results and look at the masses and see you accidentally had 1 gram hit 1000 kilogram and it reacted badly.
Thanks much for the clarification. In my case there are no joints or stacked entities and also no gravity. It’s much closer to a billiards simulation in terms of the type/frequency of collisions. The only other notable element is the application of force to launch entities into each other and so far that seems to be performing as I would expect. I was seeing some major framerate hitches at the moment that objects collided at high speed but once I simplified the colliders to either primitives or polygonal colliders with less than 10-15 vertexes that’s completely went away.
