v0.2 is out. Please follow this link:
http://www.mojomonkeycoding.com/jmeforum/viewtopic.php?t=1082&start=23
Happy DP! 
Thereās been some design changes:
- Some stuff (adding forces and syncing ODE geom to jME geom) has been delegated from PhysicsSystem to PhysicsObject.
- In order to solve the frame rate independance issue, the update(float) method has now been replaced with an update() method. Step size should now be a constant value, and your application should extend FixedFramerateGame.
- Probably some other minor changes as well
Sorry if weāve broken any code, but the changes were essential.
well, no.
You can still use the variableTimestepGame, all thats needed in the updateGame(float interpolation) method is another call to the physicsSystem:
public void update(float interpolation) {
physicsSystem.setWorldStepSize(interpolation);
physicsSystem.update();
}
But we have created a SimplePhysicsGame which extends FixedFrameRate so you can still use the interfaces of SimpleGame....
DP
Since no one gave an actual rundown of the ālicenseā I thought Iād give it a go. When you go to download the SDK you get a popup that is the license you must agree to. Itās not any sort of standard license it looks like they just wrote down a few constraints they wanted to be met. All in all pretty standard stuff and very compatible with JME.
- You canāt reverse engineer their algorithms.
- You canāt claim that you wrote it.
- You have to give credit to the Newton team in any "program information screen" i.e. splash screens, about dialogs, product packaging.
- You canāt redistribute the library except as part of your app.
- You have to inform the Newton team that you used their tech in anything you make public (heh, reminds me of Macromedia Director).
The only thing that was a bit āoffā for me was when they state: āIf at a later time the LICENSEE decides not to continue licensing the SOFTWARE under these terms and conditions, then the LICENSEE must delete permanently all files constituting the SOFTWARE.ā This means at any point they could just cut you off. Although I doubt that would ever happen, itās just sort of strange to have it in there.
Looking at the demos I was pretty impressed by the variety of engines that were represented. Havenāt looked at the source though, is it really as horrid as previously stated?
what meant was I get the impression that implementing physics this way will have pitfalls
Thats right. There is only one pitfall in implementing VariableTimestepGame with the physics. Let me explain:
ODE does certain calculations based on the worldStepSize which is linked to the frame interpolation. Now if that changes from frame to frame (although only very slightly) you start to noticed "random behaviour" as per describes it. What that is that if you have a simple box going down on a plane, that box will go in a different direction each time and you will very rarely get duplicate behaviour which is what you want.
So extending a FixedFrameRate game is the best option so that the worldStepSize can remain constant.
Hope that answers your question :)
But isnāt that the point of VariableTimeStep? Render as fast as possible, but only call update (i.e. your physics) on a fixed rate?
hehe, your getting confused with VariableTimeStep and FixedLogicrate there mojo
FixedLogicrateGame would work fine too.
DP
right
So all this means that if you donāt use a FixedFrameRate it wonāt run correctlyā¦ Thatās really bad, because nearly all games donāt use fixed frame rate. This ODEās restriction kills ODE itself IMO 
Hope youāll find a way to make it works correclty in a non-fixed framerate context !
Chman
Thatās what I was getting at with FixedLogicrate (although I got confused and called it VariableTimeStep, all these game types you guys made, sheesh). FixedLogicrate allows the rendering to occur as fast as possible, but calls the update method at a fixed rate. Still suboptimal, but better.
i just thought of a very good solution to the problemā¦ 
Let me implement it and il get right back to tell u the news!
DP
i havenāt had time to go on the pc recently. Im doing it now.
Well, no one has posted here for a while, because me and Per have been busy fixing bugs, changing the API namings and refactoring the code ALOT for the better ofcourse. I have also saw some FPS increase too with our new code and upgraded to a new version of ODE too.
Anyways, grab it here while its hot! (its at the bottom)
DP
And make sure to check out the new demos/examples Theyāve all got a whole new way to interact with the world: if you press space youāll throw green balls!
We hope to include joint support (vehicles, ragdolls) in v0.4, and perhaps a working scenegraph structure in v0.5.
what of the fps independence issues, which game type would you recommend using.
the demos are good by the way
Well, the tests use a fixed update frequency, and thus have unlimited FPS. I suggest you look at the PhysicsSimpleTest for instructions on how to set up this.
However, Iāve noticed this solution gives a very stuttery output when combined with my ThirdPersonHandler, so in that situation I suggest governing the framerate instead :? This is probably an issue with my camera system though.
the FPS dependance has been gotten rid of by introducing an internal timer to the PhysicsWorld. Upon call to "PhysicsWorld.getInstance().update()" a check is made to sure that the update is only fired of at set intervals. The use can set those at any rate he or she wishes.
Ofcourse, you can still create a pure frame rate dependant physics world by calling PhysicsWorld.getInstance().setWorldStepSize(tpf).
Both solutions are given to you to use. However, i highly recomend the set calling at regular intervals as it frees up the CPU to do some more important things while keeping the physics very up to date.
It seems that in 3D, there is no true and wrong solution to a problem its a compromise :? . In other word, you cant have it allā¦
DP
Well done people. I must say I am yet again impressed at what you
have accomplish to do.
Thank you lots for your hard work, you make me proudā¦
So when can we expect v0.5?
Great work !
Iāve really waiting for the 0.5 releaseā¦
Chman
Well, for version 0.3. I would like to add joints. Just pure joints, no āpresetā ragdolls or whatever.
However, and i have to speak to per about this first ofcourse, version 0.4 would contain vehicle support (very customisable) so that you can make those cars easy
0.5, ragdoll and all of its forms. This is the real challenge really, because from the same class, i would like to be able to make a donkey or a giant ant with correct physique.
But about a scenegraph structure, we are going to have to think about that, because looking at how we are arranging things at the moment, it would not provide any use to us besides taking up memory. But maybe the introduction of vehicles and ragdolls might change thatā¦weāl see.
Thats my personal plan anyways, im sure per has some of his own and we have to come up with a compromise.
DP