Feedback Request Unity to add support for arbitrary up-axis for CharacterController

So every once in a while I've seen people come on the forums talking about wanting to make spherical world games... and running into a wall with CharacterController.

Heck, I ran into the wall a while back with a game I was working on... and we literally ditched the game because we couldn't get it working (Rigidbody lacked the fine tuned controller CharacterController allows for, but it lacked the rotatability).

And it's all because Unity only supports the CharacterController being aligned with a primary axis of x,y,or z.


Thing is... since trying to make that game I actually have read the documentation and learned why it's not supported in Unity... and more annoyingly, that PhysX ACTUALLY SUPPORTS IT!
http://docs.nvidia.com/gameworks/co...de/Manual/CharacterControllers.html#up-vector

I remember getting upset, and then moving on with my life. And threads would pop up on the forums about it here and there... and I'd pull out the documentation for PhysX, explain how the CharacterController actually works.

And then begrudgingly point out this flaw.
(who knows, maybe Unity has a reason to leave it out... I just can't think of a reason why though)

And well it happened again today:
https://forum.unity3d.com/threads/issue-with-custom-charactercontroller.480952/

And you know what... it dawned on me. I can put in a feature request.

SO...

Anyone else who is annoyed this feature does not exist... please, vote to get it added!
https://feedback.unity3d.com/sugges...-in-physx-feature-pxcontroller-setupdirection

 

Oh and if anyone is interested in my other feature request.

CompareName:
https://feedback.unity3d.com/suggestions/comparename-option

I think we should have a CompareName option to reduce garbage issues when calling 'GameObject.name'. We get CompareTag for 'tag', but not for 'name'.

 

I think the issue with not having COmpareName is that it will cause unity to create storage index for all game objects name, and that will cause a lot of RAM at runtime....

 

Why would they have to create a storage index?

They have a way to retrieve the name, that means they have it on the unity side already. It's just that when you retrieve it, it has to create a managed object on the C# side causing GC caches.

The other way around, you create an unmanaged string on the unity side when CompareName is called and compare it there... and delete immediately.

 

Does anyone use the character controller I thought most rolled there own for there own use case

 

Ran into the same problem, use rigidody instead either with rb.MovePosition or modifying its velocity based on a normal. The movement result is pretty much the same as the CharacterController + better physics interaction

 

We use CharacterController a good deal of the time.

It controls very differently. You get much different effects. It's not as 'tight', so when you want to make a really 'tightly' controlled game... like a precise 2.5d platformer... it always feels just a bit off.

...

Anyways, since the PhysX API has it literally sitting right there. It's right there, just gotta open the function up. Why re-roll your own?

 

Stopped using it the moment I learned the performance impact of Move and simpleMove. Had like dozen characters and frames took a serious dive when I tried to move them. For my understanding most used methods for moving characters are physics and animation root motion.

 

So now that unity no longer has the feedback website and instead it's now part of the forums... I wanted to re-bump this.

Especially since I'm currently considering a game design in my roster that would heavily benefit from this.

 

The messaging I have read is that Unity doesn't consider either their old character controllers nor their new one (https://github.com/Unity-Technologies/Standard-Assets-Characters) for production. They intend them for prototyping primarily. The new one is pretty nifty and should be helpful in making your own though.

My recommendation however is to check out Kinematic Character Controller on the asset store. It's excellent and does arbitrary up direction.

 

I've heard people say Unity says this.

But I've never heard Unity say this... do you have a source of them saying this?

Cause heck, the character controller is really a PhysX thing (i link to the PhysX documentation in my OP), and it's not considered a prototyping thing in PhysX. It's an actual production thing.

Unity also uses it through out a lot of their tutorials for years, and years. I'm just highly suspect of this claim that I hear people say.

And that PhysX thing though is to my main point... the underlying PhysX controller that Unity is using has a method for setting the up vector. It exists. They just need to uncover that method on the C# side... that's it (unless for some reason Unity doesn't use the physx character controller, which would be a huge surprise to me... considering it behaves precisely the same, and Unity uses PhysX). I want precisely the behaviour that is the CharacterController component, just with variable up. Exactly how it works in PhysX.

...

But yes, in the mean time I"m checking out the Kinematic Character Controller on the Asset Store.

 

Six posts down on this page, regarding the new Standard Assets Controller:

https://forum.unity.com/threads/new-standard-asset-characters-third-person.526612/page-3

The way I see it is an asset either satisfies your requirements or not. If it doesn't, you don't really have a choice except to make it yourself or modify and extend that asset. Character controllers are usually pretty complex and have to interface with many other systems in your game. A one size fits all solution is impossible. That's why I recommended Kinematic character controller. It has a lot of solid and flexible functionality without any frills so you don't have to delete or work around a bunch of features you may not need for your game. The standard assets controller is still very useful though. I have taken some ideas from the way they have implemented certain things for that controller.

 

This is irrelevant. Unity does not want to support these assets for production because that would open another ugly can of worms. Every lazy developer who does not want to write their own character movement would get in line to demand all kind of extremely specific feature. Also although they're doing a great job with the movement in the new controller, the old ones were kind of jerky and not production-ready by any stretch.
We all know that character movement is really one of the signature of a great game, so using a canned movement system without modification is not the best idea to make a great game. It's good enough for an asset flip though.

These are the reasons why Unity says their solution is for prototyping and not for production without serious modifications. You can do that but it's not supported.

 

The only thing I see is a unity tech saying "as this asset is for prototyping...", and they're not even referencing the built in CharacterController. I'm not sure what this is evidence for then.

I agree a one size fits all solution is impossible. But I'm not asking for a one-size fits all solution. I'm just asking for the existing 'CharacterController', the one that merely wraps the PhysX character controller (as far as I know) to uncover a feature that already exists in the PhysX controller just doesn't have a C# wrapper method to it.

I have a strange feeling we're talking about different things though... I hope you don't think I'm talking about the 'Standard Assets First Person (or 3rd person) Character Controller' scripts that you can import... I'm talking about the 'CharacterContoller' component:
https://docs.unity3d.com/ScriptReference/CharacterController.html

That simple thing.

And sure you've made a suggestion for a 3rd party asset. I already said I'm looking into that asset. Doesn't mean I'm going to just give up on my request though. With that said, thank you for the suggestion, it may meet my needs and get me to what I'd like faster than waiting on Unity (which has been a 10 year endeavor).

I don't see how it's irrelevant. It's not a demand for added features... it's a request for a standard feature that already exists within the physics engine (PhysX) that is used by Unity. It's merelly a request to create the C#->C++ wrapper method that gives access to something that exists. And is a fairly simple, uncomplicated, part of PhysX.

Where do they say that the CharacterController component is for prototyping? I really want to see this.

In my 10 years of using Unity I've heard this said by regular old forum users, but never seen it from Unity. Never in a blog, never in the forums, even googling for it right now I'm not finding this. I'm finding people say the "standard assets" package that has code written for an FPS/3rd person script is for prototyping... but that's not what I'm talking about.

And if you are referring to the CharacterController component... this one:
https://docs.unity3d.com/ScriptReference/CharacterController.html

Well, I don't care if y'all don't like it. I do. I would just like it to also have this one feature, a feature that exists within the engine already... a feature that all Unity would have to do is write the method wrapper that connects the C# side to the C++/PhysX side.

If you don't think Unity will do it. That's fine. And I'm not holding my breath either.

But it doesn't hurt to ask. That's sort of what the 'requests' and 'feedback' are for.

It's not like I'm requesting for something ridiculous. Or something that requires a ton of development. It's a feature that is already in the system. It'd be like if BoxCollider didn't have a component. Unity didn't write BoxCollider, it's part of PhysX... and if they didn't add BoxCollider and someone was like "Hey, where's BoxCollider? I know it's part of the physics engine you use!" Not unreasonable.

...

Now of course googling to find a source for this "it's only for prototyping" has led me to this thread:
https://forum.unity.com/threads/character-controller-up-vector-should-be-configurable.543276/

A thread where @aubergine is basically requesting the exact same thing I am.

hippocoder then references that Unity ain't going to do it (not sure where he gets that info, but whatever), and that they're working on a replacement called 'Open Character Controller' being written by a willgoldstone...

Which ironically is the same person authoring the post OldLegWig links to as proof that it's for prototyping. But alas that thread he links is saying OCC is for prototyping... oh jesus christ it's a circle of misinformation from all sides!

...

And in the end. All I know is this:

CharacterController documentation says nothing about it being for prototyping only.

The PhysX logic that CharacterController wraps contains an arbitrary up vector as per the documentation from PhysX.

OCC isn't directly part of the Unity API and does have the author admitting it's for prototyping

I could write my own... which is fine, I've written a LOT of my own stuff. I wrote my own UnityEvent before UnityEvent existed. I wrote my own object identity for Coroutine, as well as custom yield instructions long before Unity did (you used to have to call stop by string). I've written a lot of my own custom stuff, and I will more in the future. But funny enough every time I write my own, Unity then releases their version of it. (which maybe I should play my cards, write mine, and see what Unity does out of serendipity)

The Asset Store also has some that may or may not meet my needs and I won't know without buying them. Because as was stated no controller fits all cases.

But I do know that the existing CharacterController fits my needs minus the up vector... which could potentially be had by just granting access to that part of PhysX, which is already part of Unity.

I shouldn't hold my breath for a response from Unity... which I'm not. Making a request isn't tantamount to making a demand and not looking elsewhere. I am looking elsewhere, but a request does not hurt.

...

If all of that still makes it unreasonable to create a request? Well.... I don't know what to say to y'all. You have different world views than me.

Because hell... if I could just get some CLARITY on what Unity is doing considering the loads of dead ends, half developed alternatives, and 3rd party alternatives, as well as supposedly the built in features of Unity aren't supposed to be used? OK... then why the heck doesn't Unity say that in clear and easy to find location?

Cause it's not like I don't know Unity. I've dug through their code for a decade now. I've read their documentation forwards and backwards. Anyone who knows me on this forum knows I am a wealth of Unity knowledge. And this "only for prototype" thing is something I've only heard in the shadows... never from Unity.

And if that's your only reason I shouldn't request it... well sorry, I don't listen to shadows/whispers.

...

And lastly... even if it is for prototyping. What's wrong with having variable up axis when prototyping?

 

Yes, we were. Sorry about that I haven't read back the old posts in this thread, only the new ones, so I was thinking out of context and relied on @OldLegWig 's answer for context, which was a mistake.
I agree with you completely, now, I have read the thread as I should have at the first place.

CC isn't for prototyping only, it's a wrapper. If it lacks of functionality from the PhysX lib, probably it worth the try to ask for it. Definitely.
(The standard assets and the new standard characters are for prototyping)

 

Seconding this request verbally, in case a 'like' isn't sufficient to indicate support.

 

@lordofduct Let's keep in mind that simply allowing access to physX gravity functionality will result in the behavior you are expecting is a huge assumption. You might actually be able to find someone who has decompiled that script somewhere and find out for yourself. If it is the case that every calculation for the controller was written to be oriented to the gravity direction in physX and not world up or some combination, and simply exposing it would work, then yes hopefully they will do that.

Also, it seems to me that the new standard assets controller is intended to eventually replace the CharacterController class. The controller in that package has its own movement/collision implementation that does not inherit from CharacterController. It would make sense not to get married to supporting a built in "production ready" character controller for the reason @Lurking-Ninja mentioned which is why it would be logical to stop supporting CharacterController and instead make a more narrowly focused and high quality example project that includes source code.

 

My assumption is based on the PhysX documentation. The CharacterController component is a wrapper for the PhysX "Kinematic Character Controller" otherwise known in shorthand as the CCT:
https://docs.nvidia.com/gameworks/c.../physx/guide/Manual/CharacterControllers.html

Mind you, this is why in Unity documentation you find references to the CCT like this:

https://docs.unity3d.com/ScriptReference/CharacterController-enableOverlapRecovery.html

OH HEY, What's that? A reference to the "up vector" of the CCT? Huh, even Unity admits it exists.

Mind you this isn't the gravity vector... this is the CCT's up vector. A CCT's up vector is unique to it. You can have one vector that points up <0,1,0> for one CCT and another that points <0,0,1> for another CCT.

Oh and so I can demonstrate I know they're using the term CCT there identically with the nvidia PhysX CCT:

https://docs.nvidia.com/gameworks/c...acterControllers.html#overlap-recovery-module

It's almost like they just copied the definition of 'overlap recovery module' from the PhysX documentation I've been using as a source this entire time.

Yet the new 'standard asset' you're talking about is the very thing that your evidence demonstrates to be intended for "prototyping" and not for production.

And it's replacing the current controllers found in "Standard Assets":
https://assetstore.unity.com/packages/essentials/asset-packs/standard-assets-32351

I'm not talking about "Standard Assets".

I'm talking about 'CharacterController':
https://docs.unity3d.com/ScriptReference/CharacterController.html

The component that wraps around the PhysX CCT.

And uncovering the PxControllerDesc::upDirection vector:
https://docs.nvidia.com/gameworks/c...de/Manual/CharacterControllers.html#up-vector

Just like we have a property on CharacterController for it's "center" vector. I'm just asking for a property that gets/sets the "upDirection" vector. That's it. PhysX already takes care of everything else.

And like I said... lets pretend your hearsay argument that the CharacterController I speak of is only for prototyping (srsly, I've supplied so many links to sources, where are yours?). So what? It's a single property forwarding implementation from the C# scripting side into the PhysX engine side. What would it hurt to add this if it only impacts a component that is intended for "prototyping"?

I mean... what is your argument even?

That I shouldn't make a request? Why?

Or is it that I should seek elsewhere since it likely won't happen? Sure, that's a likelihood. And is why I AM looking elsewhere AS WELL as making a request.

Like I said, I've been using Unity for 10 years and there's a lot of stupid in the API. A lot of stupid that hasn't gone anywhere. But they have also made changes for the better as well. They deprecated the property getters for components! They added object tokens for Coroutines! They created UnityEvent! The engine is maturing, the company is maturing, and I'm very pleased for that. I'm just adding a simple request for a simple feature that is a standard part of the very CCT they wrap.

And I understand why it wasn't put in originally. Because in the original Unity, the version of PhysX they used didn't have it. But as of Unity 2018.3 they've been using PhysX 3.4.2, and is why I reference the PhysX 3.4 documentation.

 

Sorry, I'm just trying to be as helpful as I can. I explicitly said if it is as simple as exposing something from physX, then yeah, do it. I've never heard that CharacterController is a wrapper for nvidia's controller. I didn't know that.

The thing is though, I have a pretty sophisticated controller that works with arbitrary gravity including flawlessly on surfaces that rotate and move around simultaneously. It's also tailored specifically for my project. Chances are something like that is terribly painful to make with CharacterController even with that added gravity functionality. I also made it with Kinematic Character Controller which is already available.

I was also just speculating on what the Unity folks are probably prioritizing - likely the new character controller which will conceivably not use physX at all at some point and rather opt for Unity Physics/Havok.

 

So you can understand my frustration at the fact you just admitted everything you've said is based on speculation as well completely side stepping my clarification on what CharacterController is, its relation to PhysX, and the links I supplied to that effect (which I linked in the very first post).

I thank you for your effort... but I hope you can understand how that can be very unhelpful in practice.

And sure DOTS and Havok may be in the future pipe. We're not there yet though. And we currently have PhysX. (and I doubt Havok doesn't have variable up)

 

I'm not sure what you think I'm sidestepping. My point is that the only thing that seems to be keeping you from making what you want is your emotional attachment to a very old component. You could download the new controller from github and start modifying it to fit your needs right now. Whether someone labels it "for prototyping" or not is meaningless if it works. CharacterController obviously doesn't and hasn't for many years. Unity is actively working on replacements for both the controller and the physics. That seems very relevant. IMO it would be helpful in practice to ditch CharacterController especially given the results of the alternative method of waiting for 10 years.

 

Reviving this old thread in support of exposing this if it's as easy as @lordofduct thinks it is. I think that would make the component much more compelling for a whole series of different genres of games that currently just can't use the built-in character controller.

 

4 years later.
CharacterController is still a part of Unity.
PhysX is still used by Unity for 3d.
Still no substantive evidence that ChracterController is for "prototyping only".
Still no replacement directly from Unity that isn't some asset store thing created by a 3rd party.

 

Yeah, API needs updating.
PhysX have way more functionality on CCT, and Character Controller is just a wrapper.
No idea why Unity does not update it properly or like ever.


You can also add CharacterController.OnControllerColliderHit message to the list of poor implementation.
Since ControllerColliderHit is a class for some reason, not a struct, it generates garbage.

And CCT "feels" better than plain rigidbody, and its great for magnitude of game genres. So there's no point in just using 3rd party solution when there's an already a solution inside engine which is just unaccessable. Or has issues due to poorly exposed API.

(That is unless UT deliberately optimized this functionality away during porting)

Question, @lordofduct have you tried submitting bug reports?
Maybe there's a way to reach PhysX port team to make them actually fix these issues?

Edit: Out of curiosity, sent them a bug report, lets see what UT resolution will be (Case 1323238):

Code (CSharp):

1. Character Controller is a Unity wrapper for CCT from PhysX. Nvidia's C++ API for CCT is way larger than currently exposed for C# component in Unity.
2.  
3. Here's manual:
4. https://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/CharacterControllers.html
5.  
6. List of currently missing, and highly requested by community:
7. - PxControllerDesc::upDirection -- very important for multitude of game genres
8. - PxController::setPosition -- needed to perform teleporting or "warps" without hacks
9. - void PxController::resize(PxF32 height) -- for crouching
10. - const PxExtendedVec3& PxController::getFootPosition() const; -- utility
11. - bool                  PxController::setFootPosition(const PxExtendedVec3& position); -- utility
12. - PxControllerDesc::nonWalkableMode -- automatic forces when sloping
13.  
14. Settings / manager related:
15. - void PxControllerManager::setTessellation -- world building accuracy
16. - PxControllerManager::setPreciseSweeps -- improved performance when accuracy is not important
17.  
18. PxUserControllerHitReport::onControllerHit -> Fix GC allocation done by ControllerColliderHit (its a class, not a struct as it should be)

 

So here's the answer:

 

Yeah, that's why back in 2019 I reflagged this thread as 'feedback', because the old feature request process was removed.

And I don't hold my breathe about the forum getting any notice.

I've worked in all sorts of industries in software, from porn sites, to accounting software (though I haven't worked in large gaming companies... only my personal stuff). And when they go to an informal process, it's just so they can easily ignore it without having to finance/maintain a formal process which they were going to ignore anyways. Because at the end of the day the community is not who drives a feature.

At best the community needs to be squeeky to get the grease. And this topic clearly does not matter to the majority of people.

 

Just in case, I've poked support a bit more, and got this:

So yeah, guess it will be left like this forever.

 

Thanks for the efforts man!

Too bad it didn't pan out.