I've been doing some tweeking to the TestVehicle class and finally came up with a solution for a suspension system that works well. I'm posting the source code for the physics part here, so anyone can test it and share some ideas.
My car is made of one main class for the Car
Physics node for the chassis
Two suspension systems
Methods for accelerating, braking (releasing gas pedal actually), steering and unsteering
One class for the suspension system:
Two physics nodes for representing the suspension anchors
Two joints, with one translational axis (Y), for representing the suspension course
Two Wheels attached
helper methods for the actions
One class for representing the Wheel
One physics node (capsule) for representing the rubber wheel (material)
One joint with the suspension, with two rotational axis, for accelerating (sppining) the wheel, and steering it
helper methods for the actions
Just add one instance of this class to your rootNode (you'll need a PhysicsSpace of course) and create input actions for using the car methods for accelerating and steering.
One can do some tweeking with the parameters to get different driving feelings. Here is the source code (without includes) for these three car classes:
I obtained better results with Spheres instead of Capsules when turning at high speed, and had problem too at high speed with my circuit when using triangles.
Thank you !
Kine —> Next cap: bullets & homing missiles programming …
I also changed to sphere instead of capsules. Made a couple of ajustments as well. One you should consider is putting some velocity to the translation axis in the suspension Joint… So the car will bem a bit lifted and the general feeling is better.
I put this code here to create the axis (the only difference is the available acelleration and the velocity):
Did you ever had some problems with one of the wheels getting into the terrain (and then strange things can happen because of the unusual forces and contacts)?
I don't know if this is related to slow framerates. I tried triangule acurate collisions and had no better luck.
Thanks in advance.
PS. I'll also start the coding for bullets, rockets and related stuff.
Can you give me some hint here? I read in another post about a minigolf game project that was suffering the same kind of problem, I gess. They said that when the ball was fast enougth it could run through some walls or terrain. Then they tried making the ball bigger. You said in a post you've heard that ODE has some issues with triangle-triangle collision.
I'll try putting the physics terrain mesh (originated from a terrainblock <- from a ImageBasedHeightMap) WITH triangle accuracy - generatePhysicsGeometry(true) - and the wheels spheres WITHOUT triangle accuracy - generatePhysicsGeometry() only.
No luck with that. I think the problem is related to the issue reported in some posts about problems with the collision detection implemented in ODE/ODEJava. I'm a bit sad and unhappy that I didn't find a solution yet.
JME and JMEPhysics are great tools and the foruns are even better. I'll keep tryong though. Next effort will be testing different wheel sizes vs. terrain TriMesh triangle sizes to see if I have any luck.
Irrisor,
You mentioned (in response to a post) about the implementation of collision detection with a HeightField - http://www.jmonkeyengine.com/jmeforum/index.php?topic=3099.msg27635#msg27635 - Any adavance? Want some help in doing that? I'm preparing for a PhD in computer science and will keep on game/physics programming for quite a while.
I did not do/hear anything about using height field with ODEJava / jME Physics, sorry. But any efforts are appreciated
Using sphere or capsule on trimesh terrain should be fine.
With ODE's collision detection there are usually two issues:
Number of contact points per step is too low -> some contacts are discarded. I increased the number of contacts to 50 in OdePhysicsSpace (Odejava.setMaxContactGeomsPerNearcallback( 50 );). This really should be sufficient. If it's not you can test if it helps to raise it. But this costs a lot of performance. If it helps to raise the number use a terrain with bigger triangles instead.
Objects are too fast. If your objects move more then the acceptable penetration depth in one physics step you should increase the number of steps per second (lower the step size). You can try something like this in your app:
if ( physicsSpace instanceof OdePhysicsSpace ) {
OdePhysicsSpace space = (OdePhysicsSpace) physicsSpace;
space.setStepSize( 0.005f );
space.setUpdateRate( 200 );
}
Be aware that applied forces should be per step and depend on the step size.
If nothing helps, try with a box instead of terrain first...
I'd already tried the bigger triangles and it really worked well. I'll try to raise the max contacts:
(Odejava.setMaxContactGeomsPerNearcallback( 50 )
I'm aware of the interdependencies of step size, gravity, forces and etc. I'll keep you informed of the possible implementation of the heightfield conlision detection... First I'll study JMEPhysics/ODEJava a bit more.
I've also got problems with my car falling though the ground. I've noticed that there is a very strong force that actually makes the car "pop" though the ground if I use this getPhysicsSpace().createJoint().attach(dynamicCarNode); to try to hold my car in mid air then its as if my car test is working fine.
What can that force be that pulls my car though the floor if I don't use that joint to keep my car on the ground?
I guess there is no point in just saying that it doesn’t work (I need to produce some code for you to check where my problem is) and so here it is. Notice that the dynamicCarNode.getLocalTranslation().y is -9 when the car is still on the ground (just before it pops though the ground) and the ground is about 0
The problem is that you created a dynamicPhysicsNode and attached my car implementation to it. You don't need to create any dynamicNode at all… They are all defined and created inside the car, suspension and wheel classes.
change the createCar method to this:
private void createCar() {
car = new Car(getPhysicsSpace(), new Vector3f(0,10,0)); // note the Vector3f as parameter. It's the car initial position, 10 units over the floor.
rootNode.attachChild(car);
}
This is the new Car constructor (I've been tweeking this classes a bit, if you want I can send the whole new source as well):
public Car(PhysicsSpace pSpace, Vector3f position) {
Hi Perrick ! First I want to thank you, all you tips helped me a lot. I'm a begginer in Java & Game develloping too. I've been learning a lot with JMonkey. It's great !!
So I encouter the same problem with number of triangles per mesh and number of points impact … my car "hitting the ground".
I tried to increase the number of PhysicSpace refresh and found how to increase the number of collision points per triangle too. It works fine but really annoys my CPU.
If I'm right increasing number of collisions as said by Renanse can be combined with decreasing number of triangles to avoid loose of computing speed…
I can't find how to modify the number of triangles you talked about … Can you bring me some help again ?
Another simple question: Will you use DynamicPhysicsNode for your rocket and bullets stuff ? Number of physics Object for a 8-player game would
be >50 Don't you think there is enough coding functions for spatials to make it possible without phys ? Perhaps CPU time would be saved… I precise I don't apply gravity to my projectiles … You've probably readed the JME Physic implementation more than me, so do you think it should save some CPU time (I ask this question even if my Object programming view tell me the contrary… )
I suppose you pre-charge your 3d models rockets and other… Do you charge one once you've fired one or all at the beginning as adviced by our Frog… ?
PS: My game FPS is beginning to get very low with all these rockets stuff !! Oops I shoudn't have used a rescaled Zepplin 3d model for my rockets …