Official New Standard Asset Characters - Third Person

Just found this threat.
Just wanne say, keep up the good work! This thing looks promising.

 

They should really watch the "Animation Bootcamp: Overgrowth" video describing this for a truly "Generic" controller that can handle nearly _any_ use-case.

@willgoldstone

The current controller is looking great!


I do want to add that the weakest point in the current design is the non-root-motion (speed-based) walking animation for Mario64-style controllers.
You could try using a "wheel-and-spoke" approach to help this kind of animation -- see below:

See the video above and watch for a couple of minutes -- it handles this issue elegantly:

@willgoldstone -- Can we get the basic Mario64 (non-rootmotion) setup working like this so that we can control movement animations better by instead informing our movement animations _with_ physics? (Eg. Walk to Run should be driven by exploration speed's current value, and be blended accordingly.)
This same locomotion could be applied to animals or vehicles too. Talk about truly generic.

See the video. Just sayin'.

PS:
I suggest watching from the beginning. That describes the basic idea for a "game physics + animation" using truly "responsive" Mario64-style physics -- This enables us to use "physics simulations" while controlling our 3rd person animations procedurally (all without needing root-motion control or heavy blending with animation baking + endless tweaks....)

 

That video (oldie but goodie) pretty much describes a solid way to implement both.
You can't decouple physics and animation, _but_ you can address them both independently, based on gameplay, all _without_ having to use one to control the other.


@willgoldstone

As mentioned above in my previous post --

Essentially, it is a two-way relationship. Physics _informs_ animation, while Animation _informs_ physics.
They each do their own thing, separately, based on the information provided from the other -- but the important factor is that neither controls the other; each does their own thing with information from the other which they can each, individually, choose to act on or ignore.

Please watch that video (above) for a more in-depth look at unifying the two.



Also, regarding things like "climbing"...

BotW is great because it makes no assumptions about the state of the physics world or animation.
It lets each aspect do its own thing.
E.g. to let the "OG" BotW Character Controller interact with physics like climbing, they used a physics "constraint" glued to the hipbone of Link to attach him to rigidbodies. See below:

 

Yes that is the video, that had a nice balance between the two, very interesring!

 

Wow... connecting Link to tree by dynamically put a joint between him and the tree. This is a very special case and I think it shouldn't be part of the controller. At least not in version 1.0.

Please don't do it. Even if it appears interesting to develop. Please don't do it.Please don't do it.Please don't do it ;-)

 

Careful! -- They might take you seriously on that! -- Unity rarely goes 2.0 on anything like this! D:

Lol

Seriously though, for climbing in general, this is pretty much how it's done -- just with a simple raycast (followed by procedural IK/FK placement) instead of a constraint (which, in this case, just replaces raycasting from the torso, hip, or some other location on the character.) The only real difference is that BotW's constraint solution can also handle when geometry suddenly becomes a rigidbody. So why not add it?

Plus, we wanted "generic" didn't we? We've got moving (and rotating) platforms already (that are not always flat boxes) that someone _will_ inevitably want to climb. What if these boxes suddenly rock or rotate while you're climbing? A more "generic" solution would inevitably be needed to manage this basic motion.
I say Unity Team should just finally bury Unreal with the best base character controller out there, available as a default. One can scarcely do better than BotW's character controller imho.

 

A combined navmesh agent / player driven input would be great, as Player characters often transition from gamplay to non playable scenes dynamically.
Is there currently any way to move the character „exactly“ to a given destination with the nav mesh agent?
While the agent itself is placed perfectly, the given example controller never reaches the point accurately. This is Important to transition to a timeline with accurately authored animations for example (2 people hugging). I guess the problem is rootmotion in that case. I can imagine a controller like in the overgrowth example would make it easier to handle situations like these.

Is there any other way for a rootmotion driven controller to reach the exact point?

Besides of these things I really love the amount of control and the use of scriptable objects. Great work!

 

Well while we're at it, lets add underwater swimming and floating in space capabilities too. (can you say feature creep?)

 

