Camera Controller Release

Is this asset not designed to be able to handle players that have gravity different than Vector3.down? I'm getting some bad jitter with this asset when my character's gravity turns sideways. If I turn off collision on the camera as well the camera is not oriented correctly when gravity is different.

I don't think it's my movement system causing the issue because if the camera is a child of the player with CameraController disabled, it's smooth no jitter at all.

 

I've used the CC with the player upside down with no issue, but that doesn't change global gravity.

When I get home, I'll try changing Unity gravity just in case. However, I wouldn't expect there to be an issue.

Is your character upside down as well?

It doesn't surprise me that parenting the camera is clean since it moves as if it is the character.

 

No, sorry, I didn't mean Unity gravity changes. Just the transform.up property of the player. It's a wall walking ability. It's mostly okay once the player is already sideways, but the transition from normal up to sideways has a lot of jitter.

Majority of the time, the camera parented as a child is what I'm looking for. It's what we currently do in our game, but we decided to switch to this asset for the transitions to easily switch between 1st/3rd person and the collision checking. I had hoped the 3rd Person Fixed would be similar to that.

Most of the jitter seems to go away if I comment out SetTargetYawPitch.

If you turn off collision checking for the camera, and have the transform up set to sideways, as you rotate around the character the distance of the camera from the player changes. I'm wondering if that has anything to do with the jitter. When transform.up is normal up, rotating happens normally without the distance changing.

 

I just tried in my testing scene where I have a ramp that eventually takes the character upside down. I'm not seeing any jittering with that. Since my other assets allow for wall-walking, I test that with all my cameras.

There is logic that takes place when the character is tilting, but it's the exact same logic that is triggered by FrameForceToFollowAnchor that you're setting. So, there shouldn't be any surprises.

Going back through the thread, you're using the SetTargetYawPitch to control the camera instead of normal input. I think that's a bit unexpected because that function was built to go from the current yaw/pitch to the target yaw/pitch over time. You're wanting to do it instantly. I'll look at that again and see about adding support for setting the value instantly.

 

Yeah there's a lot of things about my game that's usually unexpected lol. With being a multiplayer game needing client prediction and server reconciliation, I wind up having to be able to set the values directly. I could use input sometimes, but each frame it gets reset to the position last received from the server and reruns all input again. Because of it doing that I had calculated the angle during that portion, and updated the camera afterwards with the new angle.

 

Ah, that was actually what it is. It's something to do with the FrameForceToFollowAnchor that's causing the jitter on the flip. I never added that line of code in, but after rereading your posts I realized you said to do so. I just did, and now the jitter is always there.

 

This sounds like what I was experiencing at one point. Make sure that "Rotate with Input" is checked on the Bow - WalkRunTarget motion. This might not be the problem, but it's worth checking.

 

@emrys90 ,

I just pushed up a new update that has the changes we've talked about:

1. 3rd Person Fixed has a new property "Rotate with Anchor". When checked the camera will rotate when the anchor/character rotates.

2. SetTargetYawPitch has an optional argument you can set. When set to false, I won't auto-clear the target. So, you don't have to call it every frame (but you can if you need to).

3. SetTargetYawPitch has a speed argument. When set to 0, I'll now instantly set the yaw and pitch instead of rotating towards the target over time.

In doing the testing, I did find some jittering. I've cleaned that up as well.

With "Rotate with Anchor" checked, you can remove the "FrameForceToFollowAnchor" code. The SetTargetYawPitch (with speed = 0) will still let you control the rotation through code.

Let me know how this works for you.

 

lol i was using old camera still forgot to delete it from the scene

 

Okay I'll update and check it out.

Do you know what the best settings are for the near clip pane? I'm having some issues with this small creature. Offset is 0.2 on the y, distance is 1. My near clip pane is set to 0.1, and collision radius set to 0.07. For the most part this is working perfectly. The problem though is with the terrain, if I look down it often starts occluding things, even though it doesn't look like the terrain is clipping. The only way I've found to fix that is upping the near clipping pane to like 0.2, which then doesn't look so great for this small character.

 

With the tiny scale you're working with, it really is trial and error.

Here's an image I've shared before (pretend the wall is a floor):

Typically my camera collider radius covers the near plane size so that it can't intrude on the wall. If you can't do that, having wall/floor buffers will do the trick too. That's typically what AAA games do.

