Hey Guys,
I’ve noticed that my static world has a huge impact on my cpu usage:
When I have 50 BetterCharacterControls the FPS drop down to like 2 FPS, when I however decrease my level size to 1/4, it’s running at 30 FPS (and would run more: 80-90+)
How I currently “create” my collissionshape is simply using .addControl(new RigidBodyControl(0f)); on the rootNode.
This however simply uses the Triangles I use to create my objects:
I would want this house to be simply it’s boundingbox but since the windows are seperate Geometries and such it’s not.
How would I set that? Would I need to get all the Spatials (each door, window, etc) and add a BoxCollissionShape on that because adding a boxcolissionshape on the Parent-Node would lead to a similar shape? (one per geometry)
What I already tried:
I currently have a SceneGraphVisitor and if I get the spatial (.getName()) of the Grass and afterwards the MainSpatial/Node of that house, I did:
CollisionShape c = CollisionShapeFactory.createBoxShape(spatial);
spatial.addControl(new RigidBodyControl(c, 0f));
This unfortunately leads to the following bug: I can see the CollissionShapes in Physics DebugMode but the Houses are gone, just as if they were added to another node and hence don’t longer belong to the rootNode.
You want areas. If the whole scene is one big collision shape / rigidbody then the broadphase can’t sort out objects and the narrowphase will have to be run on every single triangle of your map. RigidBodies don’t have anything to do with nodes, the physics space has no nodes.
So how could I do this? By simply having multiple RigidBodies?
So the actual structure with those multiple triangles isn’t the problem?
Is it enough to simply have one rigidbodycontrol per house?
I need to add those RBC directly to the PhysicsSpace though not only the parent node, right?
Because adding the parent would simply have one CompundCollissionShape?
I don’t know but the above spatial makes the “spatial” I use it on invisible or moves it strangely.
The RigidBodyControl picks up the position that the spatial is at when you add it. I guess you’re having your spatial at 0/0/0 when you add the control and then try to move it by using setLocalTranslation which doesn’t work because the physics control puts it at the physics location (which is the point of the RigidBodyControl).
Just for other people wondering (I just tried it out :P): Actually setLocalTranslation moves the Spatial (and triangles) but the collissionshape would stay.
My code is a bit messed up and it places everything with a rigidbodycontrol manually so it was placed twice which moved the Spatials aways.
Anyway I now have 150 FPS+ (250 if I cull out the scene (and thus only measure cpu performance)).
I still have the big “new RigidBodyControl()” thing on, though and only add the rootNode to the physicsSpace, but I remember seeing some code that any children-RBC will be added to the phyiscsspace? (I guess I wouldn’t have an performance improvement without^^)
So I shouldn’t care about the actual triangles?
Do you have any other valuable tips?
And could you explain why setAccuracy is bad? I had the problem that I could always pass objects and I could (nearly) fix that with accuracy (according to the wiki).
And I didn’t really get what setCcdMotionThreshold does:
The amount of motion in 1 physics tick to trigger the continuous motion
detection in moving objects that push one another. Rarely used, but
necessary if your moving objects get stuck or roll through one another.
I didn’t get what passing objects has to do with a continuous motion?
If an object moves more than x in one physics update frame enabling CCD will perform a sweep test from the start position to the end position to see if any obstacles are in between that the object would collide with. So generally that value should be around 1/2x to 1x the objects diameter.
Increasing the accuracy for solving that problem is unnecessarily increasing the load of the physics system - bullet is pretty much built around the default frame rate.
Okay, I tried that now but I don’t really have success with that
I tried everything including quite small numbers (0.0001f) and setCcdSweptSphereRadius() without any success.
Maybe unrelated but the character is always a bit shaking (except for when I jump against a wall and hold “w” so the friction keeps me sticking to that wall)
And two other things
I want my NPC to walk through themselves but I don’t know how?
This is the usecase for setCollissionGroup?
And the other one:
PhysicsSpace.sweepTest() is the one I would want to represent something like a “View-Cone” and don’t care about the actual triangle?
Maybe try native bullet, jbullet is always a bit hit and miss with ccd. Just replace jme3-jbullet with jme3-bullet (or in the 3.0 SDK, follow the instructions to reduce distribution size and remove the jme3-libraries library set and use the jme3-libraries-physics-native one) I’d rather suggest using as high values as possible in general though.
You sure that you don’t just update your camera from the character position before the physics control applies the location to the physics object? Otherwise make sure you don’t have huge triangles that your character is supposed to walk over.
Yes, collision groups, read the javadoc though. Theres “collision” groups and “collide with” groups.
Sweeptest just sweeps a collision shape through the physics space and reports any collisions without having an actual rigidbody or pushing anything away.
Yay, it’s finally working
Unfortunately the apply{centralForce, Force, Impulse}() doesn’t work anymore, so I will have to think about the pro/cons of jbullet vs native-bullet. The native one is faster, has the ccd, but is unable to create impressive grenade-fly-away effects
There were no real changes to bullet in 3.1, right?
Other than that I am so happy that I don’t have to care about the bottleneck physics performance anymore
Edit: Oh and I use a camera attached to the character but it is set using getPhysicsLocation of the Character.
It creates another nice effect: It feels like you are accelerating because when the character starts to walk the camera is a bit behind
Applying forces should work, you just have to make sure you do it right, also the outcome might vary if you changed the accuracy. The wall and tower example works with both jbullet and bullet.
