Avatar cant step up 10mm


The avatar is too sensitive to bumps in the floor surface, as little as 10mm step is enough to stop him dead in his tracks and force you to jump.
I really think an avatar should be able to step up 200mm without any issue, but I understand the difficulties in climbing stairs.
Even still, walking should be a little bit more forgivable, the edit tools arent accurate enough to manually line up a ramp to a level surface, to a point where the avatar doesnt just bump into the tiny imperfection in the vertical alignment.


I reported this long ago, no one seems interested in fixing it. You can hack the walk script by doing a myriad ray casts looking for foot obstructions, then do a small up-force. Total hack, computationally expensive having a script do that instead of making the character controller do it properly in native code. Why raycasts? Because there is no “myAvatar::Collided” method.

There is an entity ‘collision’ event but that means placing scripts in all entities an avatar might collide with to do a step-up. Very clumsy approach. I think the best way to fix this is to fix the native character controller to let avatars step up stairs. Special bonus if the upgraded character controller creates a “stepupdown” event so that scripts like walk.js can adjust the avatar’s animations.

– Running light without overbyte


This is so old problem me and others complained about many times.
It’s annoying that hour avatar cannot get up the sidewalk from the street.

And if you use the HTC vive it’s worse because jumping is so extreme difficult to activate !

Then the stirs, since we have static mesh compound, people go use that. so you not have the ramp anymore build in you compound you would do with manual created compind shape.

This still need urgent fix or tweak.


Still a big need, I agree - and just to remember: (maybe we should create more content/stairs) :


There was an attempt to solve this problem in the “out-of-body-expeience” project PR-8691 which is a larger project relating to how to reconcile the avatar’s visible and physical position relative to the HMD’s view and position in the virtual world while walking around the real room (e.g. when walking around using a Vive).


However there are some blockers on that project, one of which is that the code that was trying to figure out how to get the avatar up a ledge can be quite expensive against a small object with a large number of triangles that uses the static-mesh shape --> very bad frame rate because the physics calculations require too many CPU cycles.

If you were to test that PR you’d see that the avatar can walk up simple ledges without too much difficulty, but it still needs some work. I’m working on it now. Hopefully we’ll have something deliverable soon.


If that is the case then perhaps HF chose the wrong physics engine? This kind of activity is something PhysX shrugs off easily. In any case I’m not convinced this is a bullet physics problem either since we have plenty of examples in OpenSim simulators of avatars with capsule physical shapes, just like in HF, either walking up steps or up irregular high-poly high-collision surfaces without suffering frame rate drops caused by high physics computations. Likewise we have myriad dynamic physics vehicles examples doing the same without issue. Granted the physics in legacy grids is done in the server-side simulator, but I have instrumented the load and it barely registers.

This should not be a problem. So, I think something else is going on in the HF design, something that bears an architectural review.


The problem is not a moving a dynamic btCapsule against a 29k-triangle btBvhTriangleMeshShape – that works fine. The problem is when trying to do a kinematic sweep test of a capsule against a 29k-triangle mesh. There may be a bug in Bullet that is fixable – dunno yet. In the short-term I’ll try to work around the problem without sweep tests. If I manage to make the avatar able to walk up steps in desktop mode in that project then I’ll announce it here so that interested parties can test it out.


Interesting that you mention opensim’s pill-shaped avatar physics encapsulation. I’m told that SL instead uses an inverted-cone-shape avatar physics encapsulation… which is a lot more suited to things like short barriers, very uneven terrain, and going up stairs and steep ramps. One of the major gripes I always had with opensim was that your av would readily get tangled up by things like sidewalk curbs and not be able to get past them unless you hit PgUp to jump over the very shallow curb, but the identical build on SL would bring no trouble at all and the av would just go right on over it. There has been SOME improvement of late, which I think might have had to do with a combination of changing back to a remodelled version of ODE in the newest opensim (well, its the default physics now on opensim 0.9) but also that they changed the physics shape of the av a bit to work better with stuff like curbs. Maybe they changed it to be less pill-like, maybe tey did something else, I’m not sure. On the other hand, it was pretty clear that inverted-cone-shaped was better than pill-shaped.


