Movement along x and z direction (left and right) not working as expected.
Movement along y (up and down) works.
Here I am trying to move box2 to right (+ X) but box2 moves to left (-X).
same issue in righthanded system. (uncomment line 4).
Or am I interpreting “Mesh.definedFacingForward” incorrectly?
In the code, the right (X) and forward (Z) amount are multiplied by -1 if
definedFacedForward = true, that’s why you need to use a negative amount for right if you want the mesh to actually move to the right (or set
definedFacedForward = false).
Maybe @JCPalmer can shed some light on this as he did the PR (a looong time ago!).
Received. That was probably late '14. Doing this from memory. Wouldn’t be till tomorrow that I could do better than that. Theory follows:
POV movement allows for a character mesh to move say 3 units forward & 1 to the right. That’s the mesh’s “forward”, & mesh’s “right”. The mesh could be anywhere, rotated in any way. You do not have to care.
POV movement really pertains to how the mesh being defined in an external program like blender. In order for a Mesh to move in terms of the mesh’s own “Point of View”, that being in terms of its current position and rotation, you need to know what is the “front” of the mesh.
There is a switch so the mesh could be defined facing backwards & exported that way, and this would be taken into account.
Think you may be trying to move from a world or camera point of view, not the mesh’s. A little tough to know what is the front of a cube is, defined only in code without export. As long as there is no rotation, things should be close to world (the mesh’s world), except relative. Once the character has turned, this makes it so you do not have to know where it is starting from or pointing.
I still use this in my animation system, though I pasted & use the code from there now days. I can queue a sequential list of animation events, say: move, turn, & move while turning. Who cares where it was prior to any animation event. It seems more OO for mesh to move according to it’s own terms. I do a lot of mesh sub-classing, & the animation system has a large presents in my base sub-class. It works for me.
I was refactoring my CharacterController (which I hadn’t touched for quite a while) and found that calcMovePOV() wasn’t working quite the way I was expecting it to work .
Also wasn’t aware of “Mesh.definedFacingForward”.
My understanding of mesh.calcMovePOV() was that given a vector in the Mesh’s local frame of reference , it would provide the equivalent vector in the global frame of reference.
Looks like “Mesh.definedFacingForward” was added later on to decide which face should be considered “forward” (facing local + z axis or -z axis) and based on that adjust the global vector accordingly.
Based on what I am seeing, by setting it to true we are telling it that the mesh forward face is the one facing -z axis.
Am I correct ?
Yes, that’s my understanding.
An update to the doc highlighting the link between method and property might be helpful .
I have created a API typedoc change pull request for that.