[Released] Character Movement Fundamentals - A Rigidbody-based Character Controller

Thanks! A screen recording would be very much appreciated, if you find the time!

 

I was wondering if somehow we could do so that we could have a 'lock target' and when moving left/right it would orbit around the target.

I saw you had a LookAtTarget script but i'm not using your camera but Cinemachine instead.

 

Well, continually locking on to a target position (or object) while moving left/right will already cause the character to orbit around the target (at least if the character's movement direction is dependant on the camera view).

Currently, the locking-on functionality is only available as part of the 'Camera Controller' component.
However, you can absolutely use the included camera scripts in combination with Cinemachine (a few customers have done so in the past and it's not that hard to do).

If that's something you're interested, just contact me via the support mail (support@j-ott.com) and I'll help you set it up!

 

E-mail sent !

 

So I finally got time to check out and reproduce the issue, and turns out I was wrong. I had set the Ground Friction to 0 while I was experimenting, prior to understanding its function. Sorry!

 

No problem! I can see how all the component variables can cause some confusion.
I'm planning to eventually add inspector tooltips, so users can read a description of what each variable is for (and recommended ranges) without having to look in the manual.

 

Hi, having some trouble here. I'm working on a VR game and tried to convert my Camera Rig to be like the FirstPersonWalker example prefab. Every LateUpdate I reset the capsule collider's height and center to match the player's camera position (see screenshot). Because it's a VR game, the camera position can change every frame which is why I need to update the collider repeatedly. Right after updating the collider I try calling mover.RecalibrateSensor. This doesn't seem to work. It doesn't look like my sensors are changing to the collider's new position. I also tried change the LateUpdate to FixedUpdate, but I get strange results. My Camera Rig game object will float in the air for some reason.
Do you know what the right way would be to update the collider's height and center every frame and then update the sensors? It seems like this should work. I'd really appreciate any help with this.

 

I just saw that you also contacted me via the support email adress, so I'll respond to you over there so (if it's okay with you)!

 

Quick update: Version 1.3 has just been accepted by Unity and can be downloaded at the Asset Store now.

Most of the changes in the new version adress the bugs/glitches that were reported by users during the last few weeks (thanks for the feedback).

Since some of you probably made changes to some of the included scripts (especially 'Mover' and 'BasicWalkerController'), I'd highly recommend creating a backup of your project before updating, so you don't lose any of your progress.

Spoiler: Version 1.3

[NOTE: If you modified any of the included scripts in an earlier version of the package, please make sure to create a safety backup of your project, so none of your work is overridden by the new changes.]
- Overhauled "slope-sliding" algorithm of 'Basic Walker Controller'. As a result 'Slide Gravity' now works more predictable and efficient.
- Added 'Use Local Momentum' option to 'Basic Walker Controller'. If enabled, controller momentum is calculated in relation to the controller's transform rotation.
- 'Sensor' and 'Camera Distance Raycaster' now use a different method to exclude certain colliders when raycasting/spherecasting. This fixes several glitches in the latest Unity version (2019).
- All visual scripts ('Turn Toward Controller Velocity', 'Smooth Position', 'Smooth Rotation', [...]) now can handle being enabled/disabled at runtime.
- Added 'Ignore Controller Momentum' option to 'Turn Toward Controller Velocity' script. If enabled, only the controller's movement velocity is used to calculate the new rotation.
- Some minor renaming of some variables to improve general code readability.

If there's any questions about some of the new features, please feel free to ask in this thread or directly by email (support@j-ott.com).

 

What's the proper way of limiting velocity ? Like not going faster than "x"?

 

The easiest way would probably be something like this:

Code (CSharp):

1. float _velocityLimit = 10f;
2. velocity = Vector3.ClampMagnitude(velocity, _velocityLimit);

Depending on your game, you might put this code right before the 'mover.SetVelocity()' function, for example.

 

Hey, I'm a little confused. How do i set this up using my own model?

 

I'd recommend the following:

• Create a prefab copy of one of the included 'animated' controller prefabs (whichever fits closest to the kind of gameplay in your game).
• Start modifying that copy by first removing the 'AnimationControl' and 'AudioControl' (both located at the root of the prefab).
• Then replace the 'CapGuy' default character (located at Root > ModelRoot > Model > CapGuy_Model) with your own character model.
• At this point, you'll need to setup your character's animations (by creating and configuring an 'Animator Controller' using Mecanim).
• Lastly, you'll need to write some simple scripts to pass the relevant data (movement speed, whether the controller is grounded, [...]) to the 'Animator' component containing the 'Animator Controller' you've set up before.

Of course, you can also create the whole controller setup from scratch (using the components in the package), but this option may take a bit longer.

(Edit: Changed some ambiguous phrasing. Please also see this comment below for more information.)

 

I'm really loving this controller!

I'm currently working on cutscene programming using the top-down controller. When the controller enters a trigger volume, I want to take away the control from the player and rotate the actual model on Y (not the camera) towards an object (switch, whatever) and perhaps play some audio, etc.. The issue is that rotating the transform of the controller causes later issues for me, so I'd like to rotate the rigidbody and keep the rotation of the player transform at 0. The rigidbody is being overridden by the mover component. Any ideas on how to accomplish this?

 

Hi Bavatt,

Since my last response caused some unintended misunderstanding (sorry for that), I'll try re-phrasing my response for clarity's sake here.

Like I mentioned earlier, the fastest way to get your mesh up and running is to use one of the included controller prefabs in the project as a base.
To do that, you'll have to remove all the components and parts which are specific to the default included character ("Capguy") and replace them with your own.
This includes the mesh itself, as well as the 'AnimationControl' and 'AudioControl' components (which are written specifically for the 'Capguy' character).

The other option would be to create a controller setup from scratch, but this will take a bit longer (and will require some tweaking on your part).
If that's the preferable option for your project, here are some things to keep in mind when creating the setup from scratch:

• For the movement of the controller to work, you'll essentially need 4 components attached to the very root of your hierarchy: A collider (a capsule collider is recommended), a rigidbody, a 'Mover' component and one of the included controller scripts (found in Resources > Scripts > Controllers).
• Of course, if you've implemented a custom controller script, you'd place that there instead.
• I recommend adding child gameobjects to the root of the hierarchy and attach any secondary components (the character mesh, the camera system, [...]) to these child objects.
• The root/rigidbody doesn't really rotate in most cases (unless you specifically do so in code for special environmental gameplay reasons). So to rotate your character mesh toward the current movement direction of the root, please use the included 'TurnTowardControllerVelocity' script.
• For setting all the different inspector values for the 'Mover' and controller scripts, I'd recommend using the included prefabs as a reference or starting point. Beyond that, the manual has more information on what each value controls and what it is used for.

Also, thanks for bringing up the lack of documentation for this step in your review - I'm planning to adress that as soon as things settle down after the current Cyber Monday Sale.
And hopefully, if I find the time, I'll also be able to finally get to the instructional videos I've been meaning to create (to cover some of the commonly asked questions).
If that works out, 'Swapping Character Meshes' will definitely be one of the first things I'll cover there.

I hope this helps! If you have any further questions (or need any help with the asset), please feel free to contact me at the official support mail anytime (support@j-ott.com).

 

Hi jeffreyjene,

I'm not sure if rotating a rigidbody without the transform is really possible, since the transform is automatically set to the rigidbody's position/rotation in Unity by default.

So, I'd definitely recommend rotating the 'ModelRoot' gameobject instead of the root transform of the controller - since the root transform should only really be rotated for special (environmental) gameplay reasons like changing gravity (for example).

Normally, the character mesh is rotated by the 'TurnTowardControllerVelocity' script (which is attached to ModelRoot). So for the situation you've described, you could simply disable this script as soon as your character enters the trigger volume and then directly control ModelRoot's rotation.

I've attached a (very simple) example script called "RotateModelSwitch" to this post - try importing it into your project and attach it to the ModelRoot. By hitting 'H', you can make the model start/stop rotating around its Y-axis.
For your situation, you could replace the rotating code with something like Transform.LookAt, for example.

Please let me know if this solution works for your project!
Also, if you'd like to continue the conversation via email, please feel free to contact me at support@j-ott.com anytime!

 

Hi Folks !

Just wondering out; in a game i'm making i would like to prevent the character from falling; like having a platform and when the characters comes to the edge and he's not anymore grounded (but like the very first frame) i would prevent further movement.

Using BasicWalkerController i've added

Code (CSharp):

1.        
2. if (!IsGrounded()) {
3.             _velocity = Vector3.zero;
4.             currentControllerState = ControllerState.Grounded;
5. }
6.  

to the FixedUpdate() but of course it doesn't work and goes to an endless loop.
Is there another obvious way (rather than adding a gazzillion invisible box colliders) ?

Thanks !

 

Unfortunately, if 'isGrounded' returns false, that means that the controller has already lost ground contact during the last physics frame (so restricting its movement at that point wouldn't prevent it from falling).

I can think of a few alternative ways to approach this, but it's a tricky problem to solve in general. Anyway, here goes:

• A) The 'invisible box collider' solution you already mentioned. Depending on your game, this one could actually be the most reliable and stable way to go about this, but it's a lot of work.
• B) Using some kind of raycast/spherecast/sweeptest based system to detect if the controller is currently walking towards an edge. This 'edge check' would have to happen after the controller's velocity calculation and before Unity's internal physics calculation. It could be quite difficult to implement and has a lot of potential edge cases you'd need to account for, though.
  
