Now, the tutorials do a bunch of ugly bad-practice bullshit. One of which is having controls implement PhysicsCollisionListener. It’s not smart. It’s stupid. The tutorials are often stupid like this. They did it to reduce one or two lines of code but it just confuses new users. It’s unfortunate, but there we are. Do not ever look to the tutorials for best practices. They are illustrative of functionality but are the dumbest source of best practices.
Yes, if it’s being called. We can’t see where it’s called. We only see tiny little windows of your code. For all we know if could be in a thisMethodIsNeverCalled() somewhere. So we’ll assume it is called. My point is that we (the readers) can’t know that for sure. We don’t see it. We have to add our own assumptions on top of yours… which is not the best way to solve a problem.
I’m not sure. I figured it out without having to look at working examples… but my own examples are not using JME’s RigidBodyControls (and they have non-kinematic objects so I may not hit the same issue).
As mentioned already, I’ve seen others post issues with getting collision events from scenes with only kinematic objects. So if I were you, that’s what I’d try first. Add some mass=1 balls flying around the scene or something and see if you get events.
Thanks!!!
Finally some progress!!!
I’m getting collision events in the listener now after adding a Sphere with mass=1 to the scene
I guess having at least one object with mass>0 triggers the collision detection. Makes sense…
Any ideas how to work-around this limitation? because switching to using non kinematic objects will probably lead to a major refactoring in my product. So I guess my question is: is there a way to force / trigger the collision detection in order to get collision events?
I don’t care manually timing & invoking the collision procedure.
Last thing I wanna do is put a hidden sphere with mass>0 in my scene…
I think I will at least try to switch to using mass>0 objects and see if I can make it work without breaking everything.
Just one question - in my scenes I rotate objects to specific degrees for example: myNinja.rotate(y+45) in 2 seconds
This rotates the ninja around the Y axis 45 degrees in 2 seconds
And:
myNinja.move(x+2) in 5 seconds moves the ninja on the X axis 2 steps (meters) in 5 seconds
Can I achieve this kind of precision while working with bullet physics? or everything is reaction to forces and the ninja will not stop moving/rotating unless something stops it.
Note: to move physics objects you need to move the rigid body and not the spatial. The spatial is just the view.
You can move them however you want… but collisions will probably make them react without your involvement. And you might get explosive behavior if you move things too far interpenetrating or whatever.
bullet was not really meant to be used this way, I guess.
As explained in the tutorials, Bullet rigid bodies come in 3 types: static, dynamic, and kinematic.
Setting mass=0 makes the body static, meaning it can’t move.
A dynamic body is a body whose motion is determined by forces (including gravity and contact forces).
A kinematic body is a body whose motion is specified directly. To make a RigidBodyControl kinematic, instantiate it with positive mass and invoke setKinematic(true) on the control.
By the way, MeshCollisionShape is intended only for static objects, so it’s probably not what you want for your character. For a kinematic concave object, use GImpactCollisionShape.
Also, note that in jme3-bullet, changing the scale of a kinematic RigidBodyControl does not update the scale of its collision shape. I know because I added an option for this in my Minie library.
Thank you guys for all the great information. I’m now having some collision detection working in my scene.
I started refactoring my code to use full physical support (non kinematic objects) but almost immediately backed off because of the poor performance on my Android device.
My product is an Educational computer language for kids so I can live with all kinematic objects in my scene and even create simple games but I see that using JME + bullet physics on Android device introduces a big performance hit (at least on my modest device) .
In my experience, the performance of Bullet depends a lot on the collision shapes used, with spheres being the most efficient and GImpact shapes the least. But I’ve never built anything for Android, so your mileage may vary.
In my experience, I had to use parallel threading on the BulletAppState. It reduces lag spikes drastically. You have to remember that mobile devices usually consist of many low-powered cores. Contrary to PC’s where single-threaded performance is the key to a high-fps game, mobile devices almost certainly require evening out the load across the whole CPU(s).
You cannot just put a PC game on a mobile device and expect it to work. It requires a whole different workflow and completely different considerations to work with. Physics should be used sparingly, faked where possible.
You should first write your game knowing it will run like crap; learning why and how to get around it, and when you feel like you’re confident in your surroundings, attempt a first-run of a real game.