Your challenge is that the character (and camera are so low to the ground). The only thing I can think of is have a minimum pitch that forces the camera above the character.

 

I'll have to do some trial and error then I guess, find something that's acceptable.

Having a bit of an issue with a transition, it's immediately going to the end state instead of transitioning.

And I'm calling it like this:
cameraController.ActivateMotor(cameraController.GetMotor("1st to 3rd"));

It works just fine for the 3rd to 1st transition, animates like I'd expect it to. Am I doing something wrong?

 

No it's a bug.

The 1st Person Camera has a MaxDistance and Distance of 0. So, I take that to mean he's at the end of his transition.

Version 3.03 will fix the issue.

 

Okay thanks.

 

I just updated, and am still having some issues.

With "Rotate with Anchor" checked, the camera distance is all messed up. It starts way farther back than it should and then winds up inside the players head. I have the Distance property set to 3.

I have a lot of jitter while in first person, this also happened in the previous release so it's not related to your update. The jitter is only when rotating my character on the yaw though. Moving and pitch rotation seems to have no jitter.

The jitter for wall walking is much better, but still there. In the previous release I fixed it when I removed the section of code that checks for FrameForceToFollowAnchor || tilting in OrbitFixedMotor line 120, which is now line 130. I see you added in _RotateWithAnchor into that if statement, which is probably why I have jitter with that enabled. That causes issues for me when I did FrameForceToFollowAnchor every frame.

 

HI i want to use the asset for the mobile can we use it on android and ios.

 

Hi,
I did a quick test on Mobile Platoform. I did not get any issue.

 

Another weird thing is at night in my game while the camera is moving backwards there's this weird blue rectangle like shape on the screen. I don't know that it's caused by your asset, but I've never seen this before I started using your asset. Any thoughts?

 

Tim,

Thanks for all the recent updates. The new system is looking/working great.

One quick practical question, and one vague issue...

1) Is there an easy way to make a camera motor default to it's "correct" position when it's activated? Meaning, for a third person camera, with a yaw of zero, and at the default distance (unless there's a collision)? I've tried monkeying around with Initialize, but I can't seem to get the right stuff in there to make this happen. In the old AdventureCamera, you could just call Reset() and that would get it done. This would be especially useful for transitions; sometimes it would be nice to snap the camera back in the default position after a transition, instead of leaving it where it is and letting the motor get it back to where it's supposed to be. Apologies if I'm missing a glaringly obvious way to do this.

2) I've noticed a bit of jitter when my character is moving forward quickly and I try to rotate the camera yaw. I'm using the Orbit Follow motor as a base. It feels almost like the motor is "fighting" the yaw input changes, pulling the camera back to the rear of the character as I try to rotate it around to look behind. The result seems to be a bit of jitter during rotation. If I increase yaw speed and smoothing, it seems to get better, but it's still perceptible. Any ideas? I can send a video if that will help.

Thanks for the great work!

 

@Tryz Is this still the proper way to set the distance of the camera at runtime?:

Code (CSharp):

1. CameraController camRig = FindObjectOfType<CameraController>();
2.  
3. if ( camRig != null )
4. {
5.     YawPitchMotor camMotor = camRig.ActiveMotor as YawPitchMotor;
6.  
7.     if ( camMotor != null )
8.     {
9.         camMotor.Distance = 10f;
10.     }
11. }

That is the code that I have, which was working before, but now it doesn't seem to work with the latest version of the asset (3.03). I don't get any errors, it simply doesn't work. The value of Distance simply stays at whatever the default is, rather than being set to the value I am giving it in code.

I checked through my code and everything seems fine and, as I said, this exact code was working in a previous version. I haven't changed any of my code, I simply updated to the latest version of the asset.

I even tried adding a debug line right before line 9 of the above code and it does in fact get printed to the console, so the part where I'm trying to set it is in fact getting called. Just the value is not being set for some reason.

Thanks for all your hard work and great support!

 

UPDATED:

Distance is correct. I'm using this code (which looks pretty much the same as yours) and it's working for OrbitFixedMotor and OribitFollowMotor:

Code (CSharp):

1.         if (GUI.Button(new Rect(10, 100, 100, 25), "Distance"))
2.         {
3.             if (CameraRig != null)
4.             {
5.                 YawPitchMotor lMotor = CameraRig.ActiveMotor as YawPitchMotor;
6.                 if (lMotor != null)
7.                 {
8.                     lMotor.Distance = 10f;
9.                 }
10.             }
11.         }

