Box2d physics - pixels to meters
Re: Box2d physics - pixels to meters
I've looked it up and indeed they have hard-coded tolerance that's "not visually significant" and it makes small objects, while numerically stable, become simulation-wise unstable since detection tolerance becomes significant compared to objects' size. And very large objects, comparatively to other objects, tend to generate very long broad phase test calculations. Number of possible collisions grows to the power of 2 to its linear size in one dimension, and computational complexity of resolving collision matrix is, as I recall, about O(n²).
Re: Box2d physics - pixels to meters
That's not the main reason I'm suggesting it, though. With the default value of 30 pixel meters, things will pretty likely be in the range of 0.1 to 10 meters.pgimeno wrote:Also, I'd take airstruck's advice about setMeter, so that the engine works in the range it's optimized for.
This is the real problem. This decision is going to affect everything else, when it shouldn't. Say you're making a game and you decide your player character is two meters high and one meter wide. You have some placeholder sprites (programmer art) that are 20px by 40px. That means you want 20 pixels per meter, so you setMeter(20).Then choose how many pixels per metre you want.
Everything else you do is in pixels (or pixels-per-whatever). You want him to run, you decide what speed he should run and you write your run function. You want him to jump twice his own height, you figure out what impulse you need to apply to get him there, and you write your jump function.
Now your graphic designer comes in and says hey, everything is way too small, here are the redesigned sprites, they're 32x64 instead of 20x40. So, you change to setMeter(32). Guess what? Now your player runs slower and jumps less high, because all of your measurements are in pixels, and the meaning of pixels just changed. Now you have to find every place you apply a force or an impulse or do anything else involving passing a value to the physics engine, and multiply it by 32 over 20.
This is obviously not tenable. The simple solution is to always work in the same units, and only convert to pixels when needed (in other words, when drawing). As far as I can tell this is how Box2D was intended to be used, and you can find plenty of threads on their forums with people saying so. The only way I would recommend using setMeter is to leave it at 1 all the time and possibly switch it to 20 or 32 or whatever just before drawing, if that's helpful for drawing, and then immediately switch it back.
Who is online
Users browsing this forum: Ahrefs [Bot] and 6 guests