I’m trying to determine if a hand controller is moving left, right, up or down based on the direction a character is facing in VR using blueprints. The problem i’m running into is only being able to find the world space vectors for controller movement and i’m not sure how that would be translated based on the cameras facing direction. Any help would be greatly appreciated.
On any Actor you can get the Forward Vector, and you can compare that to the direction of any other vector via the Dot Product operator node (looks like “.”). Dot product will return a value between -1.0 and 1.0, where -1.0 is exactly opposite direction, 0 is perpendicular, and 1 is facing exactly the same direction.
I’m not sure how to use this to tell left vs right, but you could always get the Right Vector and then if the dot product between that and the other vector is positive, it’s on the right side, and if negative, it’s on the left.
Your useful nodes for this will be Forward Vector, Right Vector, Dot Product, Actor World Location, and LookAt
I think i understand, i’ll try it out and see how it goes.
The problem with trying it this way is it’s based on the direction the controller is facing, not how it is moving, so it’s great to see what direction the controller is pointing in compared to the camera angle, which is a good thing to know as i’ve already thought of some uses for it, but it doesn’t help with determining if the controller is being moved left or right, think sideways while still facing forward.
So are you using the forward and/or right of the camera, the controller, or the pawn? And what are you comparing it to the forward and/or right of?
You can get character velocity and base the direction comparisons on that (may need to run it through a Normailze node)
was doing forward and right of the camera , compared to the forward and right of the controller, but it only gives the controllers facing not momentum, getting the component velocity of the controller is what i tried at first, but it definitely doesn’t behave as expected cause the velocity is always at 0.
Basically all i need is some way to track it’s velocity in local space in relation to the pawn it’s attached to the problem is everything i have access to from unreal tracks in world space so if the character turns around the directions are inversed, i tried finding someway to modify the x values based on character facing, but couldn’t get it to work right.if component velocity worked that would probably be ok, but all i have to work with right now is location of the component which as i said only tracks in world space.
That sounds frustrating. Would it be too laggy to cache the component world location every tick, and subtract it from the current component world location in order to find the vector of how far it has moved, multiplied by deltatime?
it would be finding out 1 frame or more after the motion takes place, instead of 1 frame before (as it would if we used velocity), but i think that could work.
I have a function set up for that already cause i use it for adjusting some particle effects, that still only helps with world space, i can’t figure out how to translate it to local based on camera direction, effectively what i need to do is determine how it is moving based on character perspective and assign it left or right for comparisons, with world space since depending on direction facing there’s no guarantee if the movement would be positive to negative x or y to figure out if it is left or right, if i had world space velocity from it is there some way to compare that to facing to determine direction of movement across the screen? or even if there’s someway to determine the direction it’s moving based on it’s own orientation, ignoring the camera would work.
and much thanks for helping me try to puzzle through this, it’s greatly appreciated.
I ended up finding a cheesy way around this by just measuring the distance between the left and right controller, if the distance is getting smaller it’s moving right, bigger is moving left. This will work 90% of the time which is enough for the purposes of the game. Thanks again for all the help.
hey a sinple elegant solution is always favorable