Motion Path speed, duration and screen size - unexpected behaviour?


I’m executing as a standalone project and the bigger the screen size (chosen with the opening dialog), the “longer” the path appears to be in terms of movement (ie, at high screen resolutions, the allocated time through motionControl.setInitialDuration() is not sufficient for the teapot to complete the whole path). This became apparent when i started experimenting with slower speeds through motionControl.setSpeed().

Are the calculations done in world units? If so, i’m not sure i understand why the screen size should have any influence on the distance travelled along the path.

Any clues, anyone ?



Not really, do you set the initial path depending on the screen somehow?

As i said, i use the code in the “” example as-is, except for messing around with the motionControl.setSpeed() value.

For example, if i set the speed at 0.25 and the InitialDuration at 10, the motion lasts a predictable 40 seconds. At 640x480, the teapot arrives at the end of the path no problem.

However, at 1024x768, the teapot reaches waypoint 4 and then stops (after 40 seconds as well). At 800x600, it stops just before wpt 5 (also after 40 secs.).

Puzzling, isn’t it ?

I’d rather look for the reasons in the framerate than the resolution. @Nehon got any idea?

That would make sense, since bigger resolution = biger fillrate. I’ll look into it over the weekend.



At any instance the system is for playing back cinematics, literally. If you want to move geometry do so my manipulating their location with controls (add.: and by decoupling from the framerate with the tpf value).

Mhh strange… I never noticed the issue… i’m often testing at 1280 though and never really changed the resolution.

MotionPath is decoupled from frame rate, tpf is stacked to compute time.

at each update i compute the distance the spatial should have been traveled on the path considering time and speed, then i interpolate its position on the path considering the interpolation type.

Only thing i could see is that there are rounding issues when computing the distance … but I would have noticed the behavior at different frame rates (vsynced or not i never noticed any difference). I wonder what the resolution has to do with this.

I’ll test that


I added a setFrameRate() of 60 to “” and now, the teapot barely makes it to the first waypt (with initialduration=10 and speed=0.25). FYI, with this example i get about 1,000fps at 320x200 and 500FPS at 1024x768

Definitely framerate-related (screen resolution slows framerate, at least on my laptop).

Maybe i should be following normen’s advice on using controls ?

I’ll do some more reading. In the meantime, i thank you both for your time.


I tested it with different frame rates or resolutions and the teapot always make it to the end at the exact same pace for me.

What version of JME do you use?

Product Version: jMonkeyEngine SDK 3.0beta

(checked with for automatic updates : up-to-date).

How do i check for minor version numbers ?

This is weird. Bear in mind that i see this behaviour with a slower speed, such as 0.25. If speed is left at 1, the teapot always makes it to the last wayoint.

Did you test at slower speeds ?



Yes i did, and the teapot still makes it to the end.

You are probably on stable release and there has been changes in nightly builds, so they’ll be pushed in next stable release. So please be patient.


tks, nehon.