Does anyone else notice that using a PhysicsCharacterNode vs a PhysicsNode for the player character reduces their framerate by at least 5fps.
I’ve tested it several times, both in Alpha 2 and Alpha 3, as well as some nightly builds in between.
Any ideas on why it is like this?
Not really, I changed back a commit by tim8dev where the ghost node would constantly check for overlapping objects instead of only when its requested, but I dont know if that was after alpha-3 or before.
I switched it back to only check overlapping on request. It’s dropping the framerate by about 30-45%
Since the JME actions are quite minimal I think the issue lies in jbullet. I am using the height-field collision shape currently, so that may have something to do with it, but I’ll look into it further to see what I can find within jbullet that might slow it down.
I’d think the kinematic character controller would be less intense than a rigid body.
The current pc I am using only has an intel integrated graphics chipset.
I see a drop as well on my desktop, but it’s not as significant, probably around a 10-20% drop, but the overall fps is 50x higher.
I dont understand why you “switched it back”? In the current svn its only checked when requested, how can checking it every frame yield more fps? Anyway, as you say theres not much going on in jME, so its all a question of jbullet performance I guess. Maybe you can find more infos about this on the bullet forum. Also, be sure to have assertions disabled, they are a pretty big performance hit in the physics and might be more excessive for ghost nodes, idk.
Ok I’ll do that.
By switched it back, I mean I switched it to check when requested, not each update.
Because that is how it was set in the code I currently have. Or at least in the Source for the libraries, maybe not the compiled versions distributed with Alpha 3.
Uhm, I dont remember anymore, it think it was not in Alpha-3 but if you update to the latest nightly (Tools->Plugins->Settings) then you should have the version with on-demand checking.
I think it’s because of the movement loop in the kinematic character controller.
in stepForwardAndStrafe
…
while (fraction > 0.01f && maxIter-- > 0) {
The above happens each physics update, along with a penetration check loop before it.
I removed the penetration check loop and performance did not increase.
It could be something else, but there’s alot of stuff going on within that while loop, so it’s my best guess.
I’m going to go back to using Rigid Bodies,
Success using rigid bodies,
Rigid body is set to static kinematic mode.
And I handle moves after updateGeometricState is called in my Master node.
I’m using Rays to handle terrain collision, very accurate and quick with some modifications to the BresenhamTerrainPicker
I posted in contributions, what I did to it, not much…
If you are there, also check out my terrain smoothing algorithm, it is pretty quick and makes terrain look more natural, although it will flatten out huge spikes pretty quickly.
The result is a high performance kinematic character controller that interacts with physics objects as well.
The potential is also there to toggle between kinematic and rigid body mode with a simple function call.
For instance if when a character dies ragdoll is needed.
I suggest to anyone running into issues with the kinematic character controller to do the same.
My movement across terrain is completely without jitters as well, since I am handling it in jme.
Cool, any ambition to pack this character up in a nice class and contribute it? For the picking, theres also a (newly added and currently untested) rayTest() method in the PhysicsSpace, when using that you dont have double collision data (from the geometry and physics)
I will pack it up into a class when I can, but it still needs some work. I have movement perfected across smooth terrain in high fps situations, as long as the ray tests don’t fail. So I’m currently addressing the issue of collision in low fps situations, and also I need to get the ray tests to always return a value when they should. Something is wrong with the picker so it is less likely to return a value in low fps situations. But with high fps it doesn’t matter so much since many more collision calculations are able to happen per frame.
I’m currently using 6 rays, but this could probably be optimized depending on the shape of the character.