Setting Free Look's aim direction

Hello all

I'm currently trying to polish up some cinematics. Unfortunately, I seem to have a problem with the transitions.

So I'm transitioning from a virtual camera (that's looking at the player) to a free look camera (that uses POV and following the player). I am setting their priorities in order to accomplish this. From here, once the transition completes, the player's camera returns to what his view was before the cinematic was started (ie, pointing above, left or even behind).

My objective right now is to have the player's camera pointing in the same direction the player unit is facing once the cinematic finishes. The first thing I did was enable recentering on both axes of the FreeLook camera when the cinematic begins. It did result in the camera facing the same direction at the end of the cinematic, but the camera would actually transition towards world Z vector before snapping to the proper direction in a single frame.

Video:

I tried a couple other things:

1. Enabling recentering on all the FreeLook's child rigs (No noticeable effect)
2. Enabling Inherit Position on the FreeLook's Transitions options (No change in behavior, although it does randomize the end direction if the recentering changes are reverted
3. Set FreeLook's Standby Update option to "Always" (No noticeable effect)

From observation, it seems as if the FreeLook's child rigs' POV values aren't being updated during the transition. Using the video as reference, you can see that the FreeLooks main X axis value is 90.0001 while the child rigs are stuck at 0 (recentering is enabled). Then the child rig values snap to the main value when the transition completes. I've attempted to change the child rig values in the inspector during the transition but they revert to 0 on the next frame (both with and without recentering enabled).

Is there any way I can work around this and achieve the effect I need? Or am I going about it wrong and there's actually a much simpler solution for it?

Thanks!

 

Hello. I use this strange combination due to the way I need the camera and player to interact. Instead of turning the player and the camera following, the camera rotates independently around the player who then turns to "catch up" to the camera's current rotation. On the other hand, the camera rigidly follows the position of the player + offset.

I built the rig way back in Unity 2018, I think, but I recall that without using the POV and adding to the main X Axis Value, the camera would continue facing in one direction even as it orbited around the player. I also used the Heading Bias variable to control the shoulder offset because the Offset extension did not work with the Collider extension. The Camera, FreeLook and VirtualCamera objects are also not parented to the player.

I don't have a LookAt target in the FreeLook. Is a LookAt target required?

In any case, it's all working splendidly aside from the issue above.

Feature:

 

At your suggestion, I redid the FreeLook using a LookAt target and Composers for the rigs. I got it working relatively close to my old view and it now does recenter during the transitions, but it came with some caveats.

1. The LookAt forces me to use the CameraOffset extension since the camera will always look at the target regardless of HeadingBias.
2. This results in CameraCollider extension only kicking in if the obstacle is directly aligned with the player and not the camera
3. When the CameraCollider moves the camera due to an obstacle, the LookAt makes the view move without any input from the player
4. Due to camera follow being damped, the view gets yanked and pulled around when the player moves with any speed or jumps. Strafing actually makes you move in a circle due to the camera tilting towards the LookAt target. Increasing the Deadzone in the rigs leads to some janky looking screen offsets when combined with the weird CameraCollider behavior.

For comparison:

Old (POV) behavior

New (Composer) behavior

I did not try to move the view at all in either of the videos, just purely moving and jumping around. Manipulating the view feels the same in either configuration, for which I'm grateful.

I do feel that this is a step in the right direction with regards to working with Cinemachine. Maybe there are some techniques that I may not know to deal with the above issues?

 

Hello, and thank you for your continued support.

I am using the extension that is applied from the dropdown menu at the bottom of the Cinemachine FreeLook component. My Cinemachine package is updated to 2.3.4 in the Package Manager. I am using Unity Editor 2019.2.0b5.


Here is a screenshot of the settings:


The "cameraTarget" object is a child of the player object.



The rigs all have identical settings with slight changes in offset. The Body damping values are changed at runtime through in-game options (from 0-1).

Extensions:


The LookAt target offset works fairly well, I'd say. it's just that the offset also moves with the LookAt target, so the camera "look" still occurs due to follow damping.

While I do intend for the position to change with the CameraCollider (discounting how it ignores the CameraOffset), I'd really like it if it didn't jerk to look at the player when it gets shifted closer. Movement input is translated to the camera's local space. If the player moves/jumps with camera follow being damped or it gets yanked about by the CameraCollider (when it works), the camera view gets centered towards the LookAt target. This causes the input to translate into a turning motion because the camera is no longer looking in the original direction.

I simply want the camera to retain it's original orientation when my character is moving around the screen. In short, it shouldn't "look" at anything or even budge unless the player does so. Please refer to the videos in my previous post.

I have tried playing with the Composer settings (specifically Deadzone and Damping), but they lead to strange behavior when combined with the CameraCollider (ie, offset shifting like the player going off-screen and staying there)

Thank you again!

 

I did assume that FreeLook was the sort of camera rig that "doesn't rotate without user intervention." Was I mistaken?

In any case, the three-rigs-on-a-curve + orbit features of FreeLook are very desirable for my game. I'd hate to have to manually recreate them on another vcam base.

I don't understand the last bit. Wouldn't the camera just orbit around to face the other side?

I can say with confidence that it does behave exactly like my old POV-based rig, at least up until the player starts moving.

 

Yes, that is exactly the issue that caused me to decide on using POVs. If you'll refer to my second post on this thread, that is the behavior I encountered when trying to use FreeLook without a LookAt target. Now, I update all the POV components' axes to match the values on the main freelook and it works. No yanking or jerking.

