Hey everyone,
I recently got interested in physics games and would like to create a small project using box2d. I have everything set up ready to go but I don't understand the conversion ratio from pixels to meters. How would I do this? Another thing that has been confusing me is which coordinate system I should be thinking in if box2d uses the Cartesian system and SDL uses the top left as 0,0 (don't know what the name for this system is). Normally I would program in terms of pixels. With this being said, if I have a sprite at location 100,100 in SDL terms, how does this translate to Box2D coordinates? Wouldn't I need to be keeping track of two coordinate systems? (If so, this is gonna drive me nuts). Hopefully you guys understand what I'm having trouble understanding. I've been looking for a good article on google all day but nothing has really helped make this click for me.
Language: C++
Drawing API: SDL
Thanks
Box2D: Understanding the conversion to pixels
It is my understanding that Box2D is optimized for an acceleration of 10m/s[sup]2[/sup]. You chose a scaling factor that works for the dimensions of your game. And should be sizably larger than 1 because that will cause objects resting on one another to have a visible jitter.
Personally I've found this conversion to be a pain in the butt as well as the Box2D collision handling API. I chose to use chipmunk instead. Though some argue that Box2D is smoother, I haven't found any real difference because it all depends on the number of sub iteration steps you choose. Of which there is no such animal as a conversion ratio to from meters to pixels. Pixels is the internal unit for Chipmunk.
But there is one valid reason to use Box2D instead of Chipmunk and that is continuous collision detection. If in a time step Box2D detects two objects went through each other if one body is defined as bullet, then Box2D will backtrack to the point prior to the objects passing through each other and redo the collision detection from that point.
The other thing I don't like about Box2D is the way bodies can snag on a path of segment shapes. There is a special type of joint to use to avoid this and I forget its name.
Here is a link I think may help.
Personally I've found this conversion to be a pain in the butt as well as the Box2D collision handling API. I chose to use chipmunk instead. Though some argue that Box2D is smoother, I haven't found any real difference because it all depends on the number of sub iteration steps you choose. Of which there is no such animal as a conversion ratio to from meters to pixels. Pixels is the internal unit for Chipmunk.
But there is one valid reason to use Box2D instead of Chipmunk and that is continuous collision detection. If in a time step Box2D detects two objects went through each other if one body is defined as bullet, then Box2D will backtrack to the point prior to the objects passing through each other and redo the collision detection from that point.
The other thing I don't like about Box2D is the way bodies can snag on a path of segment shapes. There is a special type of joint to use to avoid this and I forget its name.
Here is a link I think may help.
Author
I would still need to be thinking with two coordinate systems though wouldn't I? Or would I only need to think in one and by doing the conversion I would have the other coordinate system?
The author from the link you gave me says he programmed the demos using the box2d coordinate system then scaled the viewport to be the normal screen space. Looking up the function he uses for the scaling, it looks like it sets the top left to be the edge of the "world", which I guess would make the world coordinate system correspond to the normal screen space. Eh it's still confusing me....I'm going to take a look at the samples again, maybe there's something I overlooked in there that will help me understand this better.
The author from the link you gave me says he programmed the demos using the box2d coordinate system then scaled the viewport to be the normal screen space. Looking up the function he uses for the scaling, it looks like it sets the top left to be the edge of the "world", which I guess would make the world coordinate system correspond to the normal screen space. Eh it's still confusing me....I'm going to take a look at the samples again, maybe there's something I overlooked in there that will help me understand this better.
I believe 1 unit = meter.
Just pick a ratio of meters to pixels, such as 50.
const float MtoP = 50f;
Then for every pixel coordinate you pass in to Box2D you divide by MtoP, while every pixel out you multiply by MtoP.
Just pick a ratio of meters to pixels, such as 50.
const float MtoP = 50f;
Then for every pixel coordinate you pass in to Box2D you divide by MtoP, while every pixel out you multiply by MtoP.
you divide by MtoP
Better to to multiply by the inverse constant for performance. So lets assume PtoM is 50.0F, then multiply by 0.02F into Box2D and 50.0F out of Box2D.
Author
In case anyone else is having a hard time understanding, this video helped me out.
[media]
Thank you for your help everyone.
[media]
[/media]
Thank you for your help everyone.
I'm glad you are getting things to work out for you now. A bit of a subtlety of what you mention above is the top left is zero zero which means to me that increasing y is down. This could be the great source of your troubles as you will need to multiply Y out box2d by -50.0F and X out by 50.0F. I didn't go through the video but perhaps because they too are using SDL it may have been explained there.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
