LÖVE

Posted: **Fri Oct 17, 2008 2:48 pm**

I just discovered this, in the Box2D Python manual:

Box2D works with floating point numbers, so some tolerances have to be used to make Box2D perform well. These tolerance have been tuned to work well with meters-kilogram-second (MKS) units. In particular, Box2D has been tuned to work well with moving objects between 0.1 and 10 meters. So this means objects between soup cans and buses in size should work well.

Being a 2D physics engine it is tempting to use pixels as your units. Unfortunately this will lead to a poor simulation and possibly weird behavior. An object of length 200 pixels would be seen by Box2D as the size of a 45 story building. Imagine trying to simulate the movement of a high-rise building with an engine that is tuned to simulate ragdolls and barrels. It isn't pretty.

*** Caution ***

Box2D is tuned for MKS units. Keep the size of moving objects roughly between 0.1 and 10 meters. You'll need to use some scaling system when you render your environment and actors. The Box2D examples do this by using an OpenGL viewport transform.

Damn it. Love.physics was created with pixel-units in mind.

Posted: **Fri Oct 17, 2008 3:50 pm**

Ouch. How can games have MKS? I find this intriguing without some sort of coded length system, which would be pointless, no?

Posted: **Fri Oct 17, 2008 4:19 pm**

MKS makes sense in a 3D game, but we want pixels in 2D.

So ... any suggestions as to how we should deal with this? Add viewport transformations? A potential problem would then be to maintain pixel-perfection (visually) ...

Posted: **Fri Oct 17, 2008 4:57 pm**

I don't see the problem?

Posted: **Fri Oct 17, 2008 5:06 pm**

Does this pose a problem to a side scroller ?

Posted: **Fri Oct 17, 2008 5:18 pm**

The problem is that, according to Erin Catto, Box2D does not really handle well with moving object bigger than 10 units (although I've never noticed any problems). I normally use pixel-units, which means that I rarely use anything under 30-50 pixels(/units).

It may not matter that much though. The simulation may be a little inaccurate and not "correct", but that's probably not significant for most games.

nightvenom wrote:Does this pose a problem to a side scroller ?

Probably not.

I guess we'll have to provide a way to set the viewport in the next version, though.

Posted: **Sat Oct 18, 2008 12:49 am**

Does this only affect stuff when you use "setMassFromShapes( )"? Couldn't you manually set the mass of objects to work correctly?

Posted: **Sat Oct 18, 2008 11:55 pm**

I haven't used Love.physics yet, so excuse if this doesn't make sense, but would it be possible for the physics interface to simply scale all pixel units it is passed by a certain amount? That scaling factor could also be set by the user, if he needs to.

Posted: **Sun Oct 19, 2008 12:17 pm**

Of course that's possible, but it would involve one multiplication for each ingoing and outgoing numeric value.

But, if we want to keep our precious pixel units, I suppose that would be the way to go.

Posted: **Sun Oct 19, 2008 6:02 pm**

Floating point multiplications are dirt cheap on modern CPUs though; even a Lua function call has more overhead probably. So performance would hardly be an issue. One would just have to go through all relevant API functions and apply this scaling everywhere, which would be a slight annoyance, I assume.

LÖVE

Box2D Note

Box2D Note

Re: Box2D Note

Re: Box2D Note

Re: Box2D Note

Re: Box2D Note

Re: Box2D Note

Re: Box2D Note

Re: Box2D Note

Re: Box2D Note

Re: Box2D Note