Bullet performance with custom cars

Troubleshooting physics
1

Hello!

So i have been working on a game for several months now (current progress can be seen here).
Currently the game is working exceptionally well, so long as I don’t have more than about 8 cars in the world. This is a problem as I’d like to have at least 16, if not more.

The problem cropped up early on when I realized the default ray-vehicle in jbullet didn’t support wheel collisions. RC Car’s all have big wheels and this is a must, so I figured it was worth it to just write my own from scratch. It’s constraint based and relies on 1 physics rigid body per wheel to collide and do most the computations. By themselves these are fairly fast but obviously with 4 phys objects per car + the car body = 5 * 8 cars = 40 phys objects all wanting to smash into eachother things start to slow down. at 16 cars that’s 80 phys objects and my hefty i7 doesn’t want to get close, let alone anyone with an older computer.

So I’m in a bind, my current system can probably run ok but I’d have to limit race size :frowning: and the tracks I plan on making would have to go with fewer dynamic physics objects themselves (no windmills I guess) which anyone who’s played games like Re-Volt will remember the dynamic world objects were lots of fun. (beach balls, trains and pianos!)

I’ve thought about trying the following:

1: Phys Layers, divy up the cars to each have their own phys layer for traction & environment collisions and put them all on a different layer for inter-car collision. Layers are limited so I wouldn’t be hitting my goal. Would this offer any sort of performance increase? (something tells me no :frowning: )

2: Multi-phys spaces, This one sounds like a pain in the :oops: but I’m not convinced it would be impossible. Unless I’m blatantly wrong in that regard does anyone have any ideas if this could work and maybe point me in the right direction? it would probably be similar to the above method with each car having a phys space for environment collisions, and a seperate phys space for the inter-car collisions.

3: lastly, my method sucks. I can freely admit I might have really just messed up conceptually here, and if anyone has any suggestions on a different way to handle car on car collisions with wheels that could be twice as large as the body of the vehicle (exaggeration but you get the point) I’m all ears. I have already attempted to modify the existing ray car to position objects in a compound collision shape to get accurate wheel collision but it either messed with the ray-car’s casting or the actual collisions just weren’t right (no suspension interaction, stiff collisions, collisions which just weren’t physically possible :confused: )

For more in detail on my cars:
I have 1 regular rigid body which has 4 slider joints I extended to support spring mechanics. Attached to the opposite end of each slider is 1 custom rigid body with a capsule object which has a physics listener to determine collisions and process the traction algorithms. Capsule instead of cylinder to prevent some annoying clipping issues. (gives goods results but still work in progress) The wheels don’t actually spin, but slide across the ground!

For those curious about my performance characteristics:
I have run several tests with 1, 5 and 10 cars to determine where my performance is going. Between 70-98% of the cpu is going into broadphase, increasing with the count of cars (obviously) this is all prior to serious graphics enhancements and any ai to speak of (which will of course want some cpu as well). (i-7 8 3.1ghz, 8g ram, 560ti sli)

Apologeez in advance if this is the wrong forum, I figured it was similar to troubleshooting or could benefit someone in the future.

2

Jbullet or native bullet? Try with antive performance for some szenariso us several orders of magnitue higher, not only due to c++ but mostly because it uses better optmized/newer algorithms.

3

Just make a raycast vehicle and make the wheels kinematic attachments so they collide with stuff.

4

Phoenix: I’m using J bullet,
Normen: The kinematic attachments was what I tried first, and honestly they weren’t very good. When colliding at high speeds you will just come to a very, very abrupt halt. I played with it for awhile but couldn’t get around it. Any thoughts? I also tried the convex casting but then the wheels get into “I wanna be on top” fights, which although hilarious does kinda break the game when 2 cars go rocketing upwards >.>

The current system lets you roll all around, tearing eachother up and flipping just like real RC cars, so if I do go back to ray-cast vehicles I’d like to keep as much of that as possible.

5

I’ll go ahead and give the natives a try, will post back how that goes

6

Alright, so I followed the advice given here for setting up the bullet natives in place of j-bullet and I have a few problems.

The libraries I currently have active are as follows:

jme3-bullet-natives (contains some dll’s)
jme3-bullet (has most the controls)

with those 2 active and no additional changes to my code I am missing the following classes:

com.jme3.bullet.util.Converter;
com.bulletphysics.linearmath.Transform;