• C) Some kind of detection system based on trigger volumes might work as well, but the same difficulties apply as in option B).
• D) This is kind of a stretch, but maybe Unity's built-in navmesh system could be "hacked" to work as a detection system? I have no idea how practical this solution would actually be, so please take this with a grain of salt.

That's all I can think of right now. If any of these options sounds viable for your project, let me know and I'll try my best to help (and maybe point you in the right direction).

 

Fantastic, thanks! I'll take this offline with you to chat about it. If you are curious what I'm building with your asset, you can see it here (just the movement and interaction points. I've modified the controller a bit to GetKeyDown for jump and some code to shut down velocity on cutscene). Thanks for your quick response! http://jeffreyjene.com/games/LL/DEVBuilds/

 

Nice! That WebGL build looks really promising! (Just out of curiosity: The game currently ends at the idol, right?)

Do you have a devlog (or something similar) for your project? I'd be interested to follow your progress!

 

Yep, it ends at the idol, just trying to test out the movement/physics and dialogue settings. The devlog is started and is here: https://wordpress.com/post/jeffreyjene.wordpress.com/37 Thanks for looking!

 

Thanks for the ideas; i went ahead with trying method B.
It kinda works; character is not moving forward (that much); but it jitters like insane; is this the input that's causing problem ?

Code (CSharp):

1.         // Prevents character from falling on edges
2.         RaycastHit hit;
3.         if (!Physics.Raycast(tr.position + modelMesh.forward * mover.colliderThickness, -Vector3.up, out hit, 1f))
4.         {
5.             float d = Vector3.Dot(_velocity, modelMesh.forward.normalized);
6.             if (d >= 0.0f)
7.             {
8.                 _worldMomentum = Vector3.zero;
9.                 _velocity -= modelMesh.forward.normalized * d;
10.             }
11.  
12.         }
13.  

 

It's hard to say what might be causing the jittering, but just based on the code itself, I'm guessing it's probably caused by overshooting when you subtract from '_velocity'.

I'd recommend starting a lot simpler, like this:

Code (CSharp):

1. // Prevents character from falling on edges
2. if(currentControllerState == ControllerState.Grounded)
3. {
4.      RaycastHit hit;
5.      if (!Physics.Raycast(tr.position + (_velocity * Time.deltaTime) + tr.up * 0.01f, -Vector3.up, out hit, 1f))
6.      {
7.          _velocity = Vector3.zero;
8.      }
9.  }

(This code goes right after line 135 in the BasicWalkerController script, by the way.)

Now, this should work on completely even terrain, but will break almost instantly when you try to walk up any slopes or stairs - that's one of the things that makes the whole problem so tricky to solve.

Essentially, you'll have to check first if the controller is walking into a wall/slope/stairs, before casting downwards - because if you don't, your ground check might start from inside a collider, and won't register anything.

Anyway, I hope this helps! If you have any specific questions about the code I posted, just feel free to ask (or contact me via email) and I can go a bit more into detail!

 

Bought it, fell in love with it.

Two suggestions:
1-) Click to move for TopDownWalker
2-) A variable to enable/disable camera turn for TopDownWalker

