# Unit conversion for physics

I'm doing the physics for a 2D game which visuals are represented in openGl. Gravity is 9,8 m/s^2, how do i convert that to my screen size? OpenGl sets width to -1 to 1, and does aspect ratio of the screens real width and height to get height's size(normaly from -3 to 3, due is a smartphone game).

I know i have to convert meters to my screen size units, but what are those units and how do I convert meters to them? For example, lets say I want my screen to represent 20 meters, what are the maths?

9,8 m/s^2 * x screenUnits/m = y screenUnits/s^2

Those screen units are pixels? It doesn't make much sense cos OpenGl scales from -1 to 1 independend of the amount of pixels represented by that size. I want this to work the same on various smartphones.

Physics vs Rendering

Since OpenGL uses floating point math, it is perhaps a good guideline to use a scale of 1 world-space unit = 1 metre. Then floating point fractions of a unit are fractions of a metre.

(For 3D, you'd then set your clipping distance and z-buffer depth accordingly.)

In truth, your rendering scale is subject to your physics scale, not vice versa. Ignoring any physics aside from free-floating camera speed, you could use 1 world-space unit = 100m if you liked, and set your clipping distances and z-buffer accordingly: provided your free camera velocity was set accordingly, it would look exactly the same as the 1:1 scale mentioned above.

...So it is actually your physics scale that dictates how things really look / feel in your world. Different physics engines (whether custom or pre-packaged) work within certain tolerances, and you would scale your rendering to match. For instance, by default Box2D (which I guess you may be using due to your question tags) operates well in the tenth-of-a-meter-to-one-hundred-meters range, roughly, in terms of area; masses operate to different tolerances. Going outside these tolerances will make the physics somewhat faulty, increasingly so the further out of that range you go.

I suggest googling "box2D physics scale" to see this being discussed more; even if you work with another physics engine, I think this will help you grasp the concept better.

Pixels vs Normalized Device Coordinates

Ignore pixels altogether. OpenGL operates within NDC and that is all you should need to worry about. Your transform math (implicit in fixed pipeline, explicit in programmable pipeline i.e. shader-based code) handles the rest. You say you want it to work the same on all smartphones, well, using NDC, it will simply scale things according to each phone's screen size. If you OTOH want users with large screens to benefit from a larger play area, then you need to retrieve that phone's resolution from the OS, and use it to scale accordingly, since OpenGL has no concept of pixel resolutions.

• Gave you the tick, changing the scale of world space solved all my problems. Now everything is more manageable and clear than working with -1 to 1 range. Thanks! Dec 7, 2013 at 12:14