Which PTM_RATIO?

General discussion about Box2D tutorials
Post Reply
Eddy8555
Posts: 42
Joined: Sat Apr 27, 2013 3:01 pm

Which PTM_RATIO?

Post by Eddy8555 »

I'm doing my first steps with Rube, and with Box2D in general, and I'm not sure I understand the PTM_RATIO issue. I understand it converts pixel units to meter units. But when looking at the tutorials I found one that has a PTM_RATIO of 32, and another that has a value of 200. Why the different values?

When I exported my first trial of Rube to C++, translated it to Java and put it in my test app (on Android) the PTM_RATIO was 200f. It seems like that created a "sensitive" shape around my Green Leaf png file, so that it also moved when I touched a few millimeters away from the image.

I played with the numbers and 100 seems perfect. When I touch the image it moves, and when I touch outside of it it doesn't. Perfect.

But obviously this is a random number. Other bodies that I have in the app work well with PTM_RATIO of 200, and the 100 gets them to act erratically.

Also, shouldn't the PTM_RATIO be related to the actual screen size of the device?

Thanks for helping!
iforce2d
Site Admin
Posts: 861
Joined: Sat Dec 22, 2012 7:20 pm

Re: Which PTM_RATIO?

Post by iforce2d »

You could think of PTM like a 'zoom'. Making it larger zooms in for a close-up view, and making it smaller zooms out. I would think the samples are set differently to give each one a starting zoom value that shows that scene positioned in the view nicely.

Typically I make functions to convert between screen coordinates and physics coordinates, then I can forget about all these details. Eg. for iOS:
b2Vec2 screenToWorld( CGPoint );
CGPoint worldToScreen( b2Vec2 );

The exact implementation will differ across deployment platforms, but they must take into account the current zoom of the scene. Perhaps your conversion between screen point and physics world point is not taking into account the current PTM_RATIO when the user touches the screen?

Yes, the PTM_RATIO will have some relationship to the screen size of the device/canvas. For example if you have a box that is 1 physics unit high, and you want it to take up half of the screen height, then the view needs to show a vertical span of 2 physics units. For a screen height of 320 pixels this would mean a PTM of 160. On a different device with a screen height of 720 pixels, the PTM would be 360.
Eddy8555
Posts: 42
Joined: Sat Apr 27, 2013 3:01 pm

Re: Which PTM_RATIO?

Post by Eddy8555 »

OK so I created a body around an image in one scene, exported it, translated to java and run it in my Android application -- and it works fine.

Now I created another body, in another scene, did the same process, added it to my CCLayer -- the same layer that has the previous image -- but the new body is not responding to touches.

Since I did everything exactly the same, should I assume that the reason is that I created the images in two different RUBE scenes? Does that make sense?
Eddy8555
Posts: 42
Joined: Sat Apr 27, 2013 3:01 pm

Re: Which PTM_RATIO?

Post by Eddy8555 »

I think I get it. I looked at the tutorial for translating, rotating and scaling, then moved my bodies from one scene to the other and saw that the scale was entirely different. So of course they won't work together in my one Android screen. I'll try it again tomorrow with one scene, and one scale for all bodies.

Thanks for your patience :)
msm1982
Posts: 17
Joined: Tue Aug 20, 2013 4:13 pm

Re: Which PTM_RATIO?

Post by msm1982 »

Hi,

I read elsewhere that Box2D works best when bodies are within 0.1 to 10 meters in size... does this hold true in your experience? The quote was:
You should try to keep the dimensions of objects in your world as close to 1 meter as much as
possible. That’s not to say that you can’t have objects that are smaller than 0.1 meters or larger
than 10 meters, but you may run into glitches and strange behavior if you create relatively small
or large bodies.
If that is the case, does it only apply for dynamic bodies, or static as well? For example, what about large portions of static terrain, or a really tall static ladder?

Thanks for the help
iforce2d
Site Admin
Posts: 861
Joined: Sat Dec 22, 2012 7:20 pm

Re: Which PTM_RATIO?

Post by iforce2d »

In my experience, making bodies (well, technically we are talking about fixtures...) very large has never caused any problems. But making them very small or very narrow can indeed cause unwanted effects.

The collision response keeps a small buffer distance of 0.005 (the default setting) around fixtures, so for example when a pile of boxes settles, none of them are actually touching each other at all: http://www.iforce2d.net/b2dtut/gotchas#smallgap
If your boxes are 1 unit across, this small buffer is a very insignificant 0.5% of the fixture size and will not be noticed. On the other hand if your boxes are say 0.05 across, the buffer would be 10% of the size of a box, and it becomes noticeable because the boxes appear not to be able to touch each other. This is true for both static and dynamic bodies. If possible, the recommended approach is to make the most common size of body your simulation will use about 1, then if that causes any smaller bodies to be under about 0.05, scale everything up. Of course it also depends on what these things are... for example if the small things are bits of shrapnel that bounce around for a brief moment, you might not mind that the collision response leaves a gap between them and other things in the environment.

Making a dynamic body very long and thin can also cause trouble, I do not completely understand the details but it has to do with how the rotational inertia is calculated, and usually causes the body to spin widly. This issue is caused by the relative height/width of the shape, so the same problem should happen for both large and small bodies. For static bodies, it's not a problem because they don't rotate anyway.
Post Reply