Amazing unity character controller phenomena.

[pointcache]

So character controller detects slopes.
But the slope value is not available to us.
What could possibly stop unity people from exposing this slope value to the user?

[methos5k]

Pardon? Which value? Not the slope limit that’s there in the inspector?

[pointcache]

@methos5k

Pardon? Which value? Not the slope limit that’s there in the inspector?

pardon
lol
no. Actual slope value.

[Laperen]

You still have not clarified what you mean by slope value. Are you referring to the collision normal of the slope?

[methos5k]

Ah, I see. I guess have to calculate it (if you want the collision normal of the slope, as Laperen asked/commented).

• I forgot to hit post several mins ago when I wrote this. heh

[pointcache]

im refering to CC’s internal calculated slope value.

[pointcache]

Calculating slope starts very simple with surface normals and or raycasts, and it grows very complicated the more collisions per frame are introduced, the more different scenarios (steps, slopes, wall, how do you differentiate, overhanging steps, negative angle walls), so it would be logical that if unity itself properly calculates the slope, they would expose it to users to save the whole lot of trouble of going through the same process all over again.

And yet, its not available, why?

[methos5k]

Well, not sure what to tell you. I don’t disagree with your logic, per se, but if it’s not there… There’s not much I can do about it Just gotta adapt.

[pointcache]

Last time i started controversial thread it led to a shitshow that forced unity guys to respond, maybe something like this will work this time.

[methos5k]

You can add it as a feature request. They have a page for that ( I believe you get x number of votes, etc…)
Sounds more… civilized that looking to cause some enraged forum postings? Anyways. Take it easy.

[pointcache]

Yeah so it can drown alongside the hundreds of other requests that are shoved under the rug, civilized, efficient.

[Laperen]

@pointcache

Yeah so it can drown alongside the hundreds of other requests that are shoved under the rug, civilized, efficient.

Wow can’t imagine why your previous thread regressed into what you call a S***show.

@pointcache

Calculating slope starts very simple with surface normals and or raycasts, and it grows very complicated the more collisions per frame are introduced, the more different scenarios (steps, slopes, wall, how do you differentiate, overhanging steps, negative angle walls), so it would be logical that if unity itself properly calculates the slope, they would expose it to users to save the whole lot of trouble of going through the same process all over again.

And yet, its not available, why?

A raycast in this case IS to get the surface normal and not mutually exclusive to itself. The collision functions should also be able to provide the collision normal although it may not be as reliable for the CharacterController. For me I make use of surface normal to differentiate between walkable and unwalkable terrain which encompasses walls, so-called negative angle walls, and slopes. I’m fairly certain stepheight has nothing to do with slopes, it is simply the height at which the character controller is allowed to step over(IE teleport over). To me all the functionality you really need is to get the surface normal, which raycast can achieve as a last resort.

With all that said I’d prefer if you state what you are trying to make instead, in a separate thread. Outright demanding a feature without justification does not make a solid case. You also cannot guarantee your demands will be met in-time, if not at all.

[pointcache]

Justification is simple - the code already exists, feature already exists, everything already exists (but you can keep doing double work as nobody forces you to use that slope angle if at any point unity decides to expose it), but it’s not available to us - why?

[Laperen]

And to provide further justification to your own point, please give your problem as an example of why the feature is needed. Assuming something can be done does not make it so, and certainly is not justification by any stretch.

[Laperen]

@pointcache I just went to take a look at your website and your stuff looks amazing. Is this just a rant? Sounds like something you would have no trouble finding a workaround for at your skill level.

[lordofduct]

the unity CharacterController class is really just a wrapper around the PhysX PxController class, since unity uses PhysX for its physics:
http://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/CharacterControllers.html

The api for the class can be found here:
http://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/apireference/files/classPxController.html

Going through that, you will notice that it too does not supply the surface normal or surface slope of the surface when it struck. It’s just the way it works.

Note this part of the documentation:

By default the characters can move everywhere. This may not always be a good thing. In particular, it is often desired to prevent walking on polygons whose slope is steep. The SDK can do this automatically thanks to a user-defined slope limit. All polygons whose slope is higher than the limit slope will be marked as non walk-able, and the SDK will not let characters go there.

Two modes are available to define what happens when touching a non walk-able part. The desired mode is selected with the PxControllerDesc::nonWalkableMode enum:

