Box2d physics - pixels to meters

[khofez]

Im having a lot of trouble setting up box2d, i mean, i dont get it, do i have to set the meters to each body based on an image pixels or i have to set meters for the entire world ? cause if I set a body with 64 pixels to an image with 64 pixels as well, i can draw a rectangle based on its size (width and height), but if i just create a body with raw numbers ( lets say 100x100 ), it always draw the shape with the wrong coordinates, its really annoying.

[airstruck]

I like to setMeter(1) before doing anything else and then try to forget it ever existed (and use love.graphics.scale instead). Try it, things might work more like you expect.

[raidho36]

The function sets global physics world scale, in X pixels per meter. So if your 64 pixel object is 1 meter large, you feed "64" to that function.

Units don't really matter, you just have to be consistent with them. I.e. you have gravity of 9.8 m/s² and normal scale but it's the same as with 0.98 m/s² and 1/10th scale. Units in physics (the science) in general are extremely arbitrary, the only reason it holds together is because they're used consistently.

Also, I believe your problem with rendering misalignment is that physics object's pivot is in its centre of mass, whereas sprite pivot is by default in top left corner. You can set it manually to different values.

[Beelz]

Also, I believe your problem with rendering misalignment is that physics object's pivot is in its centre of mass, whereas sprite pivot is by default in top left corner. You can set it manually to different values.

When drawing you can offset its pivot:

Code: Select all

offsetX = img:getWidth()/2
offsetY = img:getHeight()/2
love.graphics.draw(image, x, y, rotate, scaleX, scaleY, offsetX, offsetY) --, scissorX, scissorY)
	-- You can also scissor, but not needed to scale so....

[raidho36]

The last two are shearing (skewing) factor, not scissoring. It's an important distinction because there is a specific feature that goes by the name of "scissor test" that clips render area to axis aligned box.

[pgimeno]

Units are arbitrary. First decide what your units are going to be. Then decide the length of one pixel in that unit (or conversely, how many pixels there are in one single length unit). Once you have that, you can start calculating in terms the physics engine understands.

For example, you can choose the length unit to be a metre, the time unit to be a second, and the mass unit to be the kilogram (MKS). You'll need to express all quantities in these units (speed in m/s, force in N, delta time in s, and so on). Then choose how many pixels per metre you want. Say 10 pixels are 1 metre. Then you can start placing pixels on the screen that represent objects with known measures, and getting length values from the engine that you can convert to pixels easily.

It's possible to use a pixel as the length unit instead of a metre, but then you must be careful to express speeds as px/s, force as kg px/s² and so on, and it gets messy.

Also, I'd take airstruck's advice about setMeter, so that the engine works in the range it's optimized for.

[raidho36]

so that the engine works in the range it's optimized for

Care to elaborate? Pretty sure any physics simulation system internally operates with arbitrary units and the only reason to define any kind of scale is for user convenience, as all it does is puts a multiplier to input values.

[slime]

From http://box2d.org/manual.pdf :

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

[raidho36]

That's new to me; I don't use physics in my projects. I see no obvious reasons why it wouldn't be stable on wide variety of scales: "standard issue" double precision float has more than enough exponent bits to calculate data at least on the scale from 1/10¹⁰⁰ to 10¹⁰⁰, as its base magnitude bound is over 10³⁰⁰. Since it's a floating point number, precision loss and numerical instability should be the same for any magnitude, sans subnormals and upper boundary magnitude numbers. The few FEA software that I'm aware of don't even define any units and work with arbitrary inputs, it's up to user to make sense of the numbers.

[pgimeno]

It's well possible that squaring (or cubing or whatever the engine needs to do) certain small numbers causes the result to underflow. On the other hand, I'm not so sure it internally uses doubles.

Anyway, the phrase speaks about hard-coded tolerances. It's well possible that the tolerances it refers to are something like "±5 mm" (0.005 units) rather than ratios.