Jump to content

  • Log In with Google      Sign In   
  • Create Account


Box2D: Understanding the conversion to pixels


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 SonicD007   Members   -  Reputation: 457

Like
0Likes
Like

Posted 03 November 2012 - 01:26 PM

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

Edited by SonicD007, 03 November 2012 - 01:27 PM.


Sponsor:

#2 Animate2D   Members   -  Reputation: 182

Like
2Likes
Like

Posted 03 November 2012 - 02:33 PM

It is my understanding that Box2D is optimized for an acceleration of 10m/s2. 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.

Edited by Animate2D, 03 November 2012 - 02:40 PM.


#3 SonicD007   Members   -  Reputation: 457

Like
0Likes
Like

Posted 03 November 2012 - 03:48 PM

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.

#4 Serapth   Crossbones+   -  Reputation: 5311

Like
0Likes
Like

Posted 03 November 2012 - 04:14 PM

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.

#5 Animate2D   Members   -  Reputation: 182

Like
0Likes
Like

Posted 03 November 2012 - 04:18 PM

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.

#6 SonicD007   Members   -  Reputation: 457

Like
0Likes
Like

Posted 04 November 2012 - 01:32 PM

In case anyone else is having a hard time understanding, this video helped me out.



Thank you for your help everyone.

Edited by SonicD007, 04 November 2012 - 01:33 PM.


#7 Animate2D   Members   -  Reputation: 182

Like
0Likes
Like

Posted 04 November 2012 - 04:02 PM

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.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS