Camera Controller Release

Ah, I got you. Thanks!

 

Question 1.

If i want to control a walk and a walk-jog-run mode how would i accomplish this using the adventure controller?

So for example : holding shift key down would start the avatar from walk to run cycle and vise versa.

Without the shift key it would simply walk.

I'd want both the third and first person views to behave like this?

 

Hey GXMark,

Background:
Most of the control you're talking about is in the Mecanim Animator itself. If you open the 'Humanoid' Animator Controller, you'll see a 'Forward-SM' sub-state machine. Go into that.

It looks pretty complex because it's handling the pivots, moving from walk to run, etc.

If you look at any of the transitions (WalkForward-to-JogForward, JogForward-to-RunForward, etc.), you'll see they all rely on a 'Speed' parameter to control the transition. That's the key.

Solution:
If you go into AdventureController.cs and look at line 618, that's where the 'Speed' parameter is being set. The value is coming from the mState.Speed variable.

That's what you want to hijack or modify. For example, if you look back at the WalkForward-to-JogForward transition, you'll see the transition takes place when the 'Speed' parameter is greater than 0.6. So in the code, if you force the 'Speed' to never go above 0.6, you'll always be in a walk.

How and when you determine when to force the 'Speed' is up you, but this value determines if the character walks or walks-jogs-runs.

Hope that helps,
Tim

 

Thanks Tim thats exactly what i wanted to hijack !

Cheers
Mark

 

I have the "Use collision detection" box checked and I'm trying to prevent my camera from going through walls when moving the camera using the right analogue stick- looks like it moving the camera through the "yaw" setting-

Is there anything I can do to stop the camera from going through walls when controlling the camera like that? The walls all have colliders of course-

Here's a video demonstrating the issue https://googledrive.com/host/0BwTEkFe-h60WMWtjZ2pNVk11S2M/clipping.mp4

I'm using the IndAdventureRig script btw

If its not possible to prevent it- how would I limit the camera movement to only 30' in each direction so it would be impossible to go through perpendicular walls as in the video- like the camera in Ocarina of Time for example- it seems to limit camera pitch and yaw- that would be a useful solution-

Thanks for any help!

 

Hey MDotStrange,

Thanks for the video. Visuals always help!

I created a scene like yours, but my camera didn't go through the walls:


So, I went back to your video and noticed that the camera actually moves in a square around the character. You can see there are point where it "zooms in" and "zooms out". That's the rig following the walls.

I think there could be a couple of things happening.

1. The "Main Camera" inside the "Camera Rig" isn't zero'd out. Meaning it's position is pushed back which is causing the camera itself to go in the walls.

2. The near clip plane on the camera is so low that it hides the wall the camera rig is colliding with. Mine is usually set to 0.3. This would also happen in conjunction with a very low field of view.

Please see if either of those is the case. If not, can you send me a copy of the scene/project? That will help me understand the camera settings and scene setup. Send it to tim@ootii.com.

Thank,
Tim

 

That did it- thanks Tim! The camera's Z position wasn't zeroed out- here's how it works now
https://googledrive.com/host/0BwTEkFe-h60WMWtjZ2pNVk11S2M/fixed.mp4

I have another question- its one I asked before but was unable to solve with Adventure Camera- I want to implement "Z targeting" - I was able to do it with a separate camera- I'm just using Smooth follow to follow the player and Smooth Look at which is looking at the "activeTarget" see it in action here
https://googledrive.com/host/0BwTEkFe-h60WMWtjZ2pNVk11S2M/ztargeting.mp4

Is there a way to easily implement this into Adventure Camera? Could I achieve this by making a switch so that it uses the "activeTarget" as the Anchor?

Thanks so much for the help!

 

Yeah, that's much better.

You'll notice that you can still see through the walls sometimes. That's because the camera is flush against the wall (and its collider). The camera's frustum then extends beyond the wall. The way I solve that in my games (and other games do too) is to add a collision barrier that creates some buffer between the camera and the actual wall.


