Actor Controller - an advanced character controller

@Tryz I have confirmed it does not have to do with the platform thickness (which is 0.01 btw). The issue instead is actually related to the z-rotation of the platform. Below are the notes for each of the three upside down ceiling jumps as demonstrated in the video. I show in the beginning of the video that I have "Keep Orientation" unchecked (as desired for auto-tilt-toward-ground behavior) and freeze position/rotation settings to facilitate the 2D movement in a 2.5D world.

1. Platform rotation is `0` = tunneling (bad)
   • Any value from 0 to .025 or .975 to 1
2. Platform rotation is `.26` = auto rotate in air as desired (good)
   • Any value from .26 to .974
3. Platform rotation is `.25` = freeze rotation not respected (bad)
   • Any value from .026 to .25

I'm pretty confident there is a bug in ActorController at the moment and I'm currently thinking it has to do with one of the `.25f` values in ActorController.cs. I'd be happy if I was wrong and I simply need to tweak a setting.

If I have a platform's z-rotation set to 0 or any integer I get the tunneling issue described in jump 1. However if I append .5 (to adhere to the jump 2 value range) to any integer z-rotation I get the behavior I want as seen in jump 2. As for jump 3, I think there is some bug where freeze rotation isn't respected because, as seen in the video, the character rotates along the y-axis undesirably.

1. Please share any insights you might have regarding this information and video demonstration.
2. Do you know of any games that have used ActorController with upside down jumps like I describe?

 

I don't have an answer for you. Your setup is different from what I typically see since you've got a long character, you're locking rotations, and using the ceiling walk.

If I had to guess, the 0 rotation on the platform is causing the the drop rotation to take a spherical path that your rotation lock is preventing. The code then finds the space above the ceiling is not blocked and fits in.

I think the best thing is to zip up the smallest project you can and send it to tim@ootii.com. I'll have to step through the code to see what's happening.

 

