I am working on a Physics Engine, and I have been using opengl to visualize what it's doing. I think I have a scaling issue when going from natural coordinate system to the opengl screen coordinate system, which is between -1 and 1. I am saying that 1 is 150 meters and -1 is -150 meters. Therefore, to get to scale I should be able to take the natural coordinate system point say <0,100>, and scale to screen by doing <0,100/150>, which is approximately <0,.667> screen coordinates.

When I watch a 1 kg ball fall from 100 meters, it seems too be falling to slow, as if it's falling under water (see https://www.youtube.com/watch?v=KiZODHIvJ4A for reference). The physics engine seems to be correct. I think it has something to do with the coordinate system translation (just dividing by 150 scalar right now). Does anyone know if I am doing this correctly?


I think your simulation is correct. A 100 meter fall should be 4.5 seconds on earth gravity (ignoring air resistance). And those 4.5 seconds seem to match the time in the video.

I think it is fine. I believe the "under water" impression comes from the size of the ball.

Doing a rough estimation of the size of the ball, I think it has about 10 meters of diameter. The volume would be 523.599 cubic meters (thanks Wolfram|Alpha).

That is a big ball, with only 1kg, the density is 1.90986 g/m^3 (thanks again Wolfram|Alpha), this is the density of air as per Wikipedia: 0.001225 g/cm^3. So, we see a ball moving through a medium much denser than it. Yeah, I think the "under water" feeling is purely psychological based on the size of the ball relative to the span it moves.

Your mind imagines the ball smaller, and the fall distance shorter, and then the fall is too slow, as if the medium were too dense. Draw some background, some tall buildings for reference, and your mind will get the right cue. I apologize for reading your mind without permission.

That does not mean you are handing OpenGL coordinates correctly. There is a mistake when it comes to resizing the view port. Which is something that probably you do not do at all, which means that what I describe below has nothing to do with the "under water" feeling...

Take premise that the coordinates in OpenGl goes from -1 to 1. These are called normalized device coordinates (NDC). They are not what you see. What you see are screen coordinates (SC). There is a transformation that must happen to map normalized device coordinates (that go from -1 to 1) to screen coordinates (that are in pixels).

How is that transformation defined? By the view port. You tell OpenGl about the size of your view port, and that is what OpenGL uses to map the NDC to SC for rasterisation.

That means that resizing the view port will make thing appear to move faster or slower in screen because -1 to 1 will stretch to more or less pixels, and the simulation is taking the same time.

Now, before the coordinates were in NDC, they were in whatever scale and dimensions you want when you pass the vertices to OpenGL. You have decided to use a scale factor of 150 and called it meters (you can say it is whatever unit you want, that is not the problem). By the way, you are doing that scaling in a shader, right? RIGHT?

The mistake is that this scale of 150 is fixed. It does not take into account the size of the view port. You need to consider the size of the view port if you want to compensate for the stretching I described earlier.

Please refer to How to setup glOrtho and Viewport and the difference between glOrtho and glViewPort in openGL.

Well, if the size of the window is fixed too, then this is moot. I stand by the statement that the "under water" feeling is psychological.

  • \$\begingroup\$ That was a very interesting read. Just so you know, I set the radius of the ball to 2.5 meters, which is a pretty large object to weigh only 1kg. I read that the default size of the view port was the window size, so I didn't set the view port. The information you've given me is extremely helpful, because I was planning to extend to 3d at some point. I am not doing the scaling in a shader. I am simply doing something like radius/SCALE, where scale is 150. I guess I need to go do some more reading. Thanks for the help! \$\endgroup\$ – Gary Drocella Aug 26 '19 at 8:15
  • \$\begingroup\$ I was actually able to get a bit of a speed up when I removed the print statements too. Still has a bit of an underwater feel to it, though. \$\endgroup\$ – Gary Drocella Aug 26 '19 at 9:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.