Otherwise, awesome asset.

 

Thanks, glad to hear it!

I'm planning to add a 'Click-to-move' walker at some point, but I'll probably try to finish the big restructuring update first (I'm already working on it).
That said, it should be possible to implement 'click-to-move' movement with the current version as well, by extending the 'BasicWalkerController' - if that's something you're interested in for your project, feel free to contact me via email (support@j-ott.com) and I can help you set this up.

Regarding enabling/disabling the camera turn: Have you tried disabling the 'CameraController' script of the TopDownWalker prefab?
This will effectively stop the camera from processing player input (which disables the camera turn).
You could also disable/enable the component at runtime by coding a simple script that enables/disables the component whenever a button is pressed/released (for example). Or if the controller enters a specific trigger volume.

I hope that helps! For any questions, just send me an email and I can go more into detail!

 

I'm really impressed with this character controller. Ive literally 95% done with my game, however I decided to do a overhaul trying to use your controller. Basically my character has a energy bar. Fly. Shoot. Shield. However, The only reason I purchased and want to use your controller, is purely because of the camera collision detection. I'm looking for two possible fixes to my problems. 1. Find someway to just use your camera system. Or what I've been doing for the past few days, is bringing all the scripts and redoing them for the new controller, Which I have been. Basically, I'm trying to add "Flying" to your system, which basically will just move the player foward while the button is being held down, and falling when letting go. Ive gotten the char to start moving up and forward, however the camera doesn't follow the player, and the character will fall thru the ground. Would be great if you could explain how you would implement flying yourself. I sent an email to your support address. However I'm reaching out on here as well, to get some feedback from other players. Really Just trying to get flying working. Everything else seems great!




Or find a way to get this camera system to work with my project. Which I'd glady pay for that help aswell so I can go ahead and release this game.

 

I'm trying to make the character rotate around target (while 'focusing' on it, like attacking).
I'm not using the CameraControler; the camera simply pivots around the character.

Problem is that the character slowly drifts off the 'perfect circle' around the target; like first quarter is fine then the character drifts slighly away ...

Using the BasicWalkerController i just modifed the CalculateMovementDirection ;

Code (CSharp):

1.  protected virtual Vector3 CalculateMovementDirection()
2.     {
3.  
4.         float _horizontalInput;
5.         float _verticalInput;
6.  
7.         _horizontalInput = player.GetAxis("Horizontal");
8.         _verticalInput = player.GetAxis("Vertical");
9.  
10.  
11.         Vector3 _direction = Vector3.zero;
12.        
13.         if (currentAttackState == AttackState.Relax)
14.         {
15.             _direction += mainCamera.transform.forward * _verticalInput;
16.             _direction += mainCamera.transform.right * _horizontalInput;
17.         }
18.         else
19.         {
20.             _direction += modelMesh.forward * _verticalInput;
21.             _direction += modelMesh.right * _horizontalInput;
22.         }
23.  
24.         //Clamp movement vector to magnitude of '1f';
25.         if (_direction.magnitude > 1f)
26.             _direction.Normalize();
27.  
28.         return _direction;
29.     }

And in the TurnTowardsVelocity i have :

Code (CSharp):

1.  void LateUpdate()
2.     {
3.         if (isFocusing)
4.         {
5.             tr.LookAt(target, tr.up);
6.             return;
7.         }
8.  
9.         /// rest is same
10.  

I don't understand why it drifts as no other momentum is implied ? any idea ? pulling my hairs out ! Thanks

 

I think I see the email you've sent me, so I'll adress your question via email if that's okay with you!

It's difficult to say what could be causing the drift by just looking at the code, unfortunately. If you find the time, a quick video showing the drift in action might help a lot to narrow down the problem.

However, here's one thing I noticed about your code (which may or may not be related to the drift):

When you calculate the controller's movement direction, you seem to directly use the camera's axes:

Code (CSharp):

1. _direction += mainCamera.transform.forward * _verticalInput;

I'd definitely recommend projecting the camera's axes on the "ground plane" before adding it to your direction vector:

Code (CSharp):

1. _direction += Vector3.ProjectOnPlane(mainCamera.transform.forward, Vector3.up).normalized * _verticalInput;

This ensures that your controller movement isn't affected by the camera tilt. I'm not sure if that's the cause of the drift, but it's worth a try.

And as always, feel free to contact me via email anytime, if you'd like to continue the conversation in private!

 

Yes it is for my project, it was a suggestion for Top-Down i already implemented click to move with TopDownWalker ^^

 

Hello JanOtt, just bought the package and tested it out and is is so great I love it.... and i got some questions... is there a way for character to slow down when walking up the slopes.... going down every step of the stairs is so snappy for me how do it down.... and how to solve this kind of issue... i tried adding colliders to the character but it just messes up.. sorry mate i am just an amateur

 

I don't know if I understood you correctly, but changing how slow the character walks up/down slopes and stairs is currently not included by default in the asset.

You could implement something like this with an external script that checks the current ground normal and increases/decreases the character's speed accordingly.

The specific implementation depends on your game, though.

I think I see what you mean. If you don't want your character clipping into stairs like that, you might want to try setting the 'Sensor Type' of the 'Mover' component to 'Raycast Array' (I'm assuming you currently use the 'Raycast' setting).
By doing this, you increase the number of ground contact points which will help detect stairs/slopes earlier.

I hope that helps! If anything's unclear or if you have any further questions, please feel free to contact me at the official support email (support@j-ott.com) anytime!

 

I have a difficult question.
Character Movement Fundamental and Easy Character Movement, What is different?
Please let me know in detail if you like.
I like your Profile icon.So I posted in this forum.

 

That's a tough question for me to answer, but I'll give it a try!

• In terms of features, both Character Movement Fundamentals (CMF) and Easy Character Movement (ECM) offer the same (or at least very similar) movement options (handling slopes, configurable jump, walking up/down stairs, [...]).
• Both packages use Unity's built-in 3D rigidbody physics for character movement.
• CMF currently does not support root motion out of the box (but I plan to add this in a future update eventually) - ECM already has root motion support.
• ECM's moving platform system supports rotating platforms, while CMF does not (yet) - I'll overhaul and improve the moving platform system in one of the next updates though.
• ECS currently does not support freely rotating the character at runtime, while CMF does. However, Oscar has mentioned in a recent forum post that this will be added in the next update.
• CMF's camera system is (currently) more advanced than ECS's. For example, CMF offers built-in obstacle detection for the camera (to prevent it from clipping into level geometry), as well as a third-person camera setup.
• ECS comes with built-in support for navmeshes, while CMF does not (yet).

In the end, it all depends on your game's specific requirements - so you should probably check out both asset's manuals, videos and playable demos and then decide which one fits your project better!

I hope that helps!

[Of course, this is just my interpretation (which is probably biased) - so I'd also recommend heading over to Oscar's support thread and get his opinion as well.]

 

Really Thank you!! I will ask this question in ECM thread!
Thank you!

 

Hi @JanOtt thanks for the great asset.

I have been trying it out and it's great, our game is 3D side scroller so most of the time the character is locked in a certain Z position (there's situations where he will move in Z dir like on a curvy path)

