jMonkey Camera Vector3f Gotcha

I was seeing some crazy behavior when applying force to my marble according to the current camera orientation. The marble would just shoot off as if force being applied the marble were suddenly increasing exponentially. After lots of System.out.println'ing I discovered that Camera.getDirection() and Camera.getLeft() do not return new Vector3f instances but pointers to the actual instances! So when I thought I was only changing the force quantity, I was in fact changing the actual camera properties. I was able to fix this by using Vector3f.clone().

Problems with jMonkey and Collada

I created a simple model (a cube) in Blender and exported it to both Collada and MD2 formats. I can get both models to load and appear, but the Collada one has strange culling effects (it acts like it it's a high-level node, making big chucks of my level disappear when it's out of view). For now, I'm going with MD2.

I found the Blender 3D Noob to Pro tutorial indispensable.

 

By the way, I couldn't get either to work in jME until I had performed UV mapping on my model, which apparently gives the information necessary to apply textures. Blender doesn't let you export to MD2 until this is done, whereas it let me go ahead and create a Collada file that loaded but displayed a messed up model in jME.

jME Gravity

Gravity seemed a bit sluggish to me so I poked around and found out how to tweak it: method PhysicsSpace.setDirectionalGravity. I ended up with a Vector3f set to 0, -50, 0, which looks about right for Earth gravity given the scale I'm imagining everything at.

jME Game Time

I tried running my test application on my reasonably fast Windows desktop, and it runs quite a bit differently than on my MacBook. While the physics seems to get updated at the same rate, the logic seems to run faster. In my case, this means a higher rate of acceleration can be applied to the marble, presumably because there are more applications of torque per second. It is, of course, essential that the internal clock of a game is paced with real-time so that game-play is consistent across machines.

I found a good thread on the forum addressing this issue. It appears that there are at least two ways to handle this. One is by using a built-in multiplier -- time-per-frame (tpf) -- when doing things like updating player positions. The other is by using FixedLogicRateGame. This second approach won't work for me -- I'm extending SimplePassGame -- but I may be able to add functionality from this class into my own.

For now I'm taking the easy approach: adding tpf as a multiplier when torque is be applied to the player. After tweaking the numbers to get the behavior I wanted on my Mac, I tested it on my Windows desktop. Both systems now behave identically.

jMonkey App Distribution

Because I'm curious to see how my little jMonkey Engine application runs on a different machine, I decided to try packaging it up. I started by following the guide to using jME with NetBeans that I referenced in an earlier post. It got me most of the way there, but it has a few notable omissions.

1. "Put all your images and 3D data files into JARs too." On my MacBook, this involved using Spotlight to find the image files referenced in my code and then manually copying the files into my project folder. I copied mine into the source directory, right next to the .java file, although I imagine you could put them elsewhere. Within seconds, the files appeared in my NetBeans project view. When I modified the textureState.setTexture calls I used the name of my game class and just the file name with no path (because the image files are in my source folder).
   
2. Add the native LWJGL library to your dist folder. This tip I got from a discussion on the forum. For OS X, that file is liblwjgl.jnilib; I used Spotlight to find it.
3. Add the native ODE library to your dist folder. Another tip from the forum. For OS X, the file is libodejava.jnilib.

Note that for the game to be cross-platform, the Windows and Linux flavors of the native LWJGL and ODE libraries should be included, too.

I'll try to update the wiki.

jMonkey Physics Collisions

After much experimentation and a bit of sifting through jME Physics code, I think I have a rough understanding of how to use the collision physics. The issue I ran into was that my marble was rolling on Sphere and Box objects but passing through all the other jME primitive shapes I tried.

Apparently, method PhysicsNode.generatePhysicsGeometry creates the invisible physical boundary of the node based on the associated geometric shape. Calling generatePhysicsGeometry with no argument essentially tells it to use specially optimized boundaries for better collision functionality performance. The trouble is that these high-performance boundaries only works for boxes, spheres, and terrain (I haven't tried this last one yet but the code suggests that it works).

For any other object be treated as solid, the useTriangleAccurateGeometries argument of method PhysicsNode.generatePhysicsGeometry must be set to true. Comments in the jME Physics code state that there's a performance hit. But at least it works.

jMonkey

Trying to get the jMonkey Engine (JME) working on my MacBook with the NetBeans IDE. I followed the excellent guide on the JME wiki, and got it compiling and running with only a couple problems.

When I reached section c, I basically followed the instructions, but did not select the option to create a main class. Instead, I created my own package in the project (org.rockridgex) and copied the jME-Physics_2 source file com.jmetest.physics.TestMarble.java into it. I couldn't get this project to run until I added CVS/jmephysics/impl/ode/lib/odejava-jni.jar as a compile library; I have no idea why.