I think it would be beneficial if the character controller would contain the following abilities as well:
- waving hello
- feeding baby(ies)
- jumping the shark
- starting the 100m sprint (the run would take over after that)
- pushing (and fighting) the football (soccer) marshals
- opening and closing doors and horizontal windows

 

So I'm thinking a triple-jump and a long jump, and maybe flying would be nice as well. Perhaps we could just throw in some Assassin's Creed meets GTAV (all movements of course) with some rudimentary multiplayer capabilities too.


...OR... we could just have basic (responsive and easy-to-edit) locomotion with some basic (responsive and easy-to-edit) climbing mechanisms in place that will take care of general physics so that we can finally build on top of this and debug gameplay sometime in our lifetimes?

 

It would be somewhat relevant - as far as I can remember, the old CC kept track of it's position internally rather than relying on the transform, so teleporting it required:

Code (csharp):

1. characterController.enabled = false;
2. characterController.transform.position = blah;
3. characterController.enabled = true;

Or something along those lines.

So the question is more like "can I just set the position of the cc to teleport it, or do I have to notify it in some way that that has happened".

 

Huh, good decision. Stay near the root functionality, please.

 

Agree or at least recreate the legacy Character controller feature with more improvement/stability and extendability

 

Personally what I want to see is an example character that can sit in a car and drive away while retaining its core functionality.This would illustrate MANY examples of mecanim usage including parenting/ childing during runtime. It would also make use of the vehicle controller.

I think it would be a fantastic case example.

 

A character controller is not an example -- it is a tool -- a tool that's meant to be used and modified.


What you (and a lot of others) are looking for is a tutorial on combining animation and physics.

