randygaul / player2d Goto Github PK

due to the way NGS works when on a slope and continuously jumping for example after a bit of time you can realize there is some movement in the X axis because you are everytime pushing the player by a small amount in the normal of the collision and that would add up causing movement in some extreme cases

hey,
First of all, I just wanted to say thanks so much for this project -- 2d character controllers (especially collision response) is something I've always been obsessed with, and it's nice to see other people are obsessed with it too. <3

I've got a few questions, and I suspect some of them might be answerable if I could build the code, but I don't actually use C/C++ (and, every time I try to compile something, it never works), so please bear with me if I'm asking totally stupid questions!

a) I may have found a bug on lines 309-311 of main.cpp:
if (iters == 1 && t == 0) {
player.pos = player.vel * dt;
}

There are two potential issues (I may be imagining both!):

1. I'm pretty sure you want to use += since otherwise this is going to warp the player to near the origin
2. you're using player.vel (which is the raw/uncorrected velocity) and not the temporary "vel" vector which has been nicely clamped to lie on the tangent plane... is that correct? (it might be, since if t=0 then presumably the TOI solver failed and it didn't return a useful normal. Unless GJK does actually handle this better than the root-solving methods I've been using.)

I also wanted to ask: what's the purpose of this code? I'm assuming that this is "handle the case where we start in penetration so the TOI solver can't give us a result", ie to avoid being stuck infinitely if you start the frame in penetration, but I don't really see how this code should fix that. (In the past I've tried projecting onto the previous frame's surface normal and then stepping along the tangent.)

b) Another maybe-bug (or at least, something I don't understand): in lines 95-105 of crate.h, you're depenetrating a crate out of the player by using 10 iterations of under-relaxed projection (fixing 20% of the error each iteration): couldn't you just use 1 iteration which solves 100% of the error in this case? Since nothing else is moving the crate, and the crate is always moving along the contact normal (which shouldn't change if all you're doing is translating the crate along the normal), there doesn't seem to be any reason to under-relax here. But I might be missing something! :)

c) Have you ever had any issue with seams between solid tiles? Your character controller looks fine (you sweep to find a normal, which means it should always be correct), but the crate-vs-tile code is only using NGS, which definitely does have issues with seams, so I'm curious if this just hasn't happened to you in practice. (I'm still trying to find a good solution for AABB characters (because, in degenerate situations, they can sweep exactly into the corner where two solid tiles meet and thus have seam problems), which doesn't rely on pre-processing (ie welding parallel segments together) or adjacency info (like Box2d's chain shapes).)

d) I've been trying to find a good way to support smooth movement (circles are good) and standing-on-cliffs (AABBs are good), and your example seems to work, however: doesn't this still have issues when the character lands on the corner of a solid tile? (ie your approach to keep it standing on a cliff is to use an AABB proxy to check below for collision when it's in the grounded state, but since this only applies when it's already on the ground, if the player jumps and then lands on the corner of a tile, aren't they going to be in the awkward "sort of halfway slid down the corner" case that capsules typically produce?) I'm sorry I'm not able to compile this on my own to answer this one. Figuring out a nice way to combine "character shouldn't overlap solid tiles when standing next to them" and "character is a vertical line when colliding with slopes" is something I'm still trying to figure out, it's pretty annoying! :)

Anyway, thanks again for such an edifying project. I'm currently working on a more direct depen solver -- like Erin hints in his slides, in 2D you can pretty easily directly solve for the case where the player is touching one or two planes; we've been experimenting with big worlds (think: 10,000 goombas in a giant procgen space) where doing many iterations to depen a character isn't really practical. (Then again: maybe we just need to move to C/C++ and we won't have performance problems! But it still feels like a big waste of effort to solve iteratively, when we know (thanks to the initial sweep) that we're starting very close to the correct solution.)

Cheers,
Raigan