we faced an issue where the character can collide with static object and force it self to move along it something like this


so if moved to left , i will slide along the cubes and move in Z direction (i'm using the sidescroller controller provided) . so i tried to stop this behavior i made sure that the velocity going to "SetVelocity" in mover script has zero in Z dir but it still slides, and also tried to force the Z position in an update loop but it caused glitches and it keeps moving back and force.

is there's a work around it to this , i prefer not to force rigidbody freeze z as it does cause a little glitch and there are times where we will need the character to move a long curvy ways .

thanks

 

Thanks, glad you like the asset so far!

Regarding the 'z position lock': Since the asset is based on Unity's rigidbody physics, it's not really possible to prevent the character from moving in the z direction just by changing its velocity - that's because we're only setting the velocity but Unity's internal physics calculation resolves the resulting collision.

However, there's plenty of alternative ways to solve this issue - but it depends on your specific game (and the type of gameplay you're after).

Generally speaking, locking the z-position would be the most straightforward choice (since this directly affects the internal physics calculation, I believe).
To make this compatible with moving along curves, you could simply disable and enable the z-lock whenever you need.
However, if this causes glitches in your game, it's obviously not going to work here.

You could also try to experiment with invisible colliders (that you put in front of the angled wall) - that'd be the easiest and safest option since it circumvents the problem completely (and it's very adaptable as well).