I know (quality) information on this subject is scarce (and I'm not sure why), but I suggest discovering your own techniques that work ergonomically for you through trial and error (and maybe developing your own generic solution) might be a better idea than "tutorial-seeking" is. Learning through practical experience is always the best -- a "tutorial" really should only be a guide to the basics.

Most people who do this have developed their own internal systems to make this kind of thing (they've already done) more ergonomic for themselves. For example, I'm not sure I would use Mecanim to do this "driving a car" thing. I would prefer to make a custom (reuseable) more-generic frame-based IK solution that combines all the technologies I plan to use for animation in my projects. Depending on what you're going for, my approach is overkill if your character does nothing but get in a car and turn a steering wheel. Unless he can climb walls, pickup objects in his hand, and do flips too, an IK solution _could_ be a terrible idea.

 

Its very doable with Mecanim, but like usual, Unity tutorials simply don't provide good example to grow yourself from, and there's nothing on Youtube that's free and shows this in action.

I'm not asking for a complete GTA controller here. Just practical examples. This is a game engine, so showcase that.

You have to go to better knowledge sources like Penny De Byl's animation courses on Udemy to learn how to even use the system properly. Or pay for the things like Filmstorms patreon.

Iv tried using Unity's methods to do things and teach myself. But they cant even properly explain how to use their new Prefab system [which I have grown to dislike...] or Mecanim System, or even a USEFUL way to use ECS [which looks really cool, but ultimately useless if you can't figure out how the crap to actually use it.]

We want BETTER guides in general. If those guides are a proper character controller that's notated via code...so be it. But if you can't sit down a 10 year old in front of your video explaining how to do something simple then frankly....your guides are not good enough.

 

I think the point is, Unity is not really a game engine. It is a toolset containing common tools for game development. You have a character, an animation component, a NavMesh and physics, all as separate components. You must find a way to combine all of that to make your specific, limited game from it. So there will never be a standard character that will work out of the box. That's too bad, because as you know, 90% of the time is going into building your own basic game specific systems, if you can do it at all.

I hope the future will see fully functional components usable out of the box, but I don't see it (at least not with Unity).
I mean, speaking first/third person character controllers we already have a few established control schemes. You *could* already develop a character controller that works in any game, be it racing, fighting, adventuring. But I don't see it yet.

 

Its more like:

 

If you are referring to a character controller that -only- combines physics and animation in a more generic way, then yes, Unity Team could _definitely_ make Third Person Controller that "works" in any game (except maybe not a fishing simulation game... or even a 2d-scrolling infinite runner / space-shooter game... and perhaps it might not be suited for any FPS virtual reality game either... etc. etc. -- You get my point hopefully.)

Ultimately, saying something "works" is just a roundabout way of saying it does what _I_ need it to.
But when there are thousands of users, what "works" for what _I_ need isn't always generic (or specific!) enough to work for everybody else.


Truth be told -- I would much-prefer a super-general system that deals with physics and animation (in elegant ways) separately (letting each inform the other, while letting neither dictate the other). This would allow animations to be easily editable, while physics remain responsive (i.e. like the Overgrowth video I posted above handles both -- just put a GUI wrapper around it plz?) It should be "easily-gutted" too (if I wanted to replace parts of it completely.)
One caveat though -- that nice-looking controller @willgoldstone and his team are working on now wouldn't be a reality if they went solely for what _I_ wanted (a very minimalist controller.) So I can't knock them for it. For what they have, they are doing an excellent job.

 

Also -- this is in direct conflict with what you said about wanting a controller that can be used in _any_ game.

Sorry to pick on you but...

It can either be "fully-functional" or it can "work with any game" -- If you genuinely think any character controller can provide both of these for you, then you're either delusional, have your own dev team programming for you, or you don't wipe your own bottom. I'm sorry if that sounds harsh, but some people need a reality-check.

 

Very well put. To give an example we are currently using this very character controller as a base in our game and we found it very easy to add new functionality that is not covered by it. Currently we are adding a wall run mechanic for example.

 

Man... instead of asking how I mean it or how I would design it you instantly start to hate. And some deadheads even like that. What is this forum? A Unity fanboy meeting?

 

It's not hate. It's an acknowledgement about the fact that you know nothing about game design and development and you cannot see that character controllers are diverse subject. Almost every game needs their own one because it contributes VERY much to the feeling and the mood of the game. And of course it diverse by genre (or the lack of it).
If you use standard character motor and you don't change anything, you're making some average game at best (so you can have the 638th "game" released that day when you release). It shows the lack of attention to details. And the game (and the devil) is in the details, as usual. So nothing personal, no one hates you or what you're saying, we just recognize that you may be not the best spokesperson for this entire thing you're talking about due to lack of basic knowledge in the subject. Feel free to take the offense if you would like, although I have to mention that it wasn't my intention with it.

I am against the idea of "Standard Assets" and in favor of a "Prototype tools" because of this misunderstanding you're showing very well.

 

To be fair, I expressed zero "hate" in my assessments of your commentary.
I am one of the first to give Unity grief about poor design choices (and there have been some doozies!) -- but they're trying very hard to finally get it right this time (they're remaking the entire engine, bit by bit!), and for that, they deserve at least a little support from us. There are actual people working on this stuff (even if you don't see them), so try to keep that in mind when criticizing them.

Also, I didn't ask how you "meant it" for some of the same reasons @Lurking-Ninja pointed out -- namely that it was clear you obviously weren't aware of the kind of design challenges you wanted magically solved for you.
Maybe after making a few of your own controllers, you might come to also appreciate the inherent magnitude of the design risks and inherent responsibilities @willgoldstone and his team are taking on (willingly). A flexible, nice looking, generic character controller that "works" for thousands upon thousands of different kinds of users is a monumental task.
Whether you're a "Unity fanboy" or not, those guys/girls deserve your support regardless. They are doing their best.

 

Any news on "extensible for combat scenarios" stuff? Or at least can we get some suggestion on that to make sure we are on the right path ?

 

Do you guys have any thoughts of just buying the KCC and replace the old Character Controller with KCC? That would be great!
If you then create a nice implementation-example as a standard asset on how to use it together with other tools such as Cinemachine, Mechanim, movement calculations, input handeling, etc. that is fine as well fo course.

maybe the KCC kan be the ground for OCC as well, if you buy it?

 

OCC actually can be a nice choice either, a very different approach of KCC was that you need to translate movement motion vector to velocity (that's not a big issue though), since KCC is not in active dev, i suggest you to stick to OCC for now.

see my post here: https://forum.unity.com/threads/new...cters-third-person.526612/page-4#post-4062571

 

A friendly reminder to not feed the trolls.

 

I don't think dismissing opinions like that helps the sudden friction that seems to have appeared here. In fact it's far from friendly if it's received by someone that is misinformed but interested in getting involved. I doubt this is a case of trolling - it's one of different skill levels, different understandings and different expectations of a product that is both 'in progress' and 'loosely defined' right now. Branding people with blankets statements will only annoy someone that we perhaps need to help with a clearer technical perspective.

Let's just keep feeding back to Will with the bit's we've liked and the problems we might have faced with each iteration. The more we keep it on track, the more everybody benefits.

 

Your point about keeping it on subject is a good one and reflects my sentiment. Definitely no judgement here regarding technical understanding, I'm learning lots all the time myself. Regardless of understanding, a productive attitude should be advocated for and I think the posts speak for themselves. My suggestion is simply not to engage. The intent of my post was not name calling - it's idiomatic (although point taken, it arguably may not strictly be considered trolling.)

 

Ok. Sounds like a sound suggestion. Going for OCC then.

 

No problem! -- You guys are doing a great job working with what you have!


Honestly -- regarding the additive approach in the GDC talk -- I _mainly_ posted the video to show (and _emphasize_) that physics and animation should be separate systems (that each system informs the other, rather than forcing one to maintain control over the other in some unwieldy way.)


Assuming Mecanim is at the core of the TPC's current design, I do want to point out the magnitude of this as a fundamental flaw in an otherwise great design.

A major reason why so many of us have problems with Mecanim's approach is that, by design, it essentially _forces_ us to choose between physics to be controlled by animation, _or_ vice versa -- but no in-between!
So _either_ the API is too verbose, limited, awkward/unwieldy (priority was to "provide a simple UI"), which makes it difficult/tedious to script, _or_ it is disgustingly difficult to manage complex animation changes once they quit neatly fitting into distinct/separate "states" anymore (less programming, and blend trees help, but these can be just as tedious / convoluted to setup). This all makes controllers difficult (tedious) to manage from either a physics _or_ an animation standpoint. Thanks to Mecanim's design, one or the other nearly always remains fundamentally unwieldy.
Kinematica seems like a really good start to fundamentally fixing the fundamental TPC issue, but I actually hope it becomes a full additive-animation solution for making character controllers (rather than just authoring nice-looking walks.)

I don't mean to be so critical, but now that we have Timeline and Cinemachine, Mecanim's basic design (and overall approach to animation) has really become quite dated, and is greatly affecting any tools (i.e. controllers like this one) built on top of it.
IMO, we seriously need (at some point in the near future) to move in the direction of user-configurable additive animation -- and not necessarily in the way of the GDC talk, but with the advent of C# Animation jobs, perhaps we can move in the direction of _Gang Beasts_ at least? lol

Just thinking out loud here...

 

Speaking of Kinematika this might be a as good a place as any to ask. What is going on with that? I was very excited with the prospects of that system but it seems to have died.

 

I don't think it's due to appear until 2019.3.

 

the 2019 roadmap also said someting about "new C# animation system in line with ECS" which planning on 2019.2.

so, SAC's approach of animation may drastically change then..(will they?)

 

Yupp, you've a point here. Just wanne say sorry for my offensive Baby-Post. It was issued by some frustration and arrogance. Keep up the good work, guys!

 

I think mecanim is not THAT BAD though, you can check an asset named Animancer which address some mecanim's problems, but it take trades-off of lacking designer tool(e.g. preview animation transition time).

besides, you can check `ThirdPersonBrain.cs` and `ThirdPersonMotor.cs`, they are indeed separate systems, also you can choose RootMotion/Non-RootMotion (or even in-between) as you like

 

EDIT: Nevermind, problem is solved by changing Animator update mode

____________________________________________________

I noticed something didn't feel quite right with the character's movement (didn't feel as smooth as it should be), so I did the first thing I do with all third party character controllers: see if they interpolate properly.

We can test this by setting the fixed timestep to something very high like 0.2. Even in those conditions, the character should still move smoothly, and the only downside should be input responsiveness. But here you clearly see that the character's visuals are not interpolated:


Turning Interpolation to On on the rigidbody does not solve the issue since rigidbody movement is not done entirely via rigidbody.MovePosition(). What I usually do in this case is avoid rigidbody interpolation entirely and just make my own instead. Just creating a "InterpolateCharacter" component that Lerps the mesh root between rigidbody updates will do the trick.

You may think the choppiness will not be noticeable at a 60fps fixedUpdate rate, but it is. That's because the camera runs on Update (meaning up to 75fps on most monitors, and possibly up to 144fps on others), so you see a slight disconnect between the smoothness of the camera movement and the smoothness of the character movement. It ends up giving a slight choppy feeling to it. On a 144hz monitor it is very noticeable, assuming the game also runs at 144fps or at least >60fps

Interestingly, the animation also seems to run on FixedUpdate. I wonder if it is easily convertible to Update() instead?

 

I think it's a chinemachine problem, try disabling the chinemachine state driven camera script

 

even just looking at the character in scene view, you can see it is not interpolating:


The cinemachine camera does rotate properly on update, but its position moves on FixedUpdate because I assume it's just "anchored" to the character

 

I see now, but is this really needed by most devs using this package?

I figured it out, you need to set the Animator's "Update Mode" to "Unscaled Time"

 

Lack of movement interpolation is something that's hard to put your finger on but it does have a huge effect on the "feel" of the game, especially when you compare side by side with a properly interpolated character. And most devs will never understand what the problem actually is so they won't try to fix it.

Now that Standard Assets are being remade, it would be a good opportunity to fix this. It's a pretty simple fix, too

this does fix the animation problem, but not the character movement problem

 

I understand now thank you.

For me this is the result:

 

Wait you're right.

Setting the animator to "Unscaled time" or "Normal" does fix the issue of movement interpolation, but only because movement is not even processed on FixedUpdate anymore. This means that your character is smooth but moving platforms aren't:


Now the question is: is there a way to have both the moving platforms and the character be smooth

____________________

EDIT:
ok, moving platforms here are Animator-driven as well, so setting their update mode to Normal also fixes that issue. The only question I have left is: Does the FixedUpdate animation serve an important purpose for this CharacterController? And if so, how can we have FixedUpdate animation AND smooth visual movement

 

Looking good so far, however I do have a few issues to point out.

• There should be a toggle that forces the character to always face the crosshair, similar to the strafe mechanic. This option would be very helpful for people creating a third person shooter.

• There is also a lot of mouse deceleration. Moving the mouse slowly actually turns the camera much more than moving the mouse quickly. The mouse's speed shouldn't affect how much the camera turns, only the distance the mouse moves should affect how much the camera turns. Either get rid of this mouse deceleration completely or add an option for raw mouse input.

• There is another issue with mouse input which I believe is an issue with the Input System rather than the third person controller. If you move your mouse and pick it up while you're moving it, the input gets stuck and the camera keeps scrolling. Turning on "Continuous" in the "look" action fixes this issue.

 

Looks like the old Unity stuttering problem no one found a solution for yet. There are lots of threats about it, some starting around 2012 and still active. The best solution (fixing most of stuttering) is updating all movement in Update() or FixedUpdate(), but not both. Using Update() is the best solution, because this way movement matches rendering framerate. But this has issues when bumping into walls. The only thing working so far for me is doing the PhysX update by hand ( Physics.autoSimulation = false ) and using variable framerates (Time.deltaTime) for it. But this has issues when your framerate is low, because collisions might be missed. Still found it to be the best method, but never tested it in a commercial project.
There seem to be other reasons for microstuttering, but the Update()/FixedUpdate() problem seems to be most common.

EDIT: Just had a look at my code. Missing collision in case of Physics.autoSimulation = false can be avoided by simulating several PhysX steps by hand in one Update().

 

hey there, i have an issue with the asset, i downloaded it from github and draged the files inside unity, but i cant use anything cuz of the over 73 errors i get when i draged the files heres the pic, i just wanted to test the fps, as you see im new in to unity

mu unity version is 2018.3.0f2