@Tryz Below is a video demonstrating the various scenarios (I didn't respond sooner as I was out for a week).

I emailed you the project with the same scene I used for recording the video below.

• I typically test using a controller vs. the keyboard, but the arrow keys and wasd work for movement where spacebar is for jumping (hold for longer jumps).
• Just walk into walls and keep walking for auto mounting to get into the various ceiling positions.
• You can test a .exe version via the "Deliverables" directory that's adjacent to Unity's typical "Assets"

 

Hi,

I am, really interested in your Actor Controller. Is it possible to get a version for Unity 5.6?

 

Hi. I'm afraid not. It takes too much time to maintain on much older versions of Unity.

 

Hey team, I'm getting stumped on a similar issue. I'm using the motion controller (and actor of course). Character is fine when parent object is not moving, but if I get on board the ship and the ship moves in a straight line continuously, the character is pushed in the direction the ship is moving.

Pretty much get shoved to the front window because I guess the velocity of the parent (ship) is being applied to the character even though the character is not moving locally (localposition = vector3.zero for example).

I've tried messing around with all the actorcontroller.velocity settings. It works fine if I disable the actor controller of course or if the parent transform does not move... any advice?

 

Ah i figured it out I think, it was the ProcessPlatforming() method. I guess the actor controller was not designed with it being the child of the platform in mind? This solves my immediate problem;

Code (CSharp):

1. // ----------------------------------------------------------------------
2.             // Apply any platform movement
3.             // ----------------------------------------------------------------------
4.  
5.             if (mPrevState.IsGrounded)
6.             {
7.                 //ProcessPlatforming(mPrevState);
8.             }

Now onto the next!

 

Hey @AshyB ,

Sorry for the delay. I typically do all my support on the weekends due to my crazy work schedule.

The AC will "stick" to platforms like ships, elevators, etc. But, you're right about not putting it as a child. In that case, you're double-dipping.

What I means is that the AC will take the movement and rotation of the platform and use it. If you have the AC as a child of a moving platform, Unity will move the character and then the AC will move the character again!

I always think of the player as a root level GameObject of the scene and don't child it to anything that's temporary, moving, or not an organizational part of the scene... if that makes sense.

For example, this character is on a moving & rotating platform (Cube). However, it's not a child of the Cube.


With relative gravity enabled, the character can even "stick" when the platform goes upside-down.


So, you should not have to modify any code.

I hope that helps.

 

Hey Tim, thanks for the reply and I understand about being busy and having the weekends as the only time to do stuff

I also understand about the character being a root level object and normally that's how i use your motion controller in my other projects. Love the controller btw, i consider it essential kit and use it in every project where i need a player character.

In this current project its a space sim game, so I use a floating origin system and it was just easier to make the player a child of the spaceship when the "snapping" back to zero happens.

There are other issues at the moment not related to the controller, so I may change it back to having the player a root level object and then making it snap with the ship instead but there is just so many other things to get working

Curious, how well does your controller handle high speed with "being on a platform"? I'm toying around with different ways to make the ship fly fast, either do it locally and make the actual ship do 300m/s or make the ship go slow at 10m/s and then create the illusion of it going fast but i think that would suck when you see something like a stationary rock and it looks like your going fast but its actually slow.

I ask because i notice other problems with colliders and was wondering what your experience is with your stuff.

Non-related question also, I read through the camera and motion guides and I think I remember seeing somewhere that "if you own the motion controller you don't need the adventure camera".. is that still a thing. I tried to find it again but must be blind. Just using the camera rig that comes with the motion controller at the moment and was wondering if i need to import the adventure camera at some point in the future.

 

Thanks.

Gotcha. If it works for you, I'm happy.

When I was building, it I used speeds of 100 m/s for testing. What I do is break the movement up into smaller steps and look for collisions. So, if you were going through a maze really fast, you'd "deflect" off the walls to get to the expected end point without shooting through them.

I don't believe I tested platforms moving that fast. So, I'd be less confident about that. Not to say it won't work fine... it just wasn't one of my use cases. But, you you have me curious and I'll have to play around.

The Adventure Camera was deprecated and replaced with the Camera Controller. The Camera Controller is more advanced than the free cameras that I include in the MC, but it's certainly not required and you could even use a different camera asset. I try not to force you into having to purchase just my assets.

I hope that all helps.

 

Tim is it possible that depending on the speed the grounding ray does not "collide" with the floor?

I am unable to move sometimes and when I check the animator the IsGrounded is false. Because this is in "space" there is no gravity set in the scene or on the actor controller. Its relying on the force grounding as a sort of "Magnetic boots" approach. So there is nothing forcing the character to the floor. It's basically a "get close and then stick" approach.

Seems to coincide with the "snap back to zero" of the floating origin. If I enable relative gravity, its fine until the snap and then a millisecond later it's grounded again. I'm guessing because the raycast is done at point A then there's a snap and then point B which is the impact is not where it was expected so it becomes isgrounded = false.. or something along those lines. This is at a speed of less than 100m/s. I'm too scared to go faster at the moment lol

I have the same problem with some other assets that like to do raycasts, might just be a timing thing. I had to remove the space graphics toolkit floating origin system and make my own because they liked to do it in lateupdate which messed with cameras and a bunch of other things. So I built my own in update and it fixed the camera issues. Might just need to modify this other stuff to do raycasts in lateupdate or something. I think your AC already does it in lateupdate if the box is ticked.

It's weird, because its a child of the ship so the distance from the floor should not change much/at all.

 

I don't *think* that would be an issue.

I project out the movement of the character based on the movement of the floor and then do a raycast like you mention. As long as there's nothing that would block the character from moving with the ship, I would expect you to be fine.

For example, I did tests where a small platform I'm standing on went under a wall and the character had to be pushed off. Things like fast moving and rotating, but simple, platforms.

In the case of a huge battle cruiser and characters moving from deck-to-deck while the ship is moving, It could be an issue. My speed tests were pretty primitive... it moving and rotating platforms. While I know people have use the AC on things like motor bikes and simple boats the high speed and complexity of a space ship should may add conditions I didn't think off.

I'm doing position based on the previous position of the character and movement, forces, platform, etc to calculate the new position. Could you send me a simple example of what you're doing. I'm curious about the complexity of the ship, speed, turning, etc. If you could get me a simple example I could play with it. Please send to tim@ootii.com.

 

Hi, I have a problem in dynamic to add component with AC(ActorController). Share it here, and hope to have feedback.

Description:
When I dynamic to add AC component in script in game mode, AC can't not Create BodyShapes(Such Capsule Collider or Sphere Collider). And the code in ActorController.cs:
The BodyShapes.Count is 0 in function CreateBodyShapes();

Code (CSharp):

1.         public void CreateBodyShapes()
2.         {
3.             DeserializeBodyShapes();
4.             Debug.Log("BodyShapes.Count>>> : " + BodyShapes.Count);
5.             ...
6.         }

But when I set up and added AC in Editor Mode, it is normal and fine. The CreateBodyShapes() work right.


My game scene needs many entity, but only one need ac, but they are the same base class. So I need to dynamic to add AC to the main player.
Is there a way to init or create the colliders for AC after I adding the AC component dynamicly.
Thanks for help~

 

To update:
I solved the problem with a new specifical prefab with AC component. So that the main player use this prefab and other player use the old prefab.
This way is no need to add AC component dynamically.

 

@Tryz , Hi there - can this asset be made to work with Animancer Pro?

 

I've never used Animancer Pro. So, I can only go based on what I'm reading...

It seems like it's a replacement for Mecanim and it's responsible for managing animations. The AC doesn't really care about animations. It's used to move and rotate objects (and enforce environmental structures).

If you're trying to use root-motion, you'd need to create a "driver" that reads Animancer data and convert it into AC movement commands. That's totally doable. In fact, the Motion Controller does exactly that (for Unity's Mecanim animator).