InWorldz used a capsule physics shape for avatars but it uses PhysX, and it works fine. PhysX itself generates an up force because the curved surface of the capsule, upon hitting the obstacle generates the vectored force naturally, that is, it is part of how PhysX works to generate high accuracy forces. The limit of the induced up force is 1/2 the radius of the lower sphere part of the capsule. An avatar striking an obstacle taller than 1/2 the radius of the capsule’s sphere will not climb it. The capsule’s sphere bottom is also nice because at low strike angles, the impediment force is nearly nil, so it naturally feels right - easy crossing low obstacles, harder going over taller ones until a full stop happens at 1/2R. At 1/4R, the up force is the same as the externally applied side force (whichever direction the avatar is being compelled to move). So, if the physics is decent, an avatar with a capsule physics shape should be able to easily go over obstacles that are 1/4R tall, and be completely stalled by obstacles 1/2R height or taller.

Perhaps bullet is not generating the proper induced forces. I will investigate, and I encourage others to investigate too. If bullet is not naturally generating a vectored force then that is likely a lot of the issue here. It may be a simple bug to fix. Maybe the capsule’s radius is too small. If the goal is to naturally permit an avatar to climb over an obstacle 0.7m tall, then the capsule radius needs to be 0.7m (diameter 1.4m). If that is too wide, then some additional compensation needs to be done in the charcter controller.


Here is a quick experiment. I made three obstacles, 0.5m, 0.1m, and 0.05m tall. I cannot get my avatar to climb over the first two, and it climbs over the lowest one fine (0.05m or 1.9 inches). The 0.1m (or 3.9 inch) one is clearly far too low a height for a complete forward stall, so I displayed the bounding box for the avatar. Assuming the interface app is rendering it correctly (it’s not in the horizontal direction), I can see why this is happening. The radius of the avatar capsule is around 0.15m! It needs to be much larger for natural obstacle climbing.

So the choise is to either increase the capsule radius or add character controller logic to deal with the collision stalls.


Here is another example of the inability to climb up 0.13m stairs ( 5 inch risers). This is the standard mansion model HF provides.


No, we’re not going to use big fat capsules for the avatars just to make it possible for them to climb big steps. You’ll just have to wait for magic sky hooks. The good news is that I’m working on sky-hook technology right now.


Big steps are not 5 inch risers. But, good to read attention is finally devoted to this problem. The working character controller code (physics step code) is in github Halcyon…/PhysxPhysics/PhysxCharacter.cs

It too permits smaller capsules by monitoring collisions and applying appropriate forces to rise above the obstacle.

Halcyon is the OpenSource code base of InWorldz, used by the MOSES military simulation project. It’s a good place to go look for working examples.


I’m quite happy about that, no offense to @Balpien.Hammerer but I was worried having larger avatar capsules would interfere with couples dance animations, or fighting poses. Ideally, I would not want to disable collisions for each avatar everytime I apply a custom animation.

-my two cents-


When i did read larger avatar capsules, my response is No,No;Nooo.
It would create problems with entering buildins, and get out.


No offense taken, @AlphaVersionD. Note I pointed out larger capsules after I had urged over and over for character controller fixes after my original suggestion was rejected months ago. I even offered my version of a character controller that handles steps quite nicely - open source and retargetable to Bullet too). I’ve no idea why all this was rejected.

Making a character controller that handles things like obstructions is decades old standard practice - it is not new art. Since that was rejected (you can see for yourself in previous posts), the only other viable approach would have been a capsule adjustment.

There are a couple of takeaways here. There is a problem too with the existing capsule/collision dynamics. Either the capsule render is inaccurate or the physics collision boundary extends quite a bit beyond the capsule’s surface. Given how objects cannot get closer to the avatar than 0.2m, this too needs investigation.

Second is that Bullet physics seems to be OK insofar as the induced vectored forces. I ran several tests with obstacles to observe it doing the right thing although it is not nearly as smooth as PhysX. The twitches and jitters still need investigation.

I’m glad this discussion finally stirred up desire to finally do something about this months long critical issue. BTW, the simple capsule to represent an avatar needs to be ditched eventually for higher fidelity avatar physics. Once avatars start ducking and twisting and striking at things, under control of body wear, the basic physics shape will have to bend along with their limbs.


I’ve got a PR up that has the avatar able to walk up steps. You can try it out here:

Most of the work in the out-of-body-experience branch is about allowing a Vive user to walk around in room-space without worrying about unexpected shifts in perspective when their avatar collides with virtual geometry, however in order to make that work correctly we needed the avatar to be better at keeping up with the HMD position --> it needed to be better at walking over small steps and obstacles. So, the ability was added and it even works in desktop mode.


Hi @leviathan, sounds great :slight_smile: thank you. Just, I get an error message, instead of a download page:


Mac link works, Windows link gives 404


Oops I accidentally introduced a build error on Windows. Now fixed and the installer was successfully built.