I might be able to come up with more ways to approach this, but I'd need to know more about your game first - feel free to contact me via email (support@j-ott.com) anytime and we can discuss this in more detail, if you're interested!

 

Hello,

Any word of click to move, and disable rotation?

Thanks ^^

 

I'm still currently working on restructuring the existing code - as soon as I finish separating the input code from the actual controller, implementing 'click to move' controls should be fairly straightforward.

Regarding disabling rotation - how did the approach I mentioned earlier (enabling/disabling the 'CameraController' component) work out for you?

 

Thanks for the restructure! Really happy to know you are splitting things into Controller from Input, we can reassign keys easily that way.

Yes disabling CameraController did the trick.

 

I'm looking forward to the code restructure to separate input from control. Do you have an ETA on that?

I'm starting a new project and trying to decide what I should work on over the next couple of weeks.

 

Hard to say right now, since the code restructuring affects pretty much every part of the package.
I'm still working on implementing the changes and after that, I'll have to do a few tests to make sure everything's working properly (along with some polishing and updating the documentation).

What I can tell you is that the next update (version 2.0) will probably not be 100% compatible with code written for the older versions (version 1.0 - 1.3), because of the many changes (namespaces, new scripts, streamlined code [...]).
Adjusting any old code should be straightforward though, but it's something to keep in mind.

