While you didn’t ask for further help, I’m not ready to give up on animated mesh collisions quite yet.
Quaternion.fromAxes() assumes its arguments form an orthonormal basis. Passing ZEROs to this method results a non-normal quaternion, so I suspect the code quoted above is putting the camera in an invalid state. To point the camera directly away from the mesh, I would use Camera.lookAtDirection(), reversing the (sign of the) direction but keeping the “up” vector unchanged. In this case,
cam.lookAtDirection(new Vector3f(0f, 0f, 1f), new Vector3f(0f, 1f, 0f));
You’re correct that something breaks when the mesh isn’t rendered. I looked into this, and it appears the bounding box isn’t getting updated. I don’t fully understand the mechanism. However, this optimization can be defeated by setting
rootNode.setCullHint(Spatial.CullHint.Never);
It’s considered good practice treat the scene graph strictly as visualization data and keep your game objects separate. This explains why mesh collision is optimized for picking (user interface) but not for simulating laser beams, collisions between solid objects, or character sightlines or foot support.
For those functions, I believe most people use Bullet physics or custom code.
Even in software skinning, the animation code doesn’t bother to update the mesh if it’s not being rendered on screen as that would be a huge waste of CPU.
You can easily force this to happen just by calling the same method that the rendering pipeline does to get controlRender() called (or grab the control an call controlRender() on it). On the spatial, this would be: runControlRender(RenderManager rm, ViewPort vp)
The solution I eventually used was @Darkchaos’s suggestion of adding a box to the attachment node of the bone. This is fine for working out whether an NPC can see another character. For working out whether a bullet hits a character, I’ll probably try @nehon’s suggestion of using a KinematicRagdollControl, and then calling PhysicsSpace.rayTest to test for collisions with the rigid bodies it adds to each bone (if my understanding of how it would work is correct). But I’ll leave that for another day.
If you’re working on a FPS don’t use a Ragdoll.
Usually a Ragdoll is when each bone is connected by a string, much like a puppet. I don’t know if it being kinematic keeps the bones in place, but the problem you might encounter then is how to combine a Ragdoll with BetterCharacterControl so you can have the npc walk around and jump and stuff.
What I’d suggest you to do is manually adding stretched spheres and boxes for relevant bones (like who needs different values for each toe or similar: Should a toe be shootable at all).
I’ve done it in very basic form here, you can see the dark-blue hitboxes, the red lines are the individual bones and the cyan box tracks the location of the head and back bone.
Yes you have to do it manually but this also comes at the benefit of tweaking the boxes, for instance you could have a bigger head hitbox than the head actually is, to simplify headshots and the like. That way you not only know which bone was hit but also have a lever to play around for game balance purposes (and you could always use the foot-mesh poly reduced if you wanted to shoot toes).
One thing to note though is that collideWith currently does not operate on a List of Spatials, so you can’t just say “Trace all Hitboxes and obstacles (the world geometry)”. You could only run it on the rootNode which would also have the high-poly player/npc models and the guns itself.
Everything I know about ragdolls is from the TestBoneRagdoll example. With that, the model doesn’t act like a ragdoll until you call KinematicRagdollControl.setRagdollMode(). From what I can tell, until that point, the KinematicRagdollControl doesn’t have any effect. So, that might mean it’s perfectly compatible with BetterCharacterControl.
As it happens, I’m not planning on using BetterCharacterControl anyway, but I’ll give the ragdoll solution a go, and if I run into any problems, I’ll try what you suggest instead.
Regarding what you say about collideWith, you could copy the implementation of Node.collideWith, but make it iterate through a Collection of hitboxes and obstacles. That’s precisely what I’m doing now.