CharacterControl related problems

I bet you’ll find this fun.

Yeah, you know why i decided to use jme ? Cause i HATE to have to handle collisions myself, cause i HATE geometry and collisions are all about geometry.

So, i saw some videos showing how explosions can move bricks and stuff like that and i thought “oh my god, this is awesome, this is WAY more than i need”.
After all, i don’t need bouncing balls, flying bricks and so, i ONLY need something that handle collision detections, so my char won’t pass through walls. Oh, and yes, i want to be able to change the gravity. Not a big deal, huh ? when the physic engine can handle such high physic simulation.
After all, gravity is only a constant acceleration in a direction.
Plus, it seems that jme use nodes so i won’t have to do some calculation about the absolute position of items, everything will be relative.
Hey, it will be easy to do that right ?


I think that in my life of developper i never met a class i hate that much as the CharacterControl class. But, THIS class (what i thought it was) was the reason why i chose jmonkeyengine.

Ok, so let’s summerize:

CharacterControl has a setGravity method. BUT : this method only take a float, not a direction ( (x, y, z) e.g. vectof3f). Why ?
I bet that devs thought : “of course, let’s do something to change the gravity BUT it’s obvious that people will only need a vertical (y) gravity”.
Ok, you can set the value to a negative number. But then, it’s bugged. Yes, i already made a topic on that : the charactercontrol warp endlessly when it hit a surface above him.
(look here: )
So, maybe i am wrong, maybe i am not suppose to change the gravity direction, only it’s strength.
So, WHY there is a “setUpAxis” ?
Ok, you can change the upAxis to a value in {0, 1, 2}.
0 is the X axis, 1 is the Y and 2 is the Z.
SO : you can change the gravity direction BUT only in 3 direction. Yes, you cannot set the “-y” value or the “-x” or the “-z”, or you’ll warp endlessly when you’ll hit something.

Fun thing : this values (0, 1, 2) match the indexes of an array in the KinematicCharacterControl. Why it’s fun ? It’s fun because if you change this arrays (for exemple if you add more values) everything with collision is handle properply (no more warping).
Yes, you can even use strange vector (not a canonical one), it’s perfectly fine. Yes, negative gravity has a bug, but change the axis to its negative value doesn’t.
About nothing : (0, -1, 0) is not equal to (0, 1, 0).negate. Why ? Cause (0, 1, 0).negate has the value of (-0, -1, -0). Yes, -0. No problem, right ? I know about is ieee754 and so, but we are in java, and it’s not “==” it’s the “equal” method.

Ok, let’s go back to this wonderfull charactercontrol.
So, you can change the up axis. BUT ! this doesn’t change the direction of the collision shape.
So, you fly to the wall but you capsule doesn’t change its direction. Nice feature, was mandatory.
Ok, maybe i missed something, a method like “updateCollisionShapeWithUpAxis” or any boolean value like that ? No, afaik no.
But, hey, i am a computer scientist, i can do it myself.
So, why don’t use the “setCollisionShape” method of the amazing charactercontrol class ?
You know why ? You know why ?
Cause this method is bugged, YES !
Even in a correct librairy, some class can have problems with some methods (they cannot give a proper implementation of the method).
But, in a correct librairy, you either get an exception when you invoke the method OR you have a warning message in the log and the method return without doing anything.
No, CharacterControl is way too smart to do that. No, characterControl prefer to just bug and bug and bug. Here, namely, you just start to sink in every object and you can pass through walls just by walking.
Ok, i’ll find why there is a bug and fix it.
Oh, i am stupid, there is no source code, only binaries.

But it’s ok, let’s just remove this characterControl and create a new one with the correct collisionshape and the correct direction. After all, i don’t change the gravity each frame at all, only “times to times”.
Hey, it’s seems it works.

But NO, it’s not possible, it’s charactercontrol after all. You know what ? Now, all others collisionlisteners (not related to the node with the charactercontrol at all) will have a PhysicsCollisionEvent with “null” in the a or b node a collision with the charactercontrol will rise.
Everytime ? Seems to be an … almost “good” bug, consistent. NO, it’s not possible.
Only the first time.
Yes, if you do something like “if (event.nodeA==null or even.nodeB==null) then return” you “remove” the problem, you “skip” the first collisiondetection and others are corrects.

but hey, i can solve this right ? After all, i am a computer scientist.
Let’s move to the source code and find why this happen.
Oh, i am so stupid, there is no source code. Yes, this librairy is so awesome that we NEED to compile it. Bullet has 0 bug, it’s even better than the unix core, let’s compile it, nobody will try to change anything, it’s too perfect.
What what what ? Java is now as fast as c++ because it’s compiled “on-the-fly” ? Heretic ! how dare you ?

