Gravity vector in meters, everything else in inches?

[GameMonetize]

Do you mind creating a repro on the PG jsut to ensure I'm understanding correctly the problem?

[octopus]

Alright, I built a playground, here.

The scene seems to work quite naturally as long as lines 24 and 25 are thus:

    var G = meters.G;  // how do you decide what units or value to use here? the usual 9.81 is in meters!
    var sizes = inches; // since G is in meters we'd expect to use meters here too, right?

If you set sizes to meters, now how do you decide what to set G to? 

Feel free to change these two values to see different scenarios. The scene never appears to change visually because everything else (camera, light, etc) are placed proportionally to the props in the scene. The gravity units could follow the same unit convention you choose if and only if you uncomment line 28. But for now, leave it commented and see what's up (or down) with gravity.

I hope the comments in the code help to explain what I am seeing and what I think would make things more logical. All of my experience so far has been with the Cannon physics engine and my findings are consistent with the few scenes I've built so far.

Keep in mind that there are also impulses involved. The units on the impulses shouldn't be arbitrary either. If the math is done correctly an impulse vector one unit long should be enough to move an unimpeded body of 1 unit of mass 1 unit of distance in 1 second, and indeed we see this behaviour where the movement of the balls is consistent with the proportions entered.

The main point I am making is that when a European developer (for example) builds a scene in meters, they will find that the default value of G will not be right. They will probably experiment with G (not knowing the relationship) until they find something that works. Then they will play with the impulses, and since G was decided by experimentation and not any true relationships, then their forces and impulses will be off as well. If the conversion factor of 0.0254 (line 28) is used then everything becomes predictable and sensible.

If you want to see without the impulses, just comment out the impulse lines and increase the heights of the balls to say 5*sizes.ball or 10*sizes.ball.

[yahiko]

Hi, I don't really know Babylon or the physics engine used in your example, but I am wondering wether time step needs conversion as well in order to make things work properly. The constant of gravity is an acceleration expressed in a distance unit divided by the square of a time step unit. Usually, in Europe the distance unit is in meter and time step in second, but in video games, I often have to consider frame (or tick) as a time step. Maybe you might have a look at your conversions with that in mind. This could solve your understanding issue.

[RaananW]

About the difference - 

I am not sure I follow

Both scenes will act the same if you use the right units throughout the scene -  http://www.babylonjs-playground.com/#2JY0P0#3 and http://www.babylonjs-playground.com/#2JY0P0#2 .  (works the same with the impulse as well)

You will need to work with the same units. If you chose meters as your length units, use meters as your gravity as well. Chose cm? compensate your scene's units (which you did so nicely with the meters, inches, feet objects)

I like the comment about the time step as well. The engine (cannon in that case) uses 1/60 as the default timestep. It can correct according to time, but the recommendation is to not modify the timestep in each and every frame. So setting a higher gravity value, while adjusting the timestep will also influence your scene.

But then again, I am not too sure I understood your question. 

 

[octopus]

@yahiko, that's a good point and fps certainly would play a factor, but in this demo (and in most of my tests) the fps is at 60, which is what most engines use as a basis and the math usually considers an fps of 60.

@RaananW, I do not believe your parameters in that demo are natural at all. true your parameters are consistent throughout. Yeah sure. Gravity is far too high, these balls have a restitution of 0.99 (and the table 0.5), they should be very bouncy with those parameters. But, they fall way too quickly. For both of those demos if you uncomment line 28 `G *= 0.0254` now you have a more natural looking scene.

There might be something I am missing. I have noticed that if you change the Physics engine to Oimo, then gravity is once again completely different and I have no explanation of what is going on there. But for now I am still convinced that for optimal reality in Cannon, the ratio of gravity to other units is similar to the ration of meters to inches. I haven't yet been convinced otherwise.

Just to clarify, I never really meant to say that physics isn't working properly. It all works great, it is just a matter of scale. Gravity only seems to work, imo, if you scale it by the number of meters in an inch. All I am really saying is that as long as you are using inches in your scene and meters in your G then everything looks great. Its like you have an N scale model railroad and then you plop in one thing (in this case gravity) in a gigantic G scale. 

