Stairs implimentation in HIFI


#1

After spending some time making a spiral staircase I noticed a problem. I cant walk up or down it…

In Staircase design there is a formula used to calculate a comfortable run and rise so the climb feels well normal.

I think that whatever walking animations were using need to be-able to climb any staircase in that range.
Its not life or death but I would like to think if I’m constructing a house correctly to scale that a Hifi avatar will be able to use the stairs, or its going to become really annoying down the line…


#2

The problem isn’t so much the animation but how the avatar collides and the code that helps move the it around. Not only can the avatar not walk up steep slopes, but it also gets stopped by very small step heights.

At the moment the avatar collides like a simple capsule – it collision shape is approximated as a simple bounding shape. You can see what the capsule looks like by adjusting a setting in the menu: Developer–>Avatar–>Show_Bounding_Collision_Shapes.

We use a “character controller” class to help manipulate some of the details of how it gets up to speed and collides with the ground. The MyCharacterController class is actually an “action” in Bullet parlance and most of the code that helps the avatar walk on the ground is inside MyCharacterController’s playerStep(). In the short term (until we have a more detailed collision shape for the avatar) we need to modify the logic inside that method to allow the avatar to walk up steeper slopes and step up larger steps.


#3

Welcome to the club @judas. CHeck my domain. not tried a round stair. But did have enough problems myself in the past with stairs

https://alphas.highfidelity.io/t/stairs-compound-shape-ramps-and-problems/7193


#4

That sounds like there is a better collision shape for the avatar is planned. At the point that happens think these words " that annoying bastard in the alpha community wants to be able to walk up steps"
:slight_smile:


#5

Not my fault, the did not provide us with ladders or ropes.


#6

In a simplified movement dynamics design for avatars, it’s less about the collision shape, the capsule is a common shape used to represent an avatars, and a lot about the nuance of the character controller. I did a bit of work on that for another grid to make it possible for avatars to walk up stepped surfaces smoothly as well as setting the limits of climbing up slopes. And it is here that one has to play looser rules than reality. With either Bullet or PhysX, a collision with a step as small as 0.2m will stop a capsule the size of an avatar. That step size is taller than the hemispherical bottom of the capsule, so the collision is with the vertical part of the capsule. Since avatars are programmed with a very strong vertical attractor (and usually avatars are moved via kinematics instead of physics dynamics), hitting the wall doesn’t make the avatar tilt with would then create an upward force. Besides, the look of a tilted avatar is seriously unrealistic looking, which is why that kind of tilt is not permitted. A character controller has to mitigate that by detecting the collision and performing kinematic adjustments. In the work I did in another grid, I had the controller set to permit stepping up 0.75m high walls (steps). This is also the step height in SL (0.7499m). The other controller behavior is how to deal with an avatar moving up a slope. In real life the practical limits is around 38 degrees before walking becomes an involved and slow climbing action. In virtual worlds the limit slope is much higher, around 65 degrees. This is quite unrealistic but expected.


#7

Could the new avatar recording subsystem be used to quickly document ascending/descending the staircase (with physics off) into subjective waypoints?

I think a path traced like that from within an HMD or the first person perspective would contain valuable information about the practical aspects of using the staircase. And if several passes were recorded, I bet the trend could be expressed automatically into a progression of “Zone hulls” – enabling the staircase to function from the first person perspective like a Segway-escalator.


#8

I suppose if you really wanted to simplify things, just make the physics shape (the convex hulls) for the stairs into an approximate ramp. Then, the avatar will not get stuck on the risers.


#9

That could also help from an overall accessibility standpoint I think. And if ramp-specific configuration proved necessary, maybe strategic userData could be attached to the entity to provide secondary hints to the “system collider?”

For the waypoint recording… was thinking it’d help to burn the candle from the opposite end – starting from a blessed outcome and working backwards into ways of synthesizing a similar user experience. It also means the computer could always have at least one reliable fallback strategy for helping the user complete their goal of traversing the steps.


#10

Yes, I am guessing from what you wrote that you are looking for a higher fidelity of movement on varying surfaces. It would be wonderful to see the gait of the avatar change as it transitions from walking on a surface, to walking on a slope, to walking up or down a set of stairs.

It does raise questions as to who is the agency to do that. Is it something built into the core system? Is it something in the stairs entity that communicates to the gait script on the avatar that it is now on a surface with a suggested gait of ‘walk-steps’? Presently walking/running/flying (though presently somewhat broken by recent changes) is performed by the walk.js script, so that suggests the stairs entity script would have to monitor an avatar collision and communicate to the walk script that the gait needs to change, or, perhaps, give it a URL or blob of the procedural animation to use.

That too raises more questions because walking, climbing gaits are not universal especially when you consider the avatar might not necessarily be a bipedal one. So, state hinting is probably the better approach.


#11

I only really care about bipeds :stuck_out_tongue: I just want simplicity for the end user and the builder. I can envision someone creating a complex stair zone but my gut thinks if i reach a vertical surface double tapping forward will make me move upward and then forward so I just climb the stairs. I don’t wanna fly so it should perhaps be limited to a limited stair rise…
You may work list Millipede however :smiley:


#12

I use ramps, but it’s still can be a disaster. try to avoid angles that go above 39 degree. My last testings made it visible that above that angle your avatar is not getting up.


#13

Indeed, that is exactly what I meant by: “The other controller behavior is how to deal with an avatar moving up a slope. In real life the practical limits is around 38 degrees before walking becomes an involved and slow climbing action. In virtual worlds the limit slope is much higher, around 65 degrees. This is quite unrealistic but expected.”.

The slope walk limit here is more like RL, which is not at all like the legacy grid limits. This is the sort of stuff that could use setters to communicate movement limits parameters with the character controller.