POV Horizontal and vertical input when world up changes

Hi,

Quick question, does the POV aim component in a virtual camera adjust horizontal and vertical input values to make sense against the world up override set on the main camera? I ask because it doesn't appear to and before I keep butting my head against a wall trying different configurations I wanted to see if that basic fundamental is missing.

My set up is that I have a world override set on the main camera to be a camera anchor object that is a child of the main character. The vcam is set up to be first person in that it the body is "Hard lock to target" and the aim is POV. The follow target is the camera anchor. In the scene, the player can arbitrarily change gravity and be oriented towards a different vector where world up changes from their perspective. Every time I do this, the camera is rotated correctly but the input is wonky, and it seems like the input is still the raw horizontal and vertical input according to real world up and is not adjusted / rotated in any way.

Of course I could also totally have something set up incorrectly!

I know that I could probably write a script to manipulate the input x and y values on the POV component to fix this but before I spent time doing that I thought I would pose the question.

Thanks!

 

Ah thanks for your very simple solution! Yes, that works as far as the camera orientation and input goes, but it does introduce a new problem for me (rabbit hole). I am also using the Kinematic Character Controller asset which uses the camera orientation to orient the character. So basically, the way the camera is facing drives the forward direction of the character. At the same time the camera is a child of the character (well technically, a child of the camera anchor which is a child of the character) so it is following the character, so you end up going around in circles like a dog chasing it's tail.

I don't think this is your problem to solve though, I think I need to look at the character controller script and refactor that a little to take the hierarchy change into account. Unless of course you have another quick hack for me

Thanks for your help so far! I'm almost there.

 

Sorry, I don't think I was clear. It's the vcam that is the child, not the main camera brain object. Still getting the feedback loop.

I understand what you're saying about the fact the controller should drive the vcam but I think that when you talk first person it's a bit of a grey area and it's almost like controlling the character becomes a "shared" responsibility between the viewport and the character itself. The direction you're looking with the vcam (so the resulting orientation of the main camera) drives what direction the main character model is facing (it turns in real-time with where you are looking). Giving directional input with the movement keys drives the character position IN THE DIRECTION the character is facing which is being driven by the POV. So you could say that the rotation of the character is driven by the POV while the position of the character is driven by the controller itself.

 

Thanks, sounds reasonable, I will try out that approach.

In case you're wondering I am using cinemachine because I also have a third person vcam that I cut to for certain cutscenes that behaves differently and uses more of the cinemachine functionality. I mention that because I know that strictly speaking, I don't really need to use cinemachine for pure first person and could just use a normal camera.

Lastly, any chance that POV handling world up properly could be added to the list? This would make it a complete first person solution in my book.

 

Great news re CM 2.6.0, thanks for the info. Do you happen to know when official release might be, if it's close then it might not be worth the effort for me to do the custom controller.

 

Shall do! Yep, I understand I still need to integrate it with the KCC controller asset.