Any chance the 'FindObjectOfType' isn't finding what we expect?

I'll keep digging a bit, but didn't want to leave my previous message up.

I do have a "MaxDistance" variable that is being used in the inspector. That was keeping the inspector from updating when you set "Distance = 10f", but the camera should move (at least it is for me). I've fixed the inspector for the next update.

Can you send a screen shot of your camera setup to tim@ootii.com? That may help.

 

Not sure why I didn't get a notice about these messages. I'm sorry for the delay.

That doesn't look like anything that's part of the camera. Do you have a particle system that's leaving a particle behind or something? I'm pretty confident that's not me.

 

Sorry about the delay. I'm not receiving emails about posts for some reason. I may need to re-setup my subscriptions.

You can use the "SetTargetYawPitch()" function. It will force the camera to a "local" orbit around the character. For example:

lCameraController.SetTargetYawPitch(0f, 0f, 0f);

This would force the camera to immediately go directly behind the character (yaw = 0, pitch = 0).

If you want that to happen smoothly, the last parameter is a speed.

Does that get you what you're looking for?

I did fix some jitter in the latest update. I've tried testing the Orbit Follow motor here and I'm not seeing anything. Can you shoot a video to tim@ootii.com? I'll make it a priority to look at it.

Again, sorry for the delay

 

@Tryz, I doubt the notification problem is anything on your end. I think it's just the forum software; it has inconsistencies that crop up from time to time.

I'm subscribed to a ton of threads, and I see other thread owners complain that notifications get dropped periodically. It happens infrequently and irregularly, but it happens.

I'm not a thread owner and I don't use email notifications, but to keep tabs on the daily activity on my subscriptions I first click on my Alerts in the morning, then when I'm through those, I click on Watched Threads, and invariably there are some threads (often dozens of them) in the morning that didn't make it to the Alerts as they piled up overnight. I would not be surprised if email notifications are also subject to some kind of unintended culling, like what happens with the Alerts.

 

Email sent. Thanks for the help!

 

Hi, I'm using Xbox 360 controller will this camera work with game pads?

 

Thanks! That did it perfectly. I call ClearTargetYawPitch() after one frame, otherwise the player can't control the camera themselves. Does that sound like the right solution?

Sent!

No worries! You're doing a great job!

 

It sure does.

 

@Tryz Is this the proper way to unset the camera when the object it is tracking is going to be destroyed?

Code (CSharp):

1. void OnDestroy()
2. {
3.     CameraController camRig = FindObjectOfType<CameraController>();
4.  
5.     if ( camRig != null )
6.     {
7.         camRig.Anchor = null;
8.         camRig.enabled = false;
9.     }
10. }

I was having some issues with a NullReferenceException when my player object is destroyed, so I need some way to handle that. Is the code above the best/proper way to do that?

Thanks!

 

Hey @Jick87,

With a non-ootii character controller, I was able to force the errors to happen as well. It really has to do with the "Anchor == null" and me not handling that with a non-ootii character controller.

I've fixed it and will have it ready for the next update.

You shouldn't have to do that code when your character dies, but it is clean and disabling the camera rig if it can't do anything is probably good anyway.

 

Ok, that sounds great! I'll look forward to the new version then.

Thanks for the great support as always!

 

Hi! I tried setting up the camera controller based on the user manual, but whenever I set the rig anchor, my capsule instantly shoots up into the air and flies infinitely. D'ya happen to know how to fix this? All the settings are using the preset.

 

Wow...

The camera never changes the anchor's position. It will change the rotation if the "Rotate Anchor" checkbox on the 3rd Person Fixed motor is checked (it's not by default).

Any chance you've got the camera as a child of the anchor? That could cause an infinite look kind of thing.

If that's not the case, would you send me a picture of how your scene's hierarchy is setup? That may tell me something.

Please send it to tim@ootii.com.

 

@Tryz - I'm getting some weird behavior with the Camera Controller. I'm just using the default settings (created when you select Adventure movement) with the Climbable, Scalable, and Ladder layers added in the collision settings. When I climb onto an object, the camera goes inside the character (head, I think) during the climb animation and then pops back into place at the end.

This doesn't happen if Climbable is not in the camera's collision layers, but then the camera just goes through the climbable object. I don't get this behaviour if I use Adventure Camera with the same collision settings.

 

