Hi there
Trying to do simple "physics" with Jme's collision system and bounding boxes, but i don't get it working.
Till now, a friend and me, we invested much time into this problem, buying physics books and reading tutorials on gamedev.net, gamasutra etc.
The background:
It should be a simple spatial controller, which has a velocity and is designed for moving.
Every Update, it moves the controlled spatial and checks if it collides with a certain node tree (branch), eg. walls.
Basically it should be simple Physics, like a first person shooter eg Counter Strike, with possibility to "slide" along walls.
I don't want to handle it with JmePhysics / Ode etc, because it would be overhead. (Nothing against it! Its great - for games with real physics)
Experimenting with JmePhysics 2, i think realising for example a shooter is very complicated (eg. the Mouselook with physics and forces?!)
There were some Threads about it recently:
http://www.jmonkeyengine.com/jmeforum/index.php?topic=4031.0
http://www.jmonkeyengine.com/jmeforum/index.php?topic=4057.0
Other articles:
http://www.gamasutra.com/features/20000208/lander_pfv.htm
I think it could be possible to create a PhyiscsNodeController and attach it to a simple Node for basic Bounding Collisions.
You could add this simply to a node with a FirstpersonController and have your simple FPS…
Also i am wondering about nobody has the same problems. Nymon took an approach to get it working, but
his code doesn't work if velocity is a little higher and eg. if you try it with a box instead of a sphere.
Jme is my favourit game engine, but as deeper as i get into this problem the more i am disappointed - my friend i mentioned above already has resigned -.-
If there is already a solution, please let me know. Or am i completely on the wrong way, and perhaps am not qualified for solving this problem?
Any help, comments and proposals are welcome.
Regards
snare
edit: Typos
Jme is my favourit game engine, but as deeper as i get into this problem the more i am disappointed - my friend i mentioned above already has resigned -.-
has jme ever claimed to have built in physics? or why are you disapointed? has your friend resigned from using jme cause he couldnt make physics in java that worked with it?
Maybe he just means he is disappointed in his failure to make a collision system 
I know I've felt that way myself, a simple non-realistic physics system is harder than I thought it would be
I've also been trying to get something similar working for aircarrier, at the moment I am using jme physics, but since I don't want realistic physics it is tricky, so I have to use quite odd physics settings, and override the physics behaviour when the plane is not colliding.
I would say that if there is one single thing that would be most useful in allowing for simple games to be written using core jME without too much extra code, it would be this simple collision stuff, since pretty much everything else needed for a game is already there. I know that in my game, by far the most difficult thing has been working out how to get bullet and plane collisions, and I'm still not happy with how it works. Most game ideas seem to hit the stage of "Ok, I've made a little man, and a level to run around in, now how do I get the little man to walk on the level … oh, I can't…" 
Even the flagrush tutorials seem to stop at that point, IIRC
In fact in general, the bounds/ray tracing/collision code seems to be the least well developed. OBB is a little odd, ray picking seems to generate quite large amounts of new objects that cause a lot of GC in my game, and there is no simple physics for dynamic objects sliding off static ones.
I've been thinking about ways to do the sliding collisions, but it seems it would need true bounds collision to get the first point of collision for a moving bounding object with a static one.
Sorry if none of that makes sense, I'm still a bit jet lagged from holiday
Mh i was a little disappointed because i didn't know where to start. Now i found Nehes Lession 30 and iam building ontop of it a simple "PhysicsController". Lets see if it does what i want…
The friend of mine says that information about jme, like tutorials, API Documentation etc is "organized by chaos" and if he is searching sth he doesn't find anything…
Sometimes, searching information about hours for a simple question, i am digging into the source and learning by doing. This is hard work, but it doesn't bother me.
has your friend resigned from using jme cause he couldn't make physics in java that worked with it?
I think so...
We started several Projects with jme. And unfortunately we never finshed any of these projects.
In my oppinion, the main reason why we failed was on the one hand the physics and on the other our expectations were to high.
The physics, because generating a game play like eg Counter Strike is for example with JmePhysics and its forces not practicable and with Jmes collision detection much work (The vector math is tricky in my oppinion).
Btw, i have a question:
Is there a simple solution in calculating the normals of a boundingbox at a specific point?
I have the intersection point (from IntersectionRecord) but i don't know how to get the Normal of the box at this specific point.
And i digged through the source but i there was no result :P
While writing this post shingoki answered, and i totally agree wtih him. Its nearly the quintessence i am thinking about this ^^
Greets
Snare
I am doing a flagrush mod for bit of practice and adding collision handling and sideways drift(power sliding) has been tough going, i have also tried nymon's code and the bike bursts though the walls, I say burst because you can tell that the code is trying to work fps drops to between 2-7 when I hit the fence.
Yes i have the same problem.
The rason is the high speed: The code only tests if there is a collission at the end of the movement in this frame, and if the Wall for example is between these tow points, there will be no collision. Normally this behaviour results in beeing stuck into the wall…
I am currently writing a simple physics controller, which hopefully will handle this :P, but dont know if and when it will be finished.
Greetz
Snare
okidoki got your point!
a collision system is very much needed, and were just fighting over who should do the jni wrapping
suggested solution is to wrap “Bullet” with “Noodleglue”.
http://www.continuousphysics.com/Bullet/
http://www.noodleglue.org/noodleglue/noodleglue.html
I couldn't find the thread with the collision detection discussion… so I assist in hijacking this thread for it :P…
If you guys really want sophisticated collision detection in jME, what about integrating jME Physics 2? Probably without the dynamics? Or with dynamics that can be turned off?
ODE already works with bullet (and even gimpact) so we would have bindings for it…
It can't be good to keep having separate collision detection systems for 'simple' and 'sophisticated' physics.