For the 'Z targeting', it becomes a bit tricky. The reason is that the camera orbits by pivoting around the anchor (typically the PC's head). Think of the anchor as the center point of a sphere and the camera always stays on the surface of the sphere. When the camera looks, it looks from the camera's position, through the sphere center (head), out the opposite side of the sphere.

Looking back at the AdventureRig.cs code, I don't have a way to force the camera to look at something (even if we respected the center pivot point).

The best I've got (right now) is for you to move to the 'THIRD_PERSON_FIXED' mode and then write some code that forces the camera rotation by setting a pitch and yaw that results in looking at some 'view target' position property.

The math will get a bit hairy, but it should work. I'm a bit swamped right now, but if you want to take a stab at it, I can help 'talk' you through the code. Just email me at tim@ootii.com.


Side note...
For Z targeting, I do something similar here (at 00:35):

However, I force the character to look at the target while the camera is still free to rotate around. If that's an acceptable solution, I might be more help there.

 

I was able to get some basic Z-targeting going on thanks to your tips so thats a go ^ ^

I'll go the collider buffer route to prevent the cameras going through the walls- its easy to do that with simple geometry using box and other simple colliders-

Any tips when you're using more complex geometry that requires a mesh collider as you can't add a buffer to those afaik-do you just build you own complex collider setup using several box colliders?

Thanks so much Tim!

 

Glad it's working

Even for my organic caves, I using multiple box colliders for a couple of reasons.
1. I have complete control over the position regardless of look.
2. I can keep players and NPCs from getting stuck in nooks and crannies.
3. Performance. It's a lot fast to test collision against boxes than lots of complex shapes.

Happy to help.

 

Thanks so much for the info Tim! I thought I could slap mesh colliders on there and have my work be done- So much to learn haha

 

There is a new version of the Adventure Camera up (v 1.26) and one of the changes is the folder structure.

Why did I do this?
The Adventure Camera was my first asset and I wasn't really sure how to organize it. Then, as I created other assets, there weren't any definitive instructions on how to organize code so it can be shared between assets.

Here I am 6 assets later and I have a better understanding of how Unity organizes and updates code. As I'm creating new assets, I want to leverage shared code. So, the time has come for me to update the Adventure Camera structure.

What does this mean to you?
It means ootii code is more organized. You'll find that going forward (after I make all my changes) all my assets will be under an 'ootii' folder in your project. Under that, will be the separate assets as well as shared code (the framework).

This way you won't have 6 "NumberHelper.cs" files, 6 "StringHelper.cs" files, etc.

The downside?
If you download this Adventure Camera update, you may get some errors that say something like:
The namespace '...' already contains a definition for '...'

Most people won't see these as Unity will update your files where you have them. However, it's possible that the link between the old file and the new file could be broken. If that happens, just delete the old file. That would be the one NOT under the new root "Assets/ootii" project folder.

Can I ease the pain?
If possible, the best approach to this update is to simply delete the current "AdventureCamera" folder from your "Assets" folder. Then, importing this update will be a fresh install with no issues.

What else?
Over the coming months, I'll be updating all my assets to support this new structure. Usually you won't have any issues. However, with the Adventure Camera being the oldest asset, I just wanted to prepare you for the worst.

I'm sorry
I hate these kinds of "breaking changes" and I don't do them often. However, sometimes you have to in order to move forwards.

As always, if you have any problems... I'm here to help. Just email tim@ootii.com.

Thanks for understanding!

 

I had the old version and just followed these instructions- getting these errors-

 

Hey MDotStrange,

Haven't seen this one in my tests. Just in case, I did another fresh download and install and everything was good.

Do you have any other assets imported or just the Adventure Camera?

In the old instructions I said to delete the whole 'AdventureCamera' folder. Any chance the 'Helpers' or 'Utilities' folder was deleted?

Any info you can give me about your project would help.

To get yourself going, you should be able to delete the old Adventure Camera import and start fresh with this one.

Sorry about the hassles.

 

I have a question about this update. I also have your motion controller asset and the AdventureRig.cs copied into that asset. I don't see "AdventureRig.cs" in the new update to the adventure camera - just see "IndAdventureRig.cs"

Is there a new procedure to update the motion controller asset?

 

Hi MIK3K,

When a file (like the AdventureRig.cs) is moved, Unity will update the file in its new location. So you will have gotten the update, it will just have been put the new file where you placed it in the Motion Controller folders.

I do plan on updating the Motion Controller structure as well, but I haven't yet. I want to make sure I don't cause to much pain here first.

Hope that helps,
Tim

 

Are you sure? When I click "import" and look at the list of files it is going to import I still don't see "AdventureRig.cs" in the new Adventure Camera asset. I do see the "IndAdventureRig.cs." Under AI > controllers> there is "AdventureController.cs" and "AdventureControllerState.cs" but no other files beginning with "Adventure. . . "



I had some problems getting motion controller working at first (think I had a parent/child thing wrong and weird behavior) and set it aside for a while. Set it up again recently and now it is working really great and couldn't be happier. I'm not worried about any updates but just thought you should know in case the asset store version is missing that script.

Thanks for the great controllers. Love running around my world and climbing walls.

 

Yeah, that's how it works... of course I'm going off of what I've experienced as I haven't found actual documentation.

You do have AdventureRig.cs in a folder somewhere... right? Feel free to email it to tim@ootii.com and I'll make sure it's the latest version.

Glad to hear everything else is good!

 

Any hints as to how to get a quick 180 turn like in the Resident evil games working with the adventure camera? I thought it would work by adding 180' to the Yaw X but it seems I can't affect that parameter- I've tried a few things to no avail-

Any tips or hints? Thanks!

 

Can you point me to a video (and time) just so I can make sure we're talking about the same thing?

I know for the 135 pivot I have now, I actually disable the rotation and allow the root motion of the animation to do it. Then, once that's done I re-enable rotating in code. I'm wondering if you're getting caught up in that.

 

You can see it in this video at the time in the link

14:50

Seems like you have an animation of the character spinning 180 while at the same time the camera whips around behind them- staying behind them the whole time

 

Watching in slow-mo, it looks like the RE camera always wants to move to a position behind (and slightly to the right) of the character. I can see this from 14:20-14:29.

So at 14:48 when he gets ready for the kick, the character pivots to face the enemy and the camera swings around to that default position again. Then, by 14:50 it's settled.

The AC works a little different in that it doesn't try to move behind the character. Instead it allows the character to rotate and it just stays in orbit. Even when you go to THIRD_PERSON_FIXED mode, the camera doesn't try to stay behind the character, instead the camera determines the character's rotation.

So, what does that mean? It means we'd need to add a new mode to the camera that smoothly moves to that "follow position". I don't think that would be too hard to do and if you want, I can do it for you (and everyone). It will just take me about a week to get to it.

Outside of the camera, when trying to force the camera's position you have to set the rotation on the camera's transform directly or line 564 will override the Yaw value you set. I do this to help manage the position of the camera.

If you want to tackle this before I can get to it, just shoot me an email at tim@ootii.com and I can help you through it.

 

Ok thanks for checking it out- yeh a quick turn would be nice to have- I'll have a go at messing with the script but besides accessing properties through Playmaker I'm useless with scripts- it would be a nice addition to the rig

When enemies are creeping behind the player its a great way to face them instantly-

Looking at the rig for my purposes I just need to be able to add +180 on the Yaw X with a button push- I was able to control the Yaw Y for some other modifications and that worked perfectly- so if there was a public bool that allowed a user to release the scripts control of Yaw X that would be perfect-

 

I have a rather newb question here. I like the looks of your camera but I would like the ability to easily change the distance of the camera in 3rd person to the character. Is it as easy as just changing the transform or is there a place on the editor for the camera where I can do this? Your demo looks great but I would like the option of going a bit closer to the character. Thanks.

 

Hi Teila, That's an easy one.

There's a property on the inspector called 'Distance'. Just change that to what you want and the camera will respect it.

There are about 15 settings all together that allow you to control things like distance, transition time, orbit speed, etc.

Hope that helps,
Tim

 

Hi Tim!

We did purchase your camera on the advice of my programmer. I am having some issues with it though and the programmer is busy with other stuff so I hate to distract him. I wonder if you can help me. Overall, I really like the camera so hope we can fix these issues.

I set up the camera based on the steps in the documentation. I am confused now that I read the forum since the documentation says to put the player on a layer and yet you say above that that isn't necessary. Do I have old documentation? I followed the documentation provided although I did notice some differences in names and editors, which If figured were due to 4.6. We are using a UMA prefab. Not sure if this makes a difference since he should be humanoid and have everything necessary for mecanim.

We are having several issues.

First of all, when the character is running forward on the terrain I get a nice 150 fps. But when I turn the camera at all to make him go in a different direction, the fps drops to 15 and I see lag. This won't work at all for us.

Second, we are getting rubberbanding. It is not super bad but bad enough to cause some frustration. I removed the extra collider so that is gone and the avatar is properly set as player and on the Player Layer, which is layer 8. This happens when running across the terrain. My terrain is not perfectly flat but has hills and valleys but is not super steep either.

Third, the zoom feature does not work which doesn't surprise me since the documentation shows set up for a joystick rather than a mouse. How do I get this to work with my mouse?

Also, the camera movement seems very sensitive. I imagine this can be changed by settings. It feels loose to me. I am going to play around with that a bit and see if I can fix that part.

The other issues though are pretty important. I hope to get some advice from you. The documentation is nice, I like the steps, and the discussion of code is great, but I would like to see a bit more practical discussion of settings for non programmers like me.

Thank you.

Edit: Do you prefer emails? I just noticed you put that in the documentation. Oops!

 

Hi Teila,

No, you don't need to put the player on a layer anymore. I thought I cleaned up the documentation, but I'll look again and get that straightened up.

That shouldn't be a problem. I know when I played with UMA a while back, I wasn't sure how to set extra components up on the run-time instantiated character. However, if you've got that figured out you should be good.

No, definitely not good and not normal. I've seen this happen for others when the camera wasn't 'reset' in the rig or when they had the camera parented to the character (which isn't good).

Please check those. If those aren't the issue, the best way for me to help is if you can get me a small scene this is happening in. You can send that to tim@ootii.com.

In the past year, I've hit this a couple of times and it's always something sneaky in scene

Totally understand and I bet it's related to the issue above. If you can get me a scene, that would be great.

Having a non-flat terrain shouldn't be an issue at all.

Unfortunately, there's isn't a zoom feature. The camera will go into a 'first-person-over-the-shoulder' mode that is similar to Tomb Raider, but I never implemented zoom myself. I plan on it, but haven't gotten to it.

I know others have, but I don't have a good suggestion for you. This is definitely something your programmer would do as an add-on.

There are several settings that would help:
- Orbit Speed will actually speed or slow the rotation
- Orbit Smoothing can add/remove lag that could help the feel
- Unity's Input Manager settings - If you're using the Input Manager that's included, all I do is grab the values from Unity's Input Manager directly. So, you can modify that in the Unity editor and that can help the sensitivity.


I know there's a lot here, but I think if we figure out what's going on in the scene that will clear up a lot and you'll be much happier. I'm definitely here to help and you can reach me at tim@ootii.com too.

Having a project with a scene that is exhibiting this will help a ton!

 

Hey Tim,

2 questions:

- Ive got the character running around in a scene, and I dont seem to be able to adjust where the camera sits vertically. I had to scale the character up to 1.75 (all axises) and the camera cuts off his head. I tried setting the camera rig to a higher height, leaving the camera at 0,0,0, but that didnt change anything. I couldnt find anything on setting a camera height in the docs, only distance.

- The other problem I have is that running uphill the Adventure Camera (maybe I should post on that forum instead?) keeps going under the ground. I have Use Collision Detection on, but it goes right through the terrain. Even when it is above the terrain, it is a very steep angle. Again, I dont see a setting for height setting for keeping above the terrain, which seems necessary when running up a sloped hill.

The camera is 0,0,0 on the rig. Ive tried my rig at (0,4,0) position to move it higher, but that value seems to get ignored as (0,0,0) looks the same.

Video:

-g

 

Hey Ge01f,

Some of this is a duplicate from the Motion Controller thread. I posted here first by accident, but really the solutions were relative to the Motion Controller and customizing properties for your character's height.

Camera Height
Changing the position values of the Adventure Camera transform won’t change anything. That’s because the camera manages its own position during run time. What you can do is use is the ‘Camera Offset’ property on the Motion Controller. This property determines the camera’s target point.

By default, it’s set to 1.7 (for the default character size of 1.8). However, in your case you could set it to 1.9 or 2.0.




A Couple More Notes
In the ‘Casual Idle’ motion, don’t forget to uncheck the ‘Rotate with View’ option. You don’t want that check since you’re using the Adventure Camera with the Motion Controller.

When using the Adventure Camera with the Motion Controller, you’ll want to use the ‘Adventure Forward’ motion instead of the ‘Simple Forward’ motion. You’ll find the controls much cleaner and it will replicate how modern adventure games work.


Last Thing
The last thing on your list was the camera not colliding with the ground. I'm not having this issue even when testing on very uneven ground. In my game, I've got similar hills to the ones you show in the video.

Go ahead and make the changes I mentioned on the Motion Controller thread. Once all of that is running smooth, let's look at this again. If you can send me an updated project with the terrain you're using, I'll look at that has well.



Happy New Years!

 

Awesome, thanks Tim!

Those solved all the problems.

- The character height camera was fixed by the Camera Offset Y, which is what I was missing.
- The Casual Idle disabling Rotate on View gets rid of the weird spinning effect that happened, that I wasnt dealing with yet.
- After setting the 1.9 Camera Offset Y the camera no longer had clipping problems with the terrain.

Thanks again!

Happy New Years!

 

Awesome! I'm glad it's all working

Happy New Years to you as well.

 

Hello,

Is there a way to only allow movement with the mouse if you click, hold, and drag? I need to be able to move the mouse around freely without moving the character.

Thanks

 

I second that request. It would be very helpful. Thanks!

 

I think I was able to figure it out. I modified Line 125 of the InputManager.cs to say this:
get { return UnityEngine.Input.GetKey(KeyCode.Mouse0); }

Then on line 379 of the AdventureRig.cs I modifed it to this:
mIsOrbiting = ((lMouseX != 0 || lMouseY != 0) && ootiiInputStub.IsFreeViewing);

My next problem is I need to restrict the area on the screen that allows the user to click and drag. I am making a mobile game and I need to allow the user to use an onscreen joystick and drag with another finger to change the camera position.

 

Hey guys,

What I did in the Motion Controller (because I wanted the behavior you suggest) was I did this inside the ViewY and ViewX get properties:

Code (CSharp):

1.             get
2.             {
3.                 float lView = 0f;
4.  
5.                 if (mIsXboxControllerEnabled)
6.                 {
7.                     lView = UnityEngine.Input.GetAxisRaw("RightStickX");
8.                     if (lView != 0f) { return lView; }
9.                 }
10.  
11.                 // Mouse
12.                 if (UnityEngine.Input.GetMouseButton(1))
13.                 {
14.                     lView = mViewX;
15.                 }
16.  
17.                 return lView;
18.             }

You shouldn't have to modify the Adventure Rig unless you wanted some additional behavior.

The next one is trickier as I'm not really familiar with the input controls for mobile. But, I think in the same properties as I put above, you could do a check to see if the touch is within the coordinates you want. If so, return mViewX. If not, return 0f. That's a bit of a guess, but I think that's right.

 

Can this be a toggle-able option in the official package so we don't have to maintain customizations?

 

Hey TonyLi,

Yeah, that's what I was thinking. I can't mess up any existing customers, but if I add an option to the new-ish Input Manager Core monobehavior, you could set the property for your scene.

To keep it simple, it would just be a boolean for a "hold right mouse button to change view" option.

Does that work?

 

Hi @Tryz - sure, that works for me. Can you make it a public property that's settable in the inspector? You can leave it false by default so it doesn't mess up other customers. Thanks!

 

Exactly. The Input Manager Core is a monobehavior that you can add to the scene and set in the UI. What it does is set the public property on the Input Manager itself.

Juggling a couple of things right now, but should have it done by the end of the week.

 

Hey Tim,

You suggestion worked perfectly. Below is my final product including the restriction of not allowing you to click and drag from the lower left corner where the joystick is.

Code (csharp):

1.  
2. if (UnityEngine.Input.GetMouseButton(0) && (UnityEngine.Input.mousePosition.x >= Screen.width / 2 + 50 || UnityEngine.Input.mousePosition.y >= Screen.height / 2 + 25))
3.   {
4.   lView = mViewY;
5.   }

Thanks!

 

Datsun80, you're having it limited by the left mouse button vs. the right mouse button. Is that what you expected? If so, I should probably add that as an option in the Input Manager Core inspector.

Just checking...

 

Yes, that is was I expect. I've encountered two issues so far using this setup. While I am using the joystick on screen I use my other finger to tap and drag the camera. When I do this however the camera goes into targeting mode instead of rotating the camera.

The other issue is when I click and drag on the screen the camera snaps to the point that I click on. I would like it to just rotate the cameras current position, not snap to the place I touch then rotate.

 

What does the screen register the tap-and-drag as? If it's going into targeting mode, the code must be getting a "right mouse down" flag from Unity. I'll test again here, but I'm on mouse and keyboard.

On the second issue, I think that's because the underlying "mViewX" is actually changing. The code I sent worked for the Motion Controller, but maybe I missed another part that's different between the MC and ACR. As I work on the update I mentioned, I'll make sure that doesn't happen. In the mean time, you may want to look in the Update() function and ensure the mViewX and mViewY aren't updated when the mouse isn't down.

 

Yes, since I have two fingers on the screen it registers it as a right click. I suppose I could change the code to also rotate with right click, I will just have to find a different key for the target.

I will double check the mViewX and Y.

 

Just to update you on the second issue. The click and drag works as expect on the computer. When I export to my android phone it gets weird. When I tap the screen with my finger the camera jumps around. What is interesting is when I use my stylus with a fine point it works just like the computer.

 

Hmmm... Unfortunately, I don't have a good answer for this. Are you using a third-party input controller or anything?

My wife has a tablet. If I can get it on there, I might be able to test and see if I get the same behavior.

 

@datsun80 and @TonyLi

I've created the changes and they are ready for some additional testing. Since I have to keep the Motion Controller and Adventure Camera in sync, I'd like you guys to check it out before I do the actual push.



If you'll email tim@ootii.com, I'll send you the updated files and you can let me know what you think.

 

Nope, not using any 3rd party input. I'm going to test it more tomorrow on ios to see if it does the same thing as android.

Also, I sent you an email to get the test code.

 

Works great! Thanks!

 

I have solved the camera jumping issue on mobile devices. The issue was allowing the mobile device to emulate a mouse click. In the update method of the InputManager I added a check if I am on mobile and if so use the Input.GetTouch method.

Code (CSharp):

1. UnityEngine.Input.GetTouch(touch2Watch).deltaPosition.x * lMouseSensativity * Time.deltaTime