Regarding ETA: I'd guess that anywhere from 3 - 6 weeks from now is possible. It depends on a lot of factors, including how long Unity takes to check and approve the new version.

 

@JanOtt That's great to hear. Thanks for the update.
I don't mind the wait, and it's important to do it right. I'm fully prepared to have to rewrite code for the new version.

If the update is coming before March I'll keep working with my current set of hacks and prepare to swap them out for something clean later on

 

Hi. Been playing with the asset and have couple of questions.

1. How would you calculate "Real" velocity of the actor? I mean no the velocity that we want to set, but actual velocity of the actor that is moving in the game world. The actor could be blocked by the wall and has real velocity to zero or near zero, but Getvelocity does not give this taken into account. I have tried rigidbody.velocity and it sort of works but it gives jittering results because of Unity physics.

2. If I want to have my actor crouch, what /how settings should I set to simulate this? (in order to change the position/height or the collider)

3. I am not sure how to activate the acceleration (momentum ?) of the actor. It seems like the actor can change to opposite direction almost without any speed reduction. There seem to be code relate to this "momentum" but I was unable to simulate this.

4. When I move along the wall, but slightly towards wall, (because I could be using joypad) I want to slide off the wall much easier than currently is. Right now, it feels like it has way too much friction along the wall. How can I change this?

