Sure! I'll describe the problem I'm facing (what I don't like in ellipsoid hull), then I'll try to describe solution I came up with and then the problem I've faced with my solution (it's not related to this topic, but to the main disadvantage it has).
WHAT I DON'T LIKE:
PROBLEM #1: You can see that cause of ellipsoid hull, player's gravity trace, will be able to 'grab' the edge of the block. That happens cause our bounding box isn't box shaped (or at least capsule), and gravity trace is stretched downwards... As soon as it will grab that edge, player will be able to walk up on it. Plus, cause of GLIDE and ellipsoid hull, player will be able to get on top of that edge any way, cause GLIDE will push him upwards.
PROBLEM #2: Not a big problem, but it's also related to GLIDE, in this situation, player will be pushed downwards a little bit (at least till the bbox will hit the ground, if you have an offset from surface below). This will result in getting stuck if you will get 'pushed to floor' and will try to move sideways.
PROBLEM #3: It's just another picture to show how ellipsoid will collide with the edge, and what I would like to avoid.
SOLUTIONS:
#1: We could push player away from the normals of the surface we are moving towards to, that's what I do now. I get player's velocity for a direction, then I use (f.e.) my->max_x and then trace (picture doesn't use my->max_x, and trace is stretched with the velocity, but that's just to show you the idea of what I've done). As soon as the trace hits anything, we disable our input towards the hit->x position ( if(hit->x < my->x){ input.x = maxv(input.x, 0); } else { input.x = minv(input.x, 0); } ) and we push player away from the normals ( input.x += normal.x * (1 - vec_dot(&normal, &input)); ).
#2: First of all, we separate XY and Z movement. Entity responsible for Z is half sized and placed below the origin of the XY entity. This will make trace more 'smushed'. In addition to this, we set my->max_z and my->min_z to smaller values, like 0.1 and -0.1 right before performing gravity trace, after the gravity we restore them back again (this also helps to get more or less box like trace hull). For gravity trace, we don't use our Z entities origin position, but we add a little offset, this will also help us to avoid PROBLEM #1. Our XY movement has full bounding box size and it's responsible for all XY collisions, but there is a gap, as you may see on the picture, between our XY ellipsoid hull and gravity trace. To fix that, we need to use solutions #1 and #2 together.
#3: We just add first solution to the second one, to fill the gaps and to prevent player from hopping on top of the blocks/edges as shown on PROBLEM 1. For this trace (towards the moving direction) we'll use Z entity's origin position, as shown on the picture.
'SOLUTIONS' PROBLEM
However this 'solution' has main disadvantage (at least the way I setup things), there is a gap between X and Y traces, you can see at the picture. And if player will walk towards the edge of the wall, traces won't help much, player will be able to touch the wall (and that's the main thing I would like to archive in order to prevent all problems).
It's probably a pretty dirty and not elegant way of handling things, but it's what I came up with anyway. For now, I use the same method, but with only one entity, which is responsible for XY. It preforms gravity trace (with Z offset for start position) and it also handles those traces towards the moving velocity. As for the demo, I can't share it right now, cause it's pretty complicated, and I'll have to spent time on ripping main parts out of it. Soon I'll post a demo of the movement itself, but it probably won't be 'open source', but compiled one.
Best regards.
