"Questions that don't deserve their own thread" thread

[pgimeno]

I get the point that Bartbes and Someguynamedpie are making. There's no fixed constant involved, for example there's no gravity thus Box2D doesn't have the gravitational constant built-in. Everything is arbitrary mass and length units. It seems that everything scales smoothly as long as you keep your units consistent. You can work in inches, fluid ounces and minutes, and as long as you set your values correctly with consistent units (gravity in in/min², density in oz/in³, dt in mins and so on) you'll get consistent physics results, at least in theory.

However, I've seen everywhere that Box2D is "optimized to work in the MKS system" (metres, kilograms, seconds, aka the SI). I guess that's to keep some values within acceptable ranges for the physics calculations. For example, If you work in mm and metric tons and pass a density of "0.00000000001 tm/mm³", the physics engine may have trouble with some calculations. Or setting the timestep too small or too big may cause trouble as well.

[fedkanaut]

Is it safe to have multiple threads popping instructions or whatever from one channel? Order doesn't matter, only that every individual member of the channel is popped by one and only one thread.

[airstruck]

Everything is arbitrary mass and length units. It seems that everything scales smoothly as long as you keep your units consistent.

Sure, it works, I'm just questioning whether it's actually necessary to use the same unit for everything, from a practical standpoint. Imagine this scenario: I want my world to have an earth-like gravity, so I look up the gravitational force of the earth, and I find the answer in MKS units. I think to myself, I hope love.physics uses those same units so I don't have to convert it. I look on the Love wiki, there's no mention of units so I google "box2d gravity units" and discover that it uses MKS. I think, great, I'll put 9.8 for the gravity. Obviously it doesn't work. Then I have to ask what's up on the forums. That's not convenient.

Or imagine this scenario: I'm making a little physics sandbox, and I want to let the user set the world gravity. Do I tell them to set the gravity in 30ths of a meter per second squared? No way, I want them to use the standard units. So what are my options? I can scale all the input and output, probably checking lp.getMeter way too often, just to undo the scaling done by love.physics. Or I can lp.setMeter(1) at the beginning, and lg.scale everything up 30 times or so at the default zoom level. But now other things are inconvenient, like drawing a circle. At "normal" zoom levels I can just draw a circle without specifying a number of segments and it looks fine. At 30x scale, though, it looks awful, so I have to calculate how many segments I need. Now I have write something like lg.circle('fill', x, y, r, math.sqrt(r * detailLevel * scaleFactor)). That's not convenient either.

Whether the benefits of using the "setMeter units" everywhere for consistency outweigh the practical benefits of using a more standard unit in some places is a subjective question, I think.

On a side note, does anyone know of a cheaper formula than math.sqrt(r * detailLevel * scaleFactor) to calculate the number of segments needed for a circle to look decent?

[slime]

Is it safe to have multiple threads popping instructions or whatever from one channel? Order doesn't matter, only that every individual member of the channel is popped by one and only one thread.

Yes!

[fedkanaut]

Cool, thanks!

[bartbes]

Whether the benefits of using the "setMeter units" everywhere for consistency outweigh the practical benefits of using a more standard unit in some places is a subjective question, I think.

For me the answer is obvious: yes. Always. Having to look up which unit a method takes and returns would just be crazy. Wherever Box2D takes meters, LÖVE applies scaling, simple. If I have run setMeter(1000), then set the gravity to 9.81, why should my objects have an acceleration of 9810 px/s²? And it's also very simple to use meters for everything: setMeter(1).

Can I just say that this is why I hate this thread? Mixing different discussions is annoying.

[airstruck]

Having to look up which unit a method takes and returns would just be crazy.

If setMeter really meant "pixels per meter" rather than being a "unit conversion factor," as pgimeno put it earlier, you wouldn't have to look anything up. Coordinates and distances would always be in pixels, and everything else would always be in meters. This would still make setMeter a "convenient way to draw the objects directly to the screen without the need for graphics transformations" without making other things less convenient. I do understand the appeal of having everything in the same unit, but I don't think it's such a clear cut advantage over the practical benefits of using standard units in cases where "setMeter units" aren't useful for anything other than consistency with other "setMeter units" (in other words anything not directly related to screen position).

And it's also very simple to use meters for everything: setMeter(1).