Here is the old code which worked with jbullet but is now broken (this is pretty much the only broken part, everything else only needs minor changes, if any)
[java]
@Override
protected void createJoint(){
Transform transA = new Transform(Converter.convert(rotA));
Converter.convert(pivotA, transA.origin);
Converter.convert(rotA, transA.basis);

    Transform transB = new Transform(Converter.convert(rotB));
    Converter.convert(pivotB, transB.origin);
    Converter.convert(rotB, transB.basis);

    constraint = new SpringSliderConstraint(nodeA.getObjectId(), nodeB.getObjectId(), transA, transB, useLinearReferenceFrameA);
}

[/java]

So 3 questions,
1: am I missing a step? do I need to do anything with the dll’s to get them to work correctly
2: is the converter class and the phys transform just hiding somewhere? The only thing jmonkey ide is suggesting is to use jme3.math.transform
3: I’ve never worked with dll’s before, what exactly are they and how are they used? (I’m assuming they are compiled code, if so how do you look at it?)

7

Well I made the swtich so long ago, i’m not eactly sure, but native bullet uses the jme clases in its api, and does not need javax.vecmath classes.

8

Alright, so I guess I have it implemented correctly now. I dropped my custom slider joint to use the SixDofSpringJoint instead. Still needs a lot of tweaking but this looks like it will be usable. Performance runs about 120fps up until 14 cars are present before it drops. There is no longer a per-car cost like there used to (before every car would take 10-20 fps until it was unplayable, now performance is constant until I hit the 13-14 car limit, then it nosedives).

Problems: the joints are pretty unstable. I’m not 100% certain damping is working correctly, large values don’t seem to change anything at all. The wheels also “wobble” a lot when stationary.
I also can’t seem to set the equilibrium point, the method is void (I’m guessing it makes the current location the equil point). this is bad because I had a setting, “Pre-load” which is similar to how you can adjust the cars irl by simply compressing the spring by twisting it. Before I simply made this shift the equil point to simulate the spring is always being pushed away, which worked great. I’ll look into other ways of doing this in the meantime.

These were similar to problems I had before and found solutions to so I’m sure it’s a matter of tweaking settings this time. It’s still not quite my 16 car target but 8 car’s isn’t a bad number to aim for the time being, at least until jmonkey 3.1 comes out and more work goes into making native bullet implementation more stable.

9

Well you could go the dark way and try another approach,

simulate the car on the controlling client, and using kinematic collision shapes for the remote cars. Then you will get the usual kind of synchronisation issues, but it would scale better.

As far as I know there is a normal slider in bullet, so you could keep using your custom spring logic.

Then again, how do you simulate the wheels and the bodys? Do you set collision masks, to ensure they cannot collide with each other? (As this will reduce processing load since they nearly always bound overlap)

10

I have been using setCollisionBetweenLinkedBodys(false) Is this the fastest way?

Wheels should collide with other vehicles bodies and wheels but not their own body or wheels. I just looked up collision filtering and that may indeed speed things up if the setcollisionlinkedbodys doesn’t cull out the entire parent object + other attached rigidbodies (I’m assuming it doesn’t).

My custom slider broke because It extended the j-bullet slider constraint. I’m not familiar with c++ nor working with dll’s so I really don’t know how to write a new constraint to work the way my old one did. I’ve been looking into this, just thought I’d give the existing constraint a try.

11

I’m not sure how that method works,

I usually use lowlevel bitmasks that can be used for this, I assume the method would need to hook into the colision hook, so the full calcualtion is done, then dismissed.

With the bitmasks, it can already be dismissed in the braodphase (boundingbox) phase.

12

Alright so I managed to find out how to look in the dll’s and I noticed the constraint solver isn’t packaged (or at least not accessible) with it, so where exactly is it hiding? the SliderJoint class included with the jME3-bullet imports a slider constraint from com.bulletphysics.dynamics.constraintsolver.SliderConstraint but I can’t find that package. I understand somewhere along the line it’s being cast to c++ via the JNI stuff, but I’d like to extend the constraint for my custom logic like I had before, even if I have to do it in c++. Is it possible to get to this or it it hidden in the dll?

As for bitmasking, I’m not certain I could get that to work correctly and still allow all the collisions needed. Instead I am going to write a custom broadphase filter which will knock a large number of collisions off by having cars ignore themselves. As far as I can tell the setCollision method is done post and also doesn’t include other children, but only the parent object (I could be wrong but I believe that’s how it works)

13

Well you can just download the bullet source code and take a look at it, there is nothing hidden basically, what might be missing is the binding.

http://bulletphysics.org/mediawiki-1.5.8/index.php/Constraints#Slider

However you could add that part to the bullet wrapper, it#s a bit hard getting around at first, but learning more about jni can never be a fail investement :slight_smile:

14

Thanks Phoenix,

Looks like I’ll be learning something new next week