Damn it. Love.physics was created with pixel-units in mind.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.
Box2D Note
Box2D Note
I just discovered this, in the Box2D Python manual:
Re: Box2D Note
Ouch. How can games have MKS? I find this intriguing without some sort of coded length system, which would be pointless, no?
Lovely quotes
somewhere within the jungle of administrative doom - rude
somewhere within the jungle of administrative doom - rude
Re: Box2D Note
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) ...
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) ...
Re: Box2D Note
I don't see the problem?
Lovely quotes
somewhere within the jungle of administrative doom - rude
somewhere within the jungle of administrative doom - rude
- nightvenom
- Prole
- Posts: 36
- Joined: Sat Aug 16, 2008 3:07 pm
Re: Box2D Note
Does this pose a problem to a side scroller ?
Re: Box2D Note
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.
I guess we'll have to provide a way to set the viewport in the next version, though.
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.
Probably not.nightvenom wrote:Does this pose a problem to a side scroller ?
I guess we'll have to provide a way to set the viewport in the next version, though.
Re: Box2D Note
Does this only affect stuff when you use "setMassFromShapes( )"? Couldn't you manually set the mass of objects to work correctly?
Re: Box2D Note
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.
Re: Box2D Note
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.
But, if we want to keep our precious pixel units, I suppose that would be the way to go.
Re: Box2D Note
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.
Who is online
Users browsing this forum: Bing [Bot] and 5 guests