• PxControllerNonWalkableMode::ePREVENT_CLIMBING prevents the character from moving up a slope, but does not move the character otherwise. The character will still be able to walk laterally on these polygons, and to move down their slope.
• PxControllerNonWalkableMode::ePREVENT_CLIMBING_AND_FORCE_SLIDING not only prevents the character from moving up non walk-able slopes but also forces it to slide down those slopes.

The slope limit is defined in PxControllerDesc::slopeLimit and later available through the PxController::getSlopeLimit() function. The limit is expressed as the cosine of desired limit angle. For example this uses a slope limit of 45 degrees:

slopeLimit = cosf(PxMath::degToRad(45.0f));

Using slopeLimit = 0.0f automatically disables the feature (i.e. characters can go everywhere).

So, though we set it as a angle in the inspector. Unity underneath has to calculate the cosine of it and pass that into PhysX.

This means PhysX is using the cosine of the slope to actual limit things.

This leads me to suspect that the slope they compare against falls out of their physics calculations as a cosine. Basically meaning that they don’t actually calc the slope, but rather use an existing value that COULD be used to calculate the slope, but isn’t necessary for limiting.

It’d technically be more work to get said slope information… and the api probably just presumes you could calculate this on your own if you truly really need it. Heck the following paragraph to what I previously quoted suggests slope limit isn’t even considered something you’d always need anyways and that if set to 0 is considered ‘off’.

This feature is not always needed. A common strategy is to disable it and place invisible walls in the level, to restrict player’s movements. The character module can also create those walls for you, if PxControllerDesc::invisibleWallHeight is non-zero. In this case the library creates those extra triangles on the fly, and that parameter controls their height (extruded in the user-defined up direction). A common problem is that those invisible walls are only created when non-walkable triangles are found. It is possible for a jumping character to go over them, if its bounding volume is too small and does not collide with the non-walkable triangles below him. The PxControllerDesc::maxJumpHeight parameter addresses this issue, by extending the size of the bounding volume downward. That way all potentially non-walkable triangles are properly returned by the collision queries, and invisible walls are properly created - preventing the character from jumping on them.

In the end… CharacterController is designed to be a simple basic, non-physics (no force), movement controller in the PhysX simulation. It’s not designed to be doing complicated physics, so therefore does the littlest amount of effort necessary to simulate itself.

[methos5k]

Very nice answer

[lordofduct]

A little follow up…

Why is it that I think it just falls out of their algorithm and they actually don’t have the slope… it’s all to do with the fact they use cosine of the slope for testing.

See… if they had the surface normal, the slope of that surface is the arcsin of the y portion of said normal. So you’d just compare the sin(slopeLimit) to the y of the surface normal.

But they ask for cosine… this means they aren’t using the surface normal, since getting the cosine of the slope from a surface normal is more work then just using the sine which already falls out of it easy. Why do more work when you don’t have to?

I don’t know what they use though… though I have suspicions.

For example… CharacterController MUST be a capsule collider, and it MUST stand on some axis, usually y-up. You can’t rotate it 45 degrees.

Due to this, when walking on a surface, you’re guranteed any surface you strike from the side is either going to:

A) strike the wall of the collider (the cylinder part), which since it’s above the base of the collider, must be a wall.

B) strikes the semi-sphere at the foot of the collider, this implies it’s a sloped surface (or a step, where stepOffset will come into play).

If it strikes the semi-sphere portion, we most likely have the point of contact (usually the first piece of data generated in a physics collisions simulation, just after determining if overlap). We still don’t have the slope… BUT if you just take the vector from the center of the foot semi-sphere to the point of contact… this vector’s y value will be a decent estimation of the cosine of the slope of the surface it just struck.

This is a potential place where the slope could have fallen out of their algorithm.

I suspect this MIGHT be it, primarily because this same piece of information can be used for the stepOffset. So it deals with both scenarios.

[methos5k]

Little (slightly off topic) bit to add to the feedback here: With regard to the character controller having to be a capsule, that’s not true. Because of one of the links you posted, I read a little bit for fun about the controller and you can actually have a box or capsule (in physx , maybe not Unity ;)). Beyond that, who knows. It’s a general purpose controller they say… use, don’t use, enjoy… lol

[pointcache]

@lordofduct truly remarkable answers. Thank you.