My mouse issues

Hello all,

So I’ve delved into making a very simple runnable demo in jME and immediately I’ve come across a few undesireable behaviors. I’m betting I just don’t understand how things are setup…

My demo is a simple one with a FirstPerson controller and a Box.

Using the arrows, the movement of the camera is fine. Arrow keys seems to turn the camera very slowly, but ok. The mouse is also slow (probably same reason as arrow keys – perhaps increment settings?) The problem here is that the mouse is intermittently jumply. Moving the mouse around, it will be fairly smooth and then suddenly the camera will abruptly be pointing elsewhere.

Also, the setting up of the frustrum is very different than doing it directly in GL, can someone offer a simple way to translate my GL knowledge to jME’s MO?

Thanks! I’ll be afk until Sunday, so please excuse any delay in my replies. :slight_smile:


A touchy subject. I’ve been working hard to take care of these damned pauses, as you might guess they are garbage collection pauses. I know why the occur, where they occur and how they occur. I’m just trying to figure out how best to stop them from occuring.

Basically, when you mouse look, you are multiplying a couple vectors as well as a matrix. You do this enough times and it builds up a lot of junk. I need to fix the build up of this junk. Run any of the other demos, you’ll probably have the same issue. It is worse on some machines, better on others. I am going to have to sit down and fix this, and soon. In fact, I might make it my next task. We have very good performance in jME, except for the garbage collection…

Setting up the frustum… yes, it’s a little different. Basically, you are defining the point on the coordinate axes of the six sides of the frustum. So:

setFrustum(near, far, left, right, top, bottom).

near is how close the front of the frustum is to the camera’s position. Far defines the far side. These are along your camera’s direction vector, and those two are basically the same as OpenGLs. Now, left right top and bottom define the points of the near plane. left/right are along the camera left/right vector, top/bottom along it’s up vector.

So, you are basically defining a window in relation to the camera location. The frustum is then calculated. Internally this is:




might help a little.

Ok, I just spent about 2 hours working with various classes trying to optimize object creation. I’ve made quite a bit of progress. Specifically with camera. There were lots of objects being created every time the frame was changed. It was a noticable difference. So, I’m going to spend a bit of time, improving things as much as I can for the next (0.5) release.

Yeah, I just tried the new improvements. Very impressive. Everything feels just a bit smoother now, but that has the effect of making the whole package feel more professional. Great job!

Thanks for your efforts on the mouse, Mojo. As Eric said, it looks much better now. The skipping I still notice every so often, but it seems less like a pause than a jump, because the mouse moves perhaps 3x the distance it should have in that time period, rather than not moving enough or stutteringly moving the correct amount of distance. (make sense?) I know, a frustrating bug description… sorry!

Also, thanks for the explanation on setting up the frustrum. makes more sense now.

I still have one section to optimize, and I think that will help things out a great deal. Unfortunately, it’s not a real easy one to figure out yet. Anyways, I do know of the issues, and am working to resolve them to keep everything silky smooth.