Odd... I'll look into it.

Thanks

 

I see what's going on.

Does your AC's "Collision Layers" include the climbable layers?

I think your character is intruding on the climbing colliders and that's causing the camera's sphere-cast tests to fail. I've added extra code to help prevent the "0" distance result, but 2 other options would help:

1. Ensure your AC's Collision Layers prevent him from intruding on the climbing volumes

2. Decrease the camera's "Radius" property under "Collision Properties"

My code will help, but if you press the "bug" icon and check "Show Debug Info" you'll see how the sphere-casts layout.

 

Hello

I have the "Third Person Motion Controller" already.

Is it worth me getting the "Camera Controller" when i have the above already?

Thanks

 

Hi Hans.

The MC includes some basic cameras (no collision detection, zooming, transitions, etc). If that's all you need, than the CC would be over-kill. However, if you need those advanced features (and don't own another camera solution), than the CC will plug-and-play with the MC.

In the end, it's totally your call on if you need those features or not.

 

Hello Tryz

Thanks for the answer

Looks like i will be getting the "CC" need the collision detection.
How is you Sword & Shield coming along....it is close ?
Also will you be doing a Magic user stand alone module?

Thanks Again

 

I appreciate it!

I submitted it to Unity last week for approval. So, I'm just waiting on them. My guess is that they'll release it next Monday.

I'm not sure if you follow the MC thread, but I put some videos up over there:
https://forum.unity3d.com/threads/motion-controller.229900/page-42#post-2872916

I actually plan on it. One of the things I'm mulling over is how to do magic. So, I'm not sure if that's next or not. December will probably be a 'clean up' month.

 

How would I go about lerping camera distance and offset? I have ways in game where the player grows bigger, and so the camera moves further away from the character. I'm currently lerping it by setting the following properties over a half second or so to the new values

cameraController.AnchorOffset = new Vector3(0f, x, 0f);
cameraController.GetMotor(ThirdPersonMotor).AnchorOffset = new Vector3(0f, x, 0f);

CameraMotor motor = cameraController.GetMotor(ThirdPersonMotor);
motor.MaxDistance = x;
motor.Distance = x;

Where x is the lerped value. The problem is it's not really that smooth, and it moves the camera further back at first, and then a second later or so it moves the camera up to the new offset. So they don't lerp to their new position together it seems, even though I am setting them at the same time.

 

You just set the "AnchorOffset" and "Distance" properties.

Here's what I did based on your description. It was smooth and worked fine:

Code (CSharp):

1. using UnityEngine;
2. using com.ootii.Cameras;
3.  
4. public class CC_Simple_code : MonoBehaviour
5. {
6.     public CameraController CameraRig = null;
7.  
8.     int mState = 0;
9.     float mHeight = 1.8f;
10.     float mDistance = 3.0f;
11.  
12.     void Awake()
13.     {
14.         CameraRig = FindObjectOfType<CameraController>();
15.     }
16.  
17.     void Update()
18.     {
19.         if (mState == 1)
20.         {
21.             mHeight = Mathf.Lerp(mHeight, 3f, 0.02f);
22.             CameraRig.AnchorOffset = new Vector3(0f, mHeight, 0f);
23.  
24.             mDistance = Mathf.Lerp(mDistance, 6.0f, 0.02f);
25.             CameraRig.ActiveMotor.Distance = mDistance;
26.  
27.             if (Mathf.Abs(mHeight - 3.0f) < 0.05f && Mathf.Abs(mDistance - 6.0f) < 0.05f) { mState = 0; }
28.         }
29.         else if (mState == 2)
30.         {
31.             mHeight = Mathf.Lerp(mHeight, 1.8f, 0.02f);
32.             CameraRig.AnchorOffset = new Vector3(0f, mHeight, 0f);
33.  
34.             mDistance = Mathf.Lerp(mDistance, 3.0f, 0.02f);
35.             CameraRig.ActiveMotor.Distance = mDistance;
36.  
37.             if (Mathf.Abs(mHeight - 1.8f) < 0.05f && Mathf.Abs(mDistance - 3.0f) < 0.05f) { mState = 0; }
38.         }
39.     }
40.  
41.     void OnGUI()
42.     {
43.         if (GUI.Button(new Rect(10, 10, 100, 25), "Grow")) {  mState = 1; }
44.         if (GUI.Button(new Rect(10, 40, 100, 25), "Shrink")) { mState = 2; }
45.     }
46. }

