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 ?
WRONG !!!
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: http://hub.jmonkeyengine.org/forum/topic/trouble-with-collisions/ )
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).