Official New Standard Asset Characters - Third Person

So I just have one problem with this. Running up and down stairs that have a non-convex mesh collider just is not right. The character jitters when going up and just falls of when going down( like falling down mini cliffs).

 

Seems like this will be a huge improvement over the current standard assets controllers. The third person one in particular is feeling pretty darn good at this point. My one big complaint is that it seems you are forced to use root motion for the third person controller. For some styles that's probably preferable, but it would be nice to have the option to not use root motion and have direct control over movement speed parameters.

Similarly having to modify the jump height map curve is inconvenient. Seems like that curve should be normalized and there should be a scale parameter to adjust actual jump height.

 

The difference between Prince of perisa and Mario:

Prince of perisa has to finish his animation before he can jump.
Mario can jump anytime.

Wich one controls more direct?
Mario

Wich one has smoother animations
Prince

Idealy we should be able to choose between those, or even better blend between them.

With a prioritiy for control before an animation state can finish.

 

Well, it's never all or nothing, With root motion animator, you get a callback for before the root motion takes place, so you can make the mario decision if you so choose there, for instant response.

This control has always been available.

 

But will it look as good as the dog video from a few posts back?

 

I managed to make SAC 's ThirdPersonController work with KCC (replace OpenCharacterController with KCC), things are going well

moving platform also works like a charm:

 

Am I just blind or isn't there any way to define the base speed in the third person controller? (like the sprint multiplier for example) It would be great to set the max base speed to walking for example. If that's what the forward speed range slider in Ground Movement is for, it doesn't seem to work (It doesn't have influence on the Animator at least..)

 

Oh that looks great, could you give us some details about it? (I have the KCC too and would be very interested how to combine the two )

 

it's eaier than i think, just make ControllerAdapter to use a KCC based Controller, here are some code:

in CharacterBrain.cs change code to this:

Code (CSharp):

1.  
2.         public void Move(Vector3 moveVector, float deltaTime)
3.         {
4.             isGrounded = useKcc ? kcc.Motor.GroundingStatus.IsStableOnGround : characterController.isGrounded;
5.             AerialMovement(deltaTime);
6.             if (useKcc && m_VerticalVector.y > 0f)
7.             {
8.                 kcc.Motor.ForceUnground();
9.             }
10.             MoveCharacter(moveVector + m_VerticalVector, deltaTime);
11.             m_CachedGroundVelocity = moveVector / deltaTime;
12.         }
13. ...
14.         void MoveCharacter(Vector3 movement, float deltaTime)
15.         {
16.             if (useKcc)
17.             {
18.                 kcc.targetVelocity = movement / deltaTime;
19.             } else
20.             {
21.                 var collisionFlags = characterController.Move(movement);
22.                 if ((collisionFlags & CollisionFlags.CollidedAbove) == CollisionFlags.CollidedAbove)
23.                 {
24.                     m_CurrentVerticalVelocity = 0f;
25.                     m_InitialJumpVelocity = 0f;
26.                 }
27.             }
28.         }

kcc is a Class inherits kcc's BaseCharacterController, you only need one line code:

Code (CSharp):

1.  
2.     public override void UpdateVelocity(ref Vector3 currentVelocity, float deltaTime) {
3.         currentVelocity = targetVelocity;
4.     }
5.  

some field like startedSlide, radius etc.. use kcc's corresponding api:

Code (CSharp):

1.  
2.         public bool startedSlide { get { return
3.                     useKcc ?
4.                     kcc.Motor.GroundingStatus.FoundAnyGround && !kcc.Motor.GroundingStatus.IsStableOnGround :
5.                     characterController.startedSlide; } }
6. ...
7.         float radius { get { return useKcc ? kcc.Motor.radius : characterController.scaledRadius + characterController.GetSkinWidth(); } }
8. ...
9.  
10.         LayerMask collisionLayerMask { get { return useKcc ? kcc.Motor.CollidableLayers : characterController.GetCollisionLayerMask(); } }    
11. ...
12.  
13.             isGrounded = useKcc ? kcc.Motor.GroundingStatus.IsStableOnGround : characterController.isGrounded;
14.  

you may also change some code that change rotation directly to use `kcc.Motor.SetRotation()` method, e.g. in TurnAroundBehaviour.cs

full changes are crossing multiple files with some my own specific change, hope the description above help you.

 

Thank you! looking forward to test it

 

First time I noticed this. I would like to see more interfaces with more stuff abstracted out. More attention to performance.

Right now a number of third party assets beat this in both features and performance. And by features I mean core features not just tangentially related. And it won't be long until we see one or two of those take what they have and move it to ECS and the new job friendly physics api's also. How is this project going to compete with that? Especially in light of how sporadic the development is?