It may be you're trying to keep 'x' the same, but they represent two different things. So, you probably want to treat them separate.

 

X actually is two separate values, one for y offset and the other for the distance. That's just a portion of the code. I thought MaxDistance is what determines how far the camera is away from the anchor? Here's my full code.

Code (CSharp):

1.     public void TweenCamera(float yOffset, float distance)
2.     {
3.         FloatTween info = new FloatTween
4.         {
5.             duration = 2f,
6.             startFloat = cameraController.AnchorOffset.y,
7.             targetFloat = yOffset
8.         };
9.         info.AddOnChangedCallback((x) =>
10.         {
11.             cameraController.AnchorOffset = new Vector3(0f, x, 0f);
12.             cameraController.GetMotor(ThirdPersonMotor).AnchorOffset = new Vector3(0f, x, 0f);
13.         });
14.         info.ignoreTimeScale = true;
15.  
16.         cameraOffsetTween.StartTween(info);
17.  
18.  
19.         info = new FloatTween
20.         {
21.             duration = 2f,
22.             startFloat = cameraController.GetMotor(ThirdPersonMotor).MaxDistance,
23.             targetFloat = distance
24.         };
25.         info.AddOnChangedCallback((x) =>
26.         {
27.             CameraMotor motor = cameraController.GetMotor(ThirdPersonMotor);
28.             motor.MaxDistance = x;
29.             motor.Distance = x;
30.         });
31.         info.ignoreTimeScale = true;
32.  
33.         cameraDistanceTween.StartTween(info);
34.     }

The motor is set as having the anchor as well currently, which is why I set the anchor offset on the motor as well, if that matters.

The TweenRunner is something from Unity if I recall correctly, not sure from where though. Basically it lerps from start to target over duration inside a coroutine the yield returns null, so happens after Update.

 

For the 3rd Person cameras, the MaxDistance and Distance are really the same thing. That's because the distance is always that value... unless a collision occurs. But, collisions are handled outside of the individual motors and are a reaction.

So, from the motor's stand point, Distance = MaxDistance. In fact, the Distance setter sets both the mDistance and mMaxDistance property.

That fact that you did both didn't hurt though.

Having to deal with many different types of motors does add some interesting nuances like this.

If the motor has "Use Rig Anchor" set, than the code I had would be fine. Really you'd only have to do the motor specific AnchorOffset if your motor isn't using the rig's anchor. The idea with the rig's anchor is that you can set this info once an it's used by all motors.

I've never seen that, but I'm always surprised by something I've missed in Unity.

 

So if you'd saying this should be smooth and such, do you have any ideas why that code isn't running smoothly? I'm thinking it's something related to the coliision checking or something since it moves later after it's already been set, like it's recovering to the new values.

The YawPitchMotor, which is what I am using, I looked at it's code and Distance only sets mDistance.

 

The code that I posted was smooth.

Unfortunately, I never worked with the TweenRunner you talked about or have seen the "StartTween" function you use in your code. So, I can't comment on that.

You can't use YawPitchMotor because it's abstract class. You're probably using 3rd Person Fixed or 3rd Person Follow (which inherit from YawPitchMotor)... check those Distance property overrides.

 

You're right, I'm using 3rd Person Fixed, which I think is OrbitFixedMotor? It doesn't have overrides for Distance.

 

If it helps, here's the code files for the tweening. It's just a coroutine though that yield returns null.

 

Right. OrbitFixedMotor.cs is it. I just downloaded the latest from the asset store (v 3.08) and the Distance override is at line 41.

Unfortunately, I won't have time to download and put together a project to test your custom code.

With selling assets, I try to help as much as I can, but downloading custom code like this and creating tests to review your code is beyond support and more custom development.

If you run the code I posted above, everything was smooth. You can run that and use it as an example. Simply do the following:
1. Copy the code and create a new class out of it
2. Add that component to a GameObject in the scene
3. Run the scene and press the buttons

I apologize if this comes off as rude. I don't mean it to be.

 

@Tryz Just wondering if it's possible to have the camera moving along a path, but only progressing along the path when the player is moving through the level?

Thinking something along the lines of God of War or Heavenly Sword etc. Preset camera movements that follow the player's action.