So, unless Animancer does something to prevent the AC from working I would say they should work together. You just have to create the glue. Depending on what you want, there could be a lot of glue.

 

@Tryz , thanks for the quick response, as ever. I own your Camera Controller. Is the Motion Controller you mention your Third Person Motion Controller or something else? And, either way, I am reading it as potentially compatible with Animancer Pro... Also, is your Third Person Motion Controller compatible with your Camera Controller even if the camera rig is in First Person mode or some other mode which isn't Third Person?

 

The Third Person Motion Controller (MC) is definitely not compatible. It requires the Unity Mecanim Animator.

The Actor Controller (which is the underlying movement and collision system for MC) could use Animancer Pro, but you'd have to create a "driver" to make it work. The MC is a "driver" that translates Unity's animations and Mecanim into movement that it tells the AC to do. So, your driver would translate Animancer Pro animation into movement that tells the AC what to do. The AC then look at the environment and does what it can based on colliders, physics, etc.

For first-person, check out these posts.
https://ootii.com/knowledge-base/can-i-use-the-mc-with-a-first-person-setup/
https://ootii.com/knowledge-base/3rd-person-to-1st-person/

 

@Tryz , thanks again for your response. Hmmm. I may abandon Animancer Pro them. But can you confirm - does MC support Ability / Gesture animations too - you know, like hitting a rock with a pickaxe (mining), swimming animations (swimming ability), etc, that sort of thing?

 

The motion controller supports all of those. Ootii has a swimming addon for the motion controller as well as an interaction basic motion included with the motion controller. There are several videos on Tim's youtube channel.

 

[Cross Posted From MC Forum]
Hello,

I am experiencing odd behavior with MC (2.810), Unity (2019.4.16f1) and UMA (2.10.1).
When I start my scene the Player begins to slide automatically even though I have sliding turned off in the Actor Controller. The only way I can get it to stop is to toggle the Orient to Ground setting (with Relative Gravity off) on and off again.
I am sure there is something else I could do to prevent needing to do that, but I am not sure what it is.
Does anyone know?

TIA,
Boysie

 

I would suggest eliminating the UMA variable by finding a standard model of the same dimensions and using that instead. It could lead you to the problem.

 

I was thinking about that. I have the power tools asset you created, maybe I'll spin out a regular model from that.
For now the toggle works perfectly. I think it's just a timing issue. I have the Orient to Ground on/off toggle in a Start and I am guessing the UMA magic happens in a Awake, because the start toggle seems to fix the issue.

Thanks!

 

I've been around for a few years now, but UMA Power Tools isn't mine. It was created by UnLogick (Joen), who was with Unity at the time UMA was created.

Glad you figured out a solution!

 

Derp, I think I was talking to both of you together about something in the past, got my wires crossed, hehe.

 

Hey @boysenberry ,

It feels odd that you have to use that toggle. The sliding would only happen if the character's "up" vector doesn't match the floor's "up" vector within some reasonable angle.

Is there a chance that UMA is creating a character whose origin isn't pointed world-up?

 

I am not sure. I will look at it again today.
They just did a new UMA release that I upgraded to. It might have changed things up a bit, from what I unuderstand avatars are now viewable in Edit mode.
I'll let you know what I find.

 

Hello,

i am trying to change the ActorControllers center of rotation from the Feet to the body´s center temporarily. This is mainly to simulate zero-g movement in certain cases. If someone could point me into the right direction or share ideas, it´d be much appreciated.

 

This is quite old, but I am using Actor Controller with Animancer Pro. They are a nice combo.

 

Hopefully this thread is still active... I bought this because I'm trying to get an MLAPI project with 1k objects and, so far, this controller is helping me hit that goal. Everything's great, love it, 10x the built in CharacterController perf, groovy!