On the bright side, I found that I needed to force POV update during the transition (since it's usually only on input, a major oversight on my part), so my initial problem is solved with the POV-based Freelook as well.

I guess I was surprised you mentioned Freelook and POV haven't been really tested together, so I immediately assumed that what I had done was hacky and unsafe. I am interested if there is a way to get the behavior I need from Cinemachine "as intended" seeing as it is conceptually a very simple requirement.

Thanks again.

Gameplay sample using POV-based rig:

 

Thanks!

The offsetting isn't really a main issue, since I also have a setting with the player centered, and the offset direction gets switched when the player moves laterally. I also saw those other threads where the CameraOffset extension's foibles with the CameraCollider were discussed.

I also have a scale-able auto-sight mechanic where the camera gravitates towards a locked target. Using a Composer-based rig conflicts with it because the main rig is trying to sight the enemy while the child rigs keep looking at the player+offset. On that note, I actually credit that auto-aim system to your answer on my previous thread which I was unable to reply to as I had lost my password during that time period. A belated "Thank You Very Much" is in order.

I am currently unable to cut out a demo of the player rig due to a lot of the settings needing to get initialized in options. I'll try to slice out a quick isolated version over the weekend. Thanks for the interest.

The main thrust of the rig is setting the child rigs' POV components to follow the main rig as shown here:

The FreeLook's Y-axis takes a value from 0-1 while the POV components require degrees(?) hence the computation.

I had previously only had this part running when input was detected, but allowing it to run during "cinematic mode" solved the issue in my original post.

Here's a graphic I wrote up that lists down the behavioral differences I've found between the two:

 

I'm glad I was able to help even a little, given how much help you devs and these forums have been ever since I started.

I'll be sure to do so.

 

Hello,

The Camera and VCams are unparented in the InputPlayer script's initialization. I had them as children of the Gameobject as part of a prefab which I had to unpack when I sliced out the demo. Had to remove UI assets and such to keep the project size down, unfortunately. (I kept the audio for kinesthetics )




I'll try out that set up and get back to you soon. Much appreciated!

 

Back with the project. I tweaked the settings a bit to get it closer to how my original rig looked like and the setup feels very good, especially with the smooth handling of the offset. At 0 body damping, it's almost perfect.

It gets a little jerky when damping is active, unfortunately. The camera doesn't orbit cleanly around the player. Like there's this noticeable yank once you stop moving the view. Seems like even the orbit movement is being damped, rather than just the follow movement, and it's tailing behind the camera view.

At 0:50 the camera suddenly pulls close if I shift the view to the right while boosting forwards. It's a little disorienting. After tweaking the player's mobility to match my expected highest threshold (x1.5), the problems are significantly more noticeable.

An issue occurring on both settings: When looking upwards while grounded, the camera will close in on the player's backside (due to the camera collider) and take a few seconds to adjust away from the player. It takes significantly longer when damping is active. First video, time 0:38.

I also might need to increase the height of the camera when the player moves into the center to clear the FOV, but only if it stays there for a while. Playing around with the Framing Transposer settings, seems like the only variable that affects it is CameraDistance, which shifts the entire view backwards and up. Alternately, I could edit the cameraTarget's local Y pos. I also don't know how to figure if the player is in the center. This is just a nice-to-have.

All in all, it does feel more like a conventional TPS camera, and the behavior when not damped is pretty ideal. Unfortunately, I do want to retain the damping as an option due to it mostly being a result of tester feedback. I'm actually fine with losing sight of the player mech if the speed is sufficient and compensate for it by adding a damping slider so players can adjust to taste with regards to their stats.

 

Hello,

If referring to the yank when looking around, I think it's mostly due to the Framing Transposer Soft Zones and damping.

NOTE: My Unity Editor gets stuttery if I have an object selected while in Play mode, but it's buttery smooth without anything selected.

I usually test with all damping values set to 1.0 (This is the max damping value I had with the POV FreeLook)

Cinemachine guides enabled. Collider disabled. Damping is enabled after 0:15.

Moving around with guides and damping enabled and no collider.

The yanking seems consistent with the cameraTarget leaving the Dead Zone and hitting the Soft Zone with damping enabled.

Adjusted Dead/Soft Zones with damping.

Here, I tried adjusting the zones to keep the orbit stable while looking around but it's got some terrible snapping when moving.

I think the main issue here is that the Transposer also dampens the movement of the camera around the player. It is very noticeable in that the camera pivots on it's own axis towards the new heading, then moves to maintain the framing. This movement is then affected by the dampening, which causes the orbit to lag behind the look.

The FreeLook handles the orbit separately from the follow which is the behavior I'm looking for. It's also a lot less strict with the player exiting the frame.

RE: camera distance

Changing the Transposer's camera distance value seems to move my camera back and up. I also move the cameraTarget up and down in the latter half of the clip.

RE: Code stuff


I drive the POV InputAxisValues through the InputPlayer script because I process the axes for a custom deadzone implementation.

I really appreciate your taking the time to help me with this. It's also letting me play with Cinemachine settings that I normally wouldn't touch.

 

UPDATE: Playing around more with the Transposer setting and finally got some behavior that's pretty close to what I used to have.

Maximum Soft Zones and Collider enabled

FreeLook POV for comparison

The only obvious difference left is that the camera obviously pivots around itself and then adjusts to maintain offset rather than a true orbit.

In terms of long-term experience, the Transposer does a better job in general movement and looking around due to how it handles the offset. If the camera target doesn't exit the Dead Zone, the camera remains stable. The shoulder switching is handled automatically via Zones and feels very natural.

On the other hand, the FreeLook POV rig always moves with player and lacks a built-in way to handle shoulder switching so I had to cobble one together myself, which is obviously janky and doesn't scale well at all with the damping. I'll definitely have to improve that.

Also tweaked collider settings. It does insist on keeping the player on-screen all the time, but it doesn't snake up to their backside anymore. It just clips through the floor instead.

 

Yeah, that did it.

Looks pretty good, and I can live without the orbit if it cuts down on the complexity by a lot.

I think I'll make a build with this system in place, see how the testers like it. I'll have to rewrite a lot of the options and the auto-aim but version control is a godsend. Thank you very much for your guidance on this subject!

Also, I'm still on Cinemachine 2.3.4 as before.

 

Haha, I spoke too soon. So I integrated the Transposer into a build and initial testing around the main gameplay is pretty satisfactory. On deeper testing with the other systems, I found that if the POV component is set to recenter, it recenters relative to the world, not to the VCam's follow target. Back to original issue, I guess.

I can just set it's Axis values to the player's Euler angle values either when the cinematic starts or during one, but maybe there's something simpler I'm missing that'll let the POV constantly recenter relative to its follow target?

This works well enough, just so it doesn't snap:

 

I see. Oh well. Main issue solved and I got a spiffy camera setup out of it. Calling this one a win.

Much thanks again!