Head eyes Camera - maintain UNIT_Y up

Troubleshooting General Help
1

Hello monkeys,

recently i wanted to create “true” player body with simulated real torso/head movement.
i currently dont have idea how to easly solve this, but i belive some of you might know nice math solution.

what i have:

  1. getNodeAttatchment of HeadBone

  2. add new node with some translation(front of head) to 1) point node

  3. attach camera to CameraNode inside 2) point node
    (so camera rotate exactly like head)

  4. rotate head like this:

     character.headBone.setUserControl(true);
 Quaternion headRotation = defaultHeadRotation.clone();
 headRotation.fromAngles(FastMath.DEG_TO_RAD * rotationX, FastMath.DEG_TO_RAD * rotationY, 0);
 character.headBone.setLocalRotation(headRotation);

Problem:
When headBone parent like neck or upper torso are rotated in below/up direction, then when i rotate head it will not rotate maintaining up Vector. up Vector is different based on parent elements.

Question:
How to fix up direction for headBone in this situation?
(please note i cant use lookAt with UNIT_Y vector because it will disallow looking up/below with head)
Also it would be nice to not have UNIT_Y “instant” up vector, but make tpf affect and change it.

im really tired of this math :smiley: so any help really appreciated.

here is video to make you more understand the problem:

2

I would suggest leaving the camera in world space and just manually moving it to the spot of the head bone, then rotating it as you want. CameraNode is overrated.

That should leave the rotation consistent.

1 Like
3

when i leave it in world space, and update each frame location, somehow i got more “jumping” due to physics i think.

i use BetterCharacterControl, but it dont work well for me anyway so idk if change it later.

but maybe i did something wrong, i will prepare some changes due to it

4

about issue i got when camera is in worldSpace (rootNode) and its position is updated to boneAttachmentNode each frame.

video below(yes rotation is ok, but there is other issue):

this is everything i added:

    getCamera().setLocation(this.character.eyeCameraNode.getWorldTranslation());
    getCamera().lookAt(character.headDirectionControlNodeEnd.getWorldTranslation(), Vector3f.UNIT_Y);

and removed cameraNode from bone attathment node.

as you seen in previous video if camera is in cameraNode inside “eyeCameraNode”(bone attatchment) then this issue dont exist

maybe its about physics update its spatial somehow in earlier frame than location i get is updated itself.

5

anyway thanks to your suggestion i managed to make ugly solution for this. i am unable to partially update it by tpf (but maybe will find way) anyway it works.

camera is in armatureNode, position is updated to have related position to armatureNode and used lookAt to manage it.

camNode.setLocalTranslation(this.character.eyeCameraNode.getWorldTranslation().subtract(character.node.getWorldTranslation()));
        camNode.lookAt(character.headDirectionControlNodeEnd.getWorldTranslation(), Vector3f.UNIT_Y);
6

Yeah I had that problem with the stuttering myself a handful of times, still not entirely sure what solved it in the end, but I think it had something to do with moving the camera in the simpleRender method after everything else. So you can try that to see if it’s any better I suppose.

1 Like
7

Yep, update the camera as late as possible. AppState.render() is the best place, IMO.

1 Like
8

thanks, will try for sure.

edit:

yes it work perfect in render method.

1 Like
9

a thread issue is solved, but if someone will maybe know why below video issue appear, it would be nice.

when there is white screen, trully character is in position NaN,NaN,NaN (issue) :rofl:

i will try solve this later, so if someone know earlier, please tell. myself i belive that character is thrown? or something. but NaN values are very odd… its a betterCharacterControl

10

Position NaN is usually caused by a bad Quaternion somewhere… but with physics things may be more complicated.

1 Like
11

this only appear when moving through door. door is kinematic(and when open, it stop changing rotation) and house not.

i will look more into it later, but its really odd. i do not rotate anything on physics contact.

12

Do you use native bullet?

Try setting it to a fixed timestep with no smoothing. (I don’t know if that’s possible in JME’s bullet app state stuff.)

In my SiO2 bullet integration, sometimes my position would go NaN when using native bullet and I traced it down to teeny-tiny catch-up frames in the ‘smoothing’ logic. I could not track it down in the native code and have opted for fixed time steps and no smoothing in the mean time.

13

im not sure how to set fixed timestep. in api there is only setAccuracy that dont help also.

issue exist both in 3.2.2 nativeBullet of JME and Stephen Minie lib. (if i test it correctly)

when i test it more, its when BetterCharacterControl collide with Door (rigidBody mass 0 kinematic true)

disabling door open control do not remove issue(so not Quaterion anyway), colliding with them just cause it

in earlier development i were not using physics so maybe i just do something stupid.

14

Yes, for me it also happened when contacting a kinematic object.

I call the PhysicsSpace directly in my code but if you are hunting for a way to make JME do ‘the right thing’ then find a code path that calls:
https://javadoc.jmonkeyengine.org/com/jme3/bullet/PhysicsSpace.html#update-float-int-
…with zero as the second parameter.

1 Like
15

ok will look at it tomorrow. thanks Paul :slight_smile:

16

wanted to see where this update method is executed. but i got JME source debugger problem.

hmm, since i use gradle i did not try debug JME code.

how can i do it?

i tried have both sources and compiled libs, debugger dont catch breakpoint in source lib.

checking manually i see pspace update method in bulletState, but with one parameter only.

17

I don’t know… in like 20 years of Java development, I’ve run a java debugger probably twice.

Yeah, by PhysicsSpace calls itself:
https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-bullet/src/main/java/com/jme3/bullet/PhysicsSpace.java#L465

So if you can figure out how to set that to 0:
https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-bullet/src/main/java/com/jme3/bullet/PhysicsSpace.java#L1246

…you may have something.

1 Like
18

yes sorry, i forgot to mention. when you mentioned about “steps” param i found this “setMaxSubSteps(0)” method.

i changed it to 0 in SimpleInit, but it made some issue and character were somewhere in space instead of on ground.

i even tried set 1 in simpleinit and on later stage set 0 and same issue. i see no collision elements in space. (player is just in empty skybox scene)

i can make video if need, but it will show nothing, just player in empty skybox scene (looking up/down i dont even see other elements)