Official New Standard Asset Characters - Third Person

Hello @awesomedata!

I actually don't want that. I want to know why things are done and how they are usually done. Like there are hundreds of games where you can climb on edges. Yet the examples and assets from the store for that barely work on a solid cube. Professionals do that all day and there have to be more proven ways of doing things. It's the same few problems with a lot of character controllers, like being able to jump up 89° angle walls like a mountain-goat. This has been solved a hundred thousand times in actual games since Quake1, yet in examples it's like "this works well if your gameworld is purely cubes".

 

still waiting ... and maybe someday see...

 

Believe it or not, I get that.

Sadly, Unity doesn't really hire AAA game programmers to do their "examples" and so you'll probably never get _quite_ what you want from them in this area either.
Many AAA games modify the physics down to the "engine" level in order to achieve some of the elements they need for the more "non realistic" physics you're talking about. For example, if a cube (collider) lands on another mesh and can "jump" when touching it, the only things you have to work with are that mesh's normals (and the normals of what you're after with the angle of the jump, etc.) If you want physics to be "ignored" or handled in a slightly different way, you tend to have to get into the guts of the physics engine to make that happen (i.e. don't "touch" surfaces that are 89° by simply shifting the character's collider's "downward" movement vector to move parallel along the normal's "slope" direction).

This is something I think a character controller should be able to handle (without delving into the physics engine), but that behavior changes if you want the character to "climb" those kinds of surfaces (like Link in Breath of the Wild). In order to get the kind of behavior you want, systems have to talk to one another (i.e. character controller and mesh colliders and physics system rulesets for movement).

This is often painful in Unity for reasons I wont get into here. Let's just say Unity's data and system models are simply not as "atomized" as they should be for this kind of ease of interaction.

 

Hi, I took open controller, and I have question how get velocity such as it was in a normal controller? If get m_velocity then there the speed is much lower than it was in the old character controller

 

So now, in April 2021, what is the status of this effort? Has it stalled completely? I see there's a useful PR that hasn't been merged since July 2020, and the last updated branch was 17 months ago...

 

Over a year since the last meaningful update in this thread.

It's funny that the world can go through a deadly pandemic and develop a vaccine quicker than Unity can put out a basic character controller.

 

On one hand; yes totally

But on the other hand, I feel like Unity's PhysX implementation is lacking a few crucial features in order to make a truly great open CC possible (as opposed to a closed implementation in c++), and maybe this plays a role in the delays we're seeing. It's possible to make a CC without those missing features, but you'll probably need to rely on inefficient hacks & approximations that will no doubt result in many bugs in many situations. In order of importance:

• "CapsuleCastAll"-type queries should have the option of returning one hit per triangle of a non-convex mesh collider, and not just one hit per collider
• Physics.ComputePenetration (or some equivalent of it) should give us accurate contact position information; not just the normal
  
• Physics queries such as CapsuleCast should detect hits coming from initially-overlapping shapes
• Need to be able to cast any collider shape in a generic way (would allow us to support cylinder-shaped characters)

I've added more detailed explanations here:
https://forum.unity.com/threads/dot...i-had-in-monobehaviour-physics-physx.1057004/

For years, I did my best to make a good CC under those limitations, and it's been an absolute struggle. It's only when I started messing around with DOTS physics that I discovered that all these features are totally reasonable to expect out of a physics engine, and they made my life 10x easier. I'm pretty sure PhysX is capable of all these things as well; but they're just not exposed in c#

 

Probably the main reason is the fixed PhysX update rate. No other Game Engine in the world uses a fixed update interval for it's Physics calculations. Everyone else uses the 'natural' frame rate used in all other systems including rendering.

That's also the reason for the Unity typical stuttering. Point is, you have to make a game to notice it. If you just work in your little sandboxed test environment, no Designer will ever tell you that your game stutters.

Yeah of course physics engine manufacturer wants you to call their middleware in a constant interval to get 100% predictable outcome, but I don't know of a game implementing this in the end. They all go back to frame deltaTime.

 

That's simply not true. Fixed rate for physics is the standard for most engines and is very important

Avoiding stutter is simply a matter of interpolating correctly

 

Not again a fanboy war. See Unreal.

 

That's only one engine, and it is the exception. They went with variable-rate physics because the tech debt of their engine would've made fixed timestep too much work to implement, and also as a compromise because non-technical blueprints users would have been confused by how to deal with delta times. It's not necessarily a bad solution, but there are substantial pros & cons

https://avilapa.github.io/post/framerate-independent-physics-in-ue4/#:~:text=Substepping is a technique that,completely hidden to the user.

But:

1. You can do variable rate physics in Unity with 2 lines of code if you want.
2. Character Controllers in unity are typically not even tied to a fixed update, since they work with physics queries instead of rigidbody physics. For instance, you can call CharacterController.Move() on Update()
3. You can see all kinds of proofs in existing unity games that character controllers can be smooth, even those that operate on FixedUpdate.
4. This is off-topic and I won't continue to argue. It has nothing to do with why good CCs aren't available/possible in Unity.

 

Fixed timesteps are definitely not uncommon, even some physics engines implement this internally, like Bullet Physics.

I don't know the exact reason why Unreal didn't do this but I doubt it was because it would be too much work for them to implement. I've maintained Unreal fork for years where I have turned their substepping code to run on fixed timesteps and it's not all that many lines of extra code even. How I've read this between the lines was that they had internal debate where other side wanted fixed timesteps and other side wanted to keep physics more as visual element that is always in perfect sync with the rendering.

 

Nice to hear this from you. I hope your progress with DOTS is in a good stage. Personally, after initial months of excitement on ECS I am in a wait state on it, concentrating more on procedural animation with Animation Rigging.
Do you have some good news on your side? Thanks.

 

Say hello to the new Starter Asset packages | Unity Blog

 

The only 2 reviews are 5 stars by people who reviewed nothing else ever. Legit

 

oh geez lol
Forum Link are broken so I returned here and the blog was written by By "Asset Store Team"

 

Does anyone achieve `animation retargeting` or `model replacement` with this new Third Person Standard Asset?
I found out mixamo characters or others skeleton models don't fit well with bone mapping in animation clips. So I tried to create an Animation Override Controller using my own clips and copying and paste each component attached to the asset.
But I found this so counterintuitive for beginners.

 

That just isn't true but debates like this always end up in religion-like debates.

I would never put anything critical such as movement in Update() apart from the local rotation of the camera, but I believe in keeping things in a predictable and replayable fashion.

 

Does anybody else think the Unreal-esque "robot" looks too tall/lanky -- like his arms are too short for his body?


This thing seems to run like a literal stick-man in the trailer.
Maybe it's just the FOV or something?

 

Is this project that we can find on GitHub (link: Unity-Technologies/Standard-Assets-Characters: Unity Standard Asset Controllers (github.com) same as Starter Assets

or something different?

 

Probably different, on Starter Assets the new player model is UnityArmature (the robot on the video thumbnail).