Thanks.

 

Hi castor76!

I think the most straightforward solution might be to simply track the actor's transform's position each frame and calculate its velocity based on last frame's position, the current position and the passed delta time between them.

If you're interested, feel free to contact me via email and I can go more into detail on that!

To change the collider's dimensions at runtime, you simply have to change the appropriate setting and then call the Mover's 'RecalculateColliderDimensions' function afterwards. For example:

Code (CSharp):

1. if(Input.GetKeyDown(KeyCode.LeftControl))
2. {
3.        mover.colliderHeight = 1f;
4.        mover.RecalculateColliderDimensions();
5. }

Of course, you'll still have to take care of all the other parts of crouching (adjusting movement speed, changing camera position, trigger animations, [...]) but that's it for the collider physics.

When the character is just walking around on the ground, its current momentum is probably '0' - the 'momentum' variable is really only used if the character isn't grounded (gravity affects momentum), if it loses ground contact or jumps (last movement velocity is added to momentum) or if the 'AddMomentum' function is called from an external script.

I hope this helps clear things up!

By default, the character's collider has the 'NoFriction' physics material assigned to it - so Unity's internal physics calculation doesn't cause the character to 'stick' to any walls. So definitely make sure that this physics material is assigned to your character.

However, if you're asking about "deflecting" the character's velocity along the side of the wall, that's a lot trickier, unfortunately.
Since the controller is rigidbody-based, we don't actually know where it's going to be in the next frame. This makes it hard to do any "wall-detection" before the controller actually collides with them.

That being said, what you could do is use one of the rigidbody's OnCollision() functions to calculate the current surface normal of the wall and take that into account during the movement direction calculation (by projecting the vector).

This would require some coding on your part though and there's a few edge cases to keep aware of as well.

I hope this helps! If you have any further questions (or if anything's unclear), please feel free to contact me at support@j-ott.com anytime!

 

Is there a discord channel (official or unofficial) for this asset?
Just bought it and I find it excellent and lightweight, the documentation is great too but I think it would benefit greatly also on a chat based system like discord.

 

Not yet, but a few users have expressed interest in an official channel in the past and I think it's a great idea.

I'm planning to look into creating a Discord channel as soon as I finish work on the next update. So if all goes well, there could be an official channel very soon - I'll definitely announce any news regarding this here when the time comes!

 

I just bought your character controller. I really like cinemachine camera blending. Things like talking/look at a npc, and blending from a 3d camera to 2.5d sidescroller camera and dolly track. How do i make that with the camera controller script so it feels like cinemachine camera blend?

 

I'm not sure if that's what you're asking about specifically, but if you want to use the 'CameraController' script in combination with Cinemachine, the easiest option would be to replace the Camera component in the character's hierarchy (usually found way down attached to a gameobject labeled 'Camera') with one of Cinemachine's virtual camera components.

This way, you can blend between the character's (virtual) camera view and other virtual cameras in the scene (and use Cinemachine's built-in functions).

If that doesn't work, please feel free to contact me via email (support@j-ott.com) anytime and we can discuss this in more detail!

 

thanks for the quick reply! Can i change from 3D to sidescroller camera smoothly on the same scene using the camera controller scripts provided in the example and without cinemachine?

 

Not really, at least on the current version of the package (1.3). However, it should be fairly straightforward to implement something like this by writing some custom code, though.

Of course, using Cinemachine's blending functionality might be even faster, in this specific case.