Yes, except that this creates other issues, see the second paragraph of my previous comment for an example. In fact it seems like the path of least resistance might be to use setMeter(1), but (assuming something like 30 pixels per meter is still desired) instead of doing lg.scale(30, 30) afterwards, scale up all coordinates/distances when drawing, leaving things like acceleration alone so they can stay in standard units. This is probably what I'll end up doing, I think.

Can I just say that this is why I hate this thread? Mixing different discussions is annoying.

Do I detect a theme here?

[pgimeno]

I look on the Love wiki, there's no mention of units so I google "box2d gravity units" and discover that it uses MKS. I think, great, I'll put 9.8 for the gravity. Obviously it doesn't work. Then I have to ask what's up on the forums. That's not convenient.

I think that your complaint is more about the choice of 30 for the initial setMeter value than anything else. And that's a fair complaint. Maybe we could have a love.physics.setPixelLength() method and e.g. a Body:getPositionPixels() method to deal with that conversion better, rather than having to scale the output of Body:getPosition() manually. (The same applies to CircleShape:getRadiusPixels() etc.)

Of course you can always work around that lack using this somewhat inconvenient approach:

Code: Select all

  local pixelsPerMeter = 15 -- for example
  love.physics.setMeter(1)
  -- init physics here
  ...
  -- when you have to read the values:
  love.physics.setMeter(pixelsPerMeter)
  local x, y = body:getPosition()
  local r = shape:getRadius()
  love.physics.setMeter(1)
  ...

I imagine a physics wrapping library could handle that automatically.

Edit: By the way, if you use setMeter at the beginning of the program, before love.physics.newWorld, in theory you should obtain the same result as not using setMeter at all (modulo calculation errors due to extreme values in the core of Box2D). Is that not what you're seeing? If not, can you give an example where it makes a difference?

[airstruck]

I think that your complaint is more about the choice of 30 for the initial setMeter value than anything else.

Well, 30 seems like a reasonable value for a meter-to-pixels conversion, given that box2d is tuned to work with objects between 0.1 meters and 10 meters in size. At Love's default resolution of 800 by 600, that means a shape in that size range will take up somewhere between 3x3 pixels and about a quarter of the screen. I think my main complaint is that setMeter is not just a meter-to-pixels conversion, but instead a thing that effectively changes box2d's base unit from meters into a variable user-defined unit. Intuition (and the community) tells us we should always work with meters in box2d, and only convert to and from screen positions when necessary. But Love has this backwards, it wants us to always use pixels as our base unit. I can see making an exception to the rule of always working in meters for the screen-position related stuff, in the interest of shooting for a "hello-world-like" API, but I can't see making that exception for everything else just because we already made it for position related stuff. I'd rather mix units.

Thinking about this more, I think bartbes is right about setMeter(1). I think the only reasonable thing to do if we want to use box2d in meters as intended is always immediately setMeter(1). And, in the case of library code, any time we regain control after giving it up to other code, store the results of getMeter(), setMeter(1) again, do our thing, and then setMeter(oldValue) before giving control up again.

Maybe we could have a love.physics.setPixelLength() method and e.g. a Body:getPositionPixels() method to deal with that conversion better, rather than having to scale the output of Body:getPosition() manually. (The same applies to CircleShape:getRadiusPixels() etc.)

I thought about that also, but I think there's just too much stuff that would need a *Pixels version. And really, how hard is it to do lg.scale(30, 30)? I think setMeter causes more trouble than it's worth just to save us from calling that one tiny function (other weirdness aside, like drawing circles).

By the way, if you use setMeter at the beginning of the program, before love.physics.newWorld, in theory you should obtain the same result as not using setMeter at all (modulo calculation errors due to extreme values in the core of Box2D). Is that not what you're seeing? If not, can you give an example where it makes a difference?

You can use it before newWorld or any time, because it's just a global setting that affects (nearly) all values going in and out of the physics module, sitting awkwardly on top of what is otherwise a nicely encapsulated object model. Try it out, just setMeter(1) and then create a world and add some stuff to it.

[pgimeno]

I thought about that also, but I think there's just too much stuff that would need a *Pixels version. And really, how hard is it to do lg.scale(30, 30)? I think setMeter causes more trouble than it's worth just to save us from calling that one tiny function (other weirdness aside, like drawing circles).

I don't like lg.scale as a substitute in this case, because it scales everything else. Line thickness, fonts, images... Not just the coordinates.