It works and you can finagle it, but it just makes more sense from a development stand point when everything is modelled using the same scale.

[octopus]

Let me try to explain one other way. This would seem to be the best way to code your scenes:

a- model in meters and use G=9.81 (which would be m/s^2)
b- model in feet and use G=32.185 (which would be ft/s^2)
c- model in inches and use G=386.2205 (which would be inches/s^2)

That's easy, no? But those values do not produce realistic results.

For realistic results you ought to do this:

a- model in meters and use G=0.249174
b- model in feet and use G=0.8128
c- model in inches and use G=9.81

In the second case there is an important mathematical factor used to calculate G, specifically 0.0254, but why should there be? There should be a 1:1 relationship between scene units and gravity units. If I were to build production code I would likely make myself a gravity setter function that always multiplies my value by the magical 0.0254, then I would know that if I want Moon gravity or Jupiter gravity I need only look up what those values are and plop them into my code..

In other words, what I am suggesting is why not build these conversions (to shift G to the right units) within the Babylon engine? That is all.

So far, I feel as though @JCPalmer is the only one who has actually grasped what it is I am trying to say. He said, "Looking at Blender game Engine, gravity is set to 9.80.  If you change the scene units to 'Imperial' it changes to 32.15.  "

[adam]

On my computer, multiplying gravity by .24 makes the ball drop from 386 inches in about a second.

http://www.babylonjs-playground.com/#2JY0P0#19

same with meters:

http://www.babylonjs-playground.com/#2JY0P0#18

and feet:

http://www.babylonjs-playground.com/#2JY0P0#17

[octopus]

30 minutes ago, adam said:

On my computer, multiplying gravity by .24 makes the ball drop from 386 inches in about a second.

http://www.babylonjs-playground.com/#2JY0P0#5

Well that certainly seems like a reasonable test @adam. I tweaked a couple extra things (http://www.babylonjs-playground.com/#2JY0P0#11). Objects should fall 1/2 the G value in 1 second. But I agree your value might be better than mine. You have verified though that a factor is still involved, I think it would be worth at least documenting that factor somewhere whatever it might actually be.

 

[aWeirdo]

Hi again,
As i've mentioned before.. gravity is calculated relatively correct, relatively, because it's a game framework, we cannot produce 100% correct results.

What you believe is a bug, is not a bug, it is, as i have also mentioned, a simple question of perspective. 

small scenes with small objects with a camera very close by, will produce appearance of very fast moving objects.
While bigger scenes will appear more realistic.

Here is a PG with the camera a bit further away, and all objects enlarged(correctly scaled though)

http://www.babylonjs-playground.com/#2JY0P0#15 (click run a few times and it will avg. around 500ms)

Try setting sizes to inches and gravity to meters, it will look wrong.

and the otherway around it's completely wrong, while both being meters or both inches, it looks good.




 

[adam]

19 minutes ago, octopus said:

Objects should fall 1/2 the G value in 1 second.

If that is the case, a value of .115 works for me now.  

http://www.babylonjs-playground.com/#2JY0P0#16

Months ago I set the value of gravity in my personal project to .1 of the default.  I guess I've got a pretty good eye.

[adam]

17 hours ago, aWeirdo said:

a simple question of perspective

I'm beginning to think that there could be an issue.

I don't think there is an issue.  I just think the default value for gravity is too high.

Edit: well I guess that is an issue if BJS is simulating earth's gravity by default.

 

[octopus]

@adam, I pretty much agree with your latest conclusion. Not that there's a problem with gravity per se, just that there seems to be a factor involved when choosing what value to set it to. And I agree that it seems to be around the .115 mark (not 0.0254 as I was previously saying). This assumes of course that we are trying to simulate Earth's gravity at 60fps. I'm not even sure how you would change the fps in BJS.

 

Edit: Actually it doesn't matter which gravity, you still have to multiply the desired acceleration by this factor.