It doesn't really matter how much better this is compared to the old controller. Nobody cares about that. It's how does it measure up against the best modern implementations using currently available api's. Both from the perspective of what's available on the asset store as well as those looking to implement a controller themselves. It it can't complete on those grounds, then it's really not in a better state then the current standard assets controller in terms of who will use it.

 

Agree it looks good. I have tested it out and it works quite well. However, for me I ended up writing my own in any way. Some things was missing. Like configuring how slopes should be handled up and down, how moves over steep edges should be handled. Should the character lift from ground like flying over a steep edge (like being part of the physics just there) or follow the ground more exactly.

I also would like to have more Gizmos to se where ground hit occurs, where raycast hits when characters are falling, top, bottom, size (standing, grouching), orientation (standing, swimming) etc. of capsule (capsule collider is enough).

The behaviour (character interaction with environment, collisions etc), animations and movement can be separated but interchangeable between the different parts with for example events or other mechanics.

Completely customisable extendable and component based character system is what I want.

 

I just took a look at the strafe locomotion blend tree. Why is it so complex? I cant even wrap my head around it. How are we supposed to fit in custom animations into that?

 

Just some thoughts, when i try to do some network stuff, RootMotion brings real problem to me.

currently, SAC use a `Update() -> AnimationParams -> OnAnimatorMove() -> actual movement` way to drive OCC, we actually can't simulate multiple movement in one function call (because of unity's internal animation update process), client-side prediction become nearly impossible.

maybe the solution is implement an asynchonous simulation process, but it's really difficult to achive an asynchonous Command Frame System (which is common in networked game).

Or maybe there is a way to eliminate OnAnimatorMove call and force update animator to get animator.deltaPosition? (i tried calling `animator.update(0f)` but seems not working)

For me matching speed is much easier than RootMotion, so i'll try to eliminate OnAnimatorMove use (also can save some server-side cost maybe?)

 

Where is the Import Package? I can't seem to find it, and copying the _Standard Assets folder results in bad materials.
Importing the Package

• Import the SAC package.

 

