Walking player: Collison Detection & InputHandlers fighting over control?

1: I'm not familiar with ThirdPersonController, sorry, but using it to control more than just the camera seems unsuited to me when using physics.

2: forces, yes! the other things you describe in Q2 seem rather strange to me. Leaping?!? Why does it spin uncontrolled? Can't you control that spin (easy way would be constraining local rotation).

3: You need to approximate the walls of buildings with multiple boxes (e.g. not just one) or use triangle collision geometries (which is a lot slower).

4: not that boolean parameter, it's named 'allowRepeats' (or similar). In your first example you pass 'true' which tells the input handler to invoke your action every frame the key stroke (or any of the key strokes registered with the command) is valid. While you pass 'false' in the second example for the equivalent parameter, which tells the input handler to invoke your action once when the key is pressed and once when it is released…

Thanks for answering, Irrisor!


irrisor said:

1: I'm not familiar with ThirdPersonController, sorry, but using it to control more than just the camera seems unsuited to me when using physics.


OK. So it only worked in the sample because it had no physics? If anybody has a better solution, please share. :)

irrisor said:
2: forces, yes! the other things you describe in Q2 seem rather strange to me. Leaping?!?


The box seems to be affected by conflicting "forces", for one the physics, and then the ThirdPersonController. For each step I do by pressing W, the box's location is set a step further (no smoothly like a force), and it is moved there no matter whether there is a wall or slope at the target spot or not. When it gets stuck in a solid object, it shakes and sometimes it is ejected (the physics stuff understandably doesn't like intersecting solid objects.)

When I rotate by moving the mouse left/right, then the box just leaps in a curve as if it was pivoting around something... Hmmm... around the camera position it seems. Why does it turn in the demo, but leaps for me... Hmmm. The ThirdPersonController is calling files like ThirdPersonForwardAction.java etc, maybe I find an answer in them.

irrisor said:
Why does it spin uncontrolled? Can't you control that spin (easy way would be constraining local rotation).


Constraining local rotation sounds like just what I need -- where do I find out how I do that? Generally, not allowing it to pitch and roll would be cool, so the box/character stands always upright, even on a slope, is it possible to lock that?

can you post a screen shot - im finding it hard to visualise

A picture of what, of the “forcefield” effect?



If yes, here you go: I took the roof of my model and placed my box character right above it: It does not fall in, but floats in mid air:

pic1

pic2

Strangely enough, collision detection works – the box can walk on the invisible frontier (the “forcefield” seems to be bigger than the roof I removed.)



I can’t take a picture of whjat it looks like when I place the character inside, it just shakes a lot until the box is forced outside.



BTW something about the way I load the 3ds model is probably not correct, the colors look very strange. (Blender did not export any textures for it.)

to get a feeling of the physics geometry applied to your model display them with the physics debugger (in SimpleGame press [V]).



constraining rotation would be best with a joint that has three translational axes and one rotational - unfortunately ODE does not provide such a joint yet :(. But you can adjust the local rotation of your player after each physics step. Or you can apply couter-forces when your player starts to roll/pitch.

ThirdPersonController was not specifically written to be used with physics.  It is written in such a way as to directly move the controlled character rather than apply forces to it.  That said, you could do something like use it to control an invisible object that you read the forces from (ie, force the invisible object to 0,0,0, apply the controller, read the new position and apply the difference from 0,0,0 as a force to your real object.)  If you are also using ChaseCamera, make sure you set the camera target to your real object to keep it looking at the right thing.



Just to be clear, I haven't done the above myself, and I don't use jme-physics.  Hopefully though, the above is something useful to solving your problem.

Granted I did this quite a while back on a hacked-together project using jME-Physics 1 and an earlier version of jME, but here’s the code I released that supports it:



http://forum.captiveimagination.com/index.php/topic,85.0.html

renanse said:
ThirdPersonController was not specifically written to be used with physics.

Regarding the spheres - make sure that you specify box collision detection physics when adding your objects to the world, as I think it defaults to sphere. Which is useful for balls and whatnot, I suppose, but not very helpful for game world. I had a very interesting problem with square crates in my world rolling around… very disconcerting.

Phydeaux said:

Regarding the spheres - make sure that you specify box collision detection physics when adding your objects to the world, as I think it defaults to sphere. Which is useful for balls and whatnot, I suppose, but not very helpful for game world. I had a very interesting problem with square crates in my world rolling around... very disconcerting.


That sounds like just what is happening here! I found something called BoundingVolume.BOUNDING_BOX, but with which command do I set that?
And I assume I have to set it for each object? I can do that for players and trees etc, but the model I load is made of parts, I can't set the BoundingVolume for each part?

Bah. Am stoopid. Found it…


Phydeaux said:

Regarding the spheres - make sure that you specify box collision detection physics when adding your objects to the world, as I think it defaults to sphere.


PS:

Now all indoor walls and even surfaces interact with the player as expected.

However slopes now act as boxes, too.... Meaning the character cannot walk up ramps. Also, open door frames act like solid walls...

The ramps and door frames are part of the model I load, I cannot access them individually. (Or can I? Should I?) Of course I could remove all ramps from the model and insert them as jme objects... but that would make things very complicated. And I have no clue what to do about the door openings. Any hints?

PPS:

For forum users with similar problems: I could fix part of the bug of not getting up ramps and through doors by simply making the player bit smaller. Seems it just didn't fit through? the bounding box is bigger than it seems. This helped for all but one doorframe -- and it's a wide one, strange.

And in case anyone has a similar problem with colors displaying, but being too white: Activating linear light attenuation helped -- the light was shining too bright, so all the walls were blindingly white.