However... My characters are sticking to walls pretty badly and I'm curious if anybody has any suggestions as to how to fix this? I need the perf, but the stickiness is killer. My setup is... strange... and I don't have a driver that I'm using (movement is handled via ScriptableObject behaviors, happy to go into details if it would help.)

Anybody experiencing stickiness with this or is it just me? I did tweak the fixed update time a bit so maybe that's it?

Would love any thoughts while I investigate a fix, thanks!

Edit: For some clarity, I have some stacked boxes and seem to be sticking quite badly to the stacked boxes. Solid surfaces seem to be OK. Mostly...

 

OK I found the problem, though I'm still having issues with characters not being able to jump reliably in corners.

The auto created "body shapes" sets the Body Capsule's Top Transform to the head of the character. Sounds neat on the surface, but with the animations I'm using the character is leaning forward a bit and that slight offset was causing the stickiness when jumping. Removing the Top Transform and adjusting the Top Offset to fit the capsule to my object worked like a charm (with the exception of objects still struggling to jump when moving into room corners.)

Since my case is to have up to a thousand very simple actors running around, I opted to go for all of them having simple capsules. I made a small change to disable the auto-creation of the Foot Sphere shape and removed the auto-assignment of the Top Transform. Easy like pie!

Now it's on to objects sticking to walls while jumping in corners. One step at a time

 

Hi @HAMMERWANG ,

Good catch on the Body Capsule's Top Transform. If you've got 1000s of simple actors, keeping their colliders as simple as possible is the right approach.

For sticking to walls, are your walls slanted or pretty vertical? Can you send me some images or even better... a sample scene? Send those to tim@ootii.com. I think that's the best way for me to see what's going on.

I did a simple test in my "demo_Factory" scene where I matched your character setup and everything seemed fined. So, it may be something unique in your scene that I just need to look at. I'm happy to help.

 

Here's my simple scene setup:



Jumping in these corner bits while moving *exactly* in the direction of the corner of the blocks prevents the character from jumping entirely. My game only allows camera rotation in 45 degree intervals, so moving *exactly* 45 degrees into those corners is easy with keyboard input.

My setup is a bit strange as well, as I've adjusted the physics tickrate down quite a bit.

My current theory is that the grounded check is still messing with jump a bit. I've been unhacking stuff since moving over to this controller and some gremlins are coming out of the shaddows

I'm going to mess with this a bit more and let you know what I find.

 

I was able to reproduce this as well. The motion forward (and I think collision) are cancelling gravity. I need to look into this more.

 

Hello! How can I calculate the destination position after using AddImpulse? I tried this formula, but it doesn't works for me.

Code (CSharp):

1. Vector3 curPos = GetCurrentPosition();
2.  
3. Vector3 impulse = GetImpulseToApply();
4.  
5. ActorController.AddImpulse(impulse)
6.  
7. Vector3 destPos = curPos + (impulse / ActorController.Mass)

So in this example the final position is not equals with destPos. In this scenario I'm just trying to calculate it without any collision, so I thought it should be equal but it doesn't work. What could be the correct formula?

Thank you!


Edit: I'm applying the same force using AddImpulse to the same actor but the distance between the start and end position is never the same. What I'm doing wrong?

 

Hello again! I've hit a *crazy* issue where, with 1000 actors running around, eventually my frame time goes to over 1,000ms and it's all in physics raycasts. I've been trying to optimize character movement a bit (if I can hit 60fps with 1k actors moving I'll be over the moon!) so I've done a few things:

1. Disabled the "Use Unity Colliders" in the single Body Capsule I have for each actor.
2. Manually update in my own NetworkActorController script:

private void LateUpdate()
{
if (actorController == null)
return;
if (IsMoving && IsOwner)
actorController.ControllerLateUpdate(Time.deltaTime, 1);
}
3. Using ground layers, default only, with each actor on a separate Actor layer.

I've been debugging this for an hour or so and I literally have no idea where these are coming from. It seems to go away if I disable collision, but I haven't been able to pinpoint the root cause just yet.

Here's what my profiler looks like:


Any ideas?

I guess the TLDR question is:

What could be causing this explosion of raycasts? Secondly, any general advice for hyper-optimizing character movement for 1k simple actors?

Thanks!

 

Digging a bit more deeploy now that I have time...

It looks like collision being enabled is causing the while(true) loop in UpdateMovement() to fail to break by constantly, very minimally adjusting lDesiredDistance.

Here's an example:


I'm not entirely sure of the cause, yet, but I *may* just end up capping the number of iterations here and bumping lStepDistance up from 0.1 to ~my desired move distance.

I'm going to poke at this a bit more, I see what this is doing now but I'm still not sure *why*