I've tried a few things, and currently I am setting the localTranslation on a parent node to the physics node, but it doesn't seem to be working. My program creates several boxes in the same place (which go flying as soon as they start to render).
basics are:
Box b = new Box (name, new Vector3f(), colour)
dynamicPhysicsNode.attachSpatial(b)
translationNode.setLocalTranslation(xTrans, yTrans, zTrans)
translationNode.attachSpatial(dynamicphysicsnode)
rootNode.attachSpatial(translationNode)
I know to use addForce, etc, but I need them to start somewhere other than the origin (and to teleport... eventually). Any ideas as to why this isn't working?
game states with better thread timing and locking (all the things I asked for in the features thread)… and I wanted it working, not working tomorrow.
minor reasons
extracted timing logic into a class so that I could use it for the independant physics thread. (and soon an 'event' thread)
update an fps stats node in the update clause (though I could do that externally now)
now that it works, I can't be bothered setting it back. (umm, perhaps this should be the main reason…)
before you worry too much, its almost as simple as changing it to new StandardGame() instead of XPhysicsGame() (+ physics, of course). 'game' classes are seperate from world building and input control.
also to learn about the insides as well as the outsides of jME. It was interesting to find that the init has to be in the same thread as the render for lwjgl
I'd like to push back the timing utility to jME, but to do it properley, things using it would need a Tickable[init(), tick(float tpf)] interface (I figure one feature request at a time)… and then there would be a fully (independantly) threadable physics impl as well… as far as I could tell, the packaged physics game extended simplegame, not standardgame.
its different to Java3D (and I don't have a pair of 6 axis trackers like I did at uni), but it feels more like something I can play with (and make a simple game. Of the highly complex Marble Puzzle variety).
Not to divert this topic too much, but could you link back to that "features thread" so I can see what those features were that are missing?
See the idea of StandardGame was that work should be done in GameStates rather than extending it. The only thing you've mentioned that truly isn't "supported" is update thread timing changes and I wouldn't be opposed to adding something for that.
To offer an example of how I've done physics in my own games in Galaxies Beyond I have a SpaceGameState that if I recall extends PhysicsGameState (should be in jME-Physics) and provides all the functionality for physics without having to change or wire extra functionality into StandardGame. There's nothing inherently wrong with what you're doing except it violates the purpose I had for StandardGame.
lock the game to prevent it from ticking while the nodes are being created. Since a node is automatically part of a physics space, it gets acted upon every time physicsSpace.update(tpf) is called.