Partial feedback - It is very difficult to add additional actions (whereby an action might be similar to how you've added Jump or Strafe). From my initial look, it appears as though adding new actions/movements would require a number of scripts to be modified/changed/edited to make this function appropriately. Therefore, my partial feedback would be to make this easier to implement. The list of "actions/movements" will definitely be based on what someone is trying to do, but right now it takes a ton of effort to do this (unless I am missing something completely). For example, I might want to implement Crouch or Shooting or Opening a Door or Entering a Vehicle (thereby triggering a separate vehicle controller).

Thanks. Just my partial feedback all intended to be friendly and open.

 

Implementing robust moving-platform support was a pretty massive endeavour in my experience, and not something most users would want to have to mess with. Actually I think roughly 2/3 of the time I spent on my entire CC was trying to implement proper moving-platform and rigidbody-interaction support. Some people do it by just setting the character as child of the platform transform, but this method is extremely limited and can cause countless problems

Implementing this caused a lot of design/architecture changes in my CC, so I would assume it might possibly be the same for this CC too. What I'm trying to say here is that if you don't implement that feature, many users who will try to implement it on their own may end up realizing that it's actually impossible with the current design to do this well and efficiently. I think it would be important for you to validate that it is in fact possible by prototyping the feature, and the sooner the better (to avoid massive refactors in the future)

I feel like it would be important to have support for this in a standard assets CC. It is pretty common in games to require characters to stand on kinematic or dynamic rigidbodies such as elevators or on the roof of a moving car

I don't have a well-prepared explanation for why exactly moving platforms and physics interactions are complicated at this moment, but the bottom line is that it will probably require you to cut your CC logic into several separate phases and impose a very explicit control over when certain parts of the CC movement logic are executed, when the physics is simulated, when moving platforms process their movement, etc... all these steps will be interlaced with each other and must be done in the right order

 

It should be possible to create a CC that supports both rootmotion and direct movement without sacrificing anything. All you need is to make it so that users work with the CC by telling it which velocity it should be having at this frame (not sure if that's the case here, haven't investigated enough)

As long as you have this mecanism, you can do both approaches:

• (direct movement) write a simple script that sets the CC velocity based on inputs
• (rootmotion) write a simple script that sets the CC velocity to whatever the velocity of the rootmotion is right now

 

Actually, RootMotion driven makes proper networking CC a nightmare, because we often have different FrameRate between Movement & Animation...

Also, i'm curious about you saying "countless problems" about parenting style moving-platform, can you give us some explanation or problematic cases ?

 

Everyone runs into the moving-platform problem eventually. Here is someone running into it yesterday - https://www.reddit.com/r/Unity3D/comments/ag0wzt/making_a_better_character_controller_how_can_we/

 

"countless" may be a little bit hyperbolic, but I can see two main problems

1. Tilting:
If you are standing on something that can rotate on the sides, transform parenting will not give you the expected result. You'd expect the character to always remain upright and anchored in the exact same spot on the horizontal plane.

A proper implementation would result in this:
https://i.gyazo.com/ed8806e66281317b82eea18e804f5461.mp4
...and a transform parenting implementation would give you this:
https://i.gyazo.com/54572454aebb3b3d880ffcfdd7518c4f.mp4

An example of why support for this is good to have is that you can have your character stand firmly on a moving boat like in Sea of Thieves: https://i.gyazo.com/321a1eff665461a53f2a4a7876b75ae2.mp4
The algorithm works even if the move/rotation speed of the moving platform is literally "99999999". The character will never move a single inch from where it stands, unless you want it to.

2. Transform parenting movement ignores the character's movement algorithm:
Consider what is happening here:
https://i.gyazo.com/29e8d92ebe834a7b390746fc0e1239e8.mp4

We are standing on a moving platform and we get pushed into an obstacle. Here the result looks elegant because my implementation of moving platforms makes sure the character always gets moved by the real character movement logic, so it slides perfectly against the surfaces and will properly register all movement hits if you need to play friction audio or spawn vfx. But with a transform parenting implementation, the character will never use its CapsuleCast to detect the collision agains the wall and slide along its tangent. Instead it'll get "teleported" inside it at every frame and will jitter between the two surfaces until it finally gets out eventually

This problem gets even worse if we get pushed into a not-kinematic rigidbody. When your character gets moved by parenting, it has no idea of how to describe that movement in a way that the physics engine can work with. Therefore, if you hit a rigidbody, you'll essentially get "teleported" into the other rigidbody and the rigidbody will try to decollide really fast. Your character will also try to decollide really fast. The result will look really buggy and everything will be jittering all over the place. Mass ratios and push forces will also be totally ignored

 

I think there are quite different ideas of what this asset should be. Personally I'd prefer something simplistic and extensible, to allow somewhat new coders to understand how it functions, and add what they need for their own projects. Others wants more advanced features out of the box. I can't say one aspect is more valid or correct than the other, but somehow these needs need to be balanced. In any case a good modular architecture that follows the current best practice of the language (whatever that is; I still don't know) would be a huge plus.

Edit: A whole other approach to this problem could be to make a tutorial of how the asset could be built, starting with the bare minimum and gradually adding more features.

 

is it just me or configuring mouse sensitivity with cinemachine free look are actually very painfull?
Edit: i think i found a bug for cinemachine (of maybe that's how it work actually). On Cinemachine brain when the Update method are using SmartUpdate or FixedUpdate, the camera move feels snappy but mostly jittery. Changing this to late Update make the camera move smoother. This is very noticable when used on First Person Mode

@willgoldstone
Not sure if this already in the latest SAC, but might want to add some kind of airborne controll settings overridable from script of course.
Right now when the character jump i can change the course of the character while he/she airborne.
and when the character jump forward, and while airborne we release forward button. The Character losing it forward velocity and just fall downward.
Now again those are actually just fine for some game mechanic. But have an option for that might be better

 

I'm finding that the CanStepOffset check is inconsistent, almost always passing when the step is smaller than the capsule radius even when the step offset is some amount smaller. Additionally, it seems to like to start sliding on slopes that are well within the slope limit. I thought this was a problem on my end (opting to only use the OCC,) but I tested the ThirdPersonBrain in Protoland and it seems to be a problem there as well.

 

Does the moving platforms require you to do anything special with the platforms, or is it all handled by the character controller? Don't have time to jump into the example project right now.

 

Looks really nice! Really appreciate the team looking and and acting on requests from this thread

 

Moving platforms looks good to me. And they just "work" which is nice. Of course I did get pushed through the floor when I was sitting on that blue platform that goes around the cube near the elevator. The orange platform that goes up and down pushed me through the floor. Not sure what to recommend - I've seen some people make the character pop up on the platform pushing them down and other people kill the player (as in being squished). Reason it happened is cause my cat jumped on my lap and I was paying attention.

Suggestions - Make it easier to add things to the Brain. Example: You have 5 Animator states built in (ie Jump, Landing), so if I wanted to add more I'd have to edit your code, or inherit and I'd rather do something that's easier (like some sort of Ability System).

 

Looks really nice so far!

I have some requests:
- Please make it possible to smoothly switch from First Person to Third Person view (and vice versa)
- Probably already planned, would be awesome to have Foot IK (especially when on slopes and stairs)
- Configurable or otherwise easy to add movement modes such as: swimming on surface/diving, climbing

Sorry if these are too much to ask this early, Ill keep my eyes on this thread for sure

 

@willgoldstone is walk mode going to be added?

 

Does this support character teleporting within same scene or to different scene?