Man, is it possible to have a class that control player and allow me to change the gravity in a proper way ?

(i didn’t talk about setViewDirection, but it doen’t work)
(i didn’t talk about the “fall at a speed not related to gravity when fall without jumping”… it’s a nice feature. Oh, and of course, not related to gravity BUT framerate related. It’s charactercontrol after all).

So what exactly do you want to cause with this post? You complain about a feature of an external library on another forum than the one that belongs to the library.
We use a modified version of jbullet but changing its source will not help you a lot as we will move the code to native bullet with a future release. Thats also why obstructing the jbullet code and its origin is well intended. Add to that the jbullet developer is not very communicative so even if you improve his lib you might only find out half a year later when he actually incorporates your patch.

i ONLY need something that handle collision detections, so my char won’t pass through walls. Oh, and yes, i want to be able to change the gravity. Not a big deal, huh ?
Well, why choose Bullet then? You should be able to create those functionalities with "pure" jME. (Although, without spending too much time on it, it wouldn't be as performant and smooth as Bullet is)

CollisionDetecting: RayCasting-collideWith methods
Gravity: setLocalTranslation(getLocalTranslation() + some-mysterious-gravity-parameter-that-you-surely-can-figure-out);

Why complaining and beding rude about a class that was made for quick tests? :slight_smile:

Also, just setting a RigidBodies velocity continuous will probably much more react like you expect it to. The character is just a ghost control and a kinematic rigid body, it has no “real” physics. But still I have to wonder what the point of this rant would be?

the point of my post is to say that

  1. maybe bullet is not THAT good and jmonkey should look for an other physic engine
  2. on the tutoriel, you have a short message saying “charactercontrol is poor and maybe the staff of jme will release a better version of that in the futur” (to make a long story short). Is this still true ? I mean : is it still on the agenda ?

most problems (not all of them though) come from the charactercontrol. And unlike a lot of other thing related to games, create a charactercontrol is not trivial.
So, have a strong and very reliable charactercontrol should be on the top of the “todo” list.
Why people use game engine to make their games ? To don’t have to recreate the wheel and a cubic wheel (as they won’t do it well most of time).

JME with its node system is very strong and very pleasant to use. You attach node, you make them rotate, you translate them ect and everything work like it’s suppose to work.
You want to create a planet with moons ? No problem, just put a pivot (and one for each moon if you want) in the center of the planet, translate the moon and rotate the pivot and magic, it works.
You want to put it in the background ? Just some lines and it’s done and you’ll never have to come back to it.

This is good, this is very pleasant.
bullet is like a pebble in the shoe. Everytime you do something, you’ll find some new problem with the ccd, with objects passing through walls, with controller that store more datas than they should (charactercontrol always refer to its spatial position to know its physic position - and it’s a good thing. RigidBodyControl store the physicposition in itself and so you cannot have many controls that change the position in turn), with strange restitution behaviour (put a ball with full restitution on a ground with no restitution and the ball won’t rebounce - the ball should bounce if the ball move to the ground)…
Everytime i use bullet, i find bugs, i find problems and everytime it’s for a stupid reason or, worse, for no reason.
Bullet even don’t have a mathematic approach ! Yeah, i expected it to perform some extrapolation of the movement to detect collision before they happen and so don’t have a “per frame” collision detection. I mean : when i throw a ball, i know its trajectory and so i know where the ball will land.
Of course it’s easier to implement a simulation where i move the ball a little each frame and check if there is collision, but it’s less efficient for the GPU and it suffer from bugs (bullet through paper).

I am still waiting for a moment where suddenly i will say “omg it’s awesome” as i said for the scenegraph part of jme, but i doubt that this will happen.

I don’t think that integrate such a poor physic engine in jme is good for its sustainability.
I far as i am concerned, bullet is bullshit. The caractercontrol class is the most obviously deficient part (as we met it very soon), but the whole “simulate and recover” method was maybe good in 2000 but it’s now out of date.
Jme needs good foundations and bullet is not one.

  1. Nope, bullet is great, I think your view is mainly fueled by your frustration, did you work with physics or game engines at all yet?
  2. Yeah.
@bubuche said: Ok, you can change the upAxis to a value in {0, 1, 2}. 0 is the X axis, 1 is the Y and 2 is the Z. SO : you can change the gravity direction BUT only in 3 direction. Yes, you cannot set the "-y" value or the "-x" or the "-z", or you'll warp endlessly when you'll hit something.

I didn’t catch all of it but this sort of jumped out at me as a concern.

Setting an up axis to (0,1,2) doesn’t really make any sense. This is a direction vector so should be of unit length… it can point in any direction, though. It may not be doing what you intend either way. This just hinted at a fundamental misunderstanding in 3D math.

Edit: never mind. This shows my complete ignorance of the bullet API.