Gnollrunner said:
I seriously don't understand your issue. If the ball is being pushed directly left, it's stuck.

With ‘stuck’ i mean the problem that you can't get back either. Ofc. it's fine if you can't move forward anymore, but such narrowing passages can indeed make the player (or at least dynamic objects) get stuck in some games.
And in many games it's easy to get stuck if the geometry is noisy. You somehow manage to get ‘in’, but then you can't get ‘out’. Happens quite often, and then you have to reload / restart, which is the worst thing that can happen.
I don't mean situations where my way is ‘blocked’ due to obstacles, which ofc. is no problem but expected.

Gnollrunner said:
Note the Z axis is along the cross-product of the two plane normals so it's moving along the that vector which is the cross-product of the normals. So what exactly is the confusion?

Oh, i think get it now: If the player keeps pushing into the narrowing corner, he can't. And instead his motion is projected to the cross (Z axis), so he can only go sideways from his view. Makes sense.

Gnollrunner said:
Come on, that's the easy case. The OP drew that in his first post, and you drew it too. How can it be you don't get it now.

My point is not that some cases are hard or easy, but that you need to treat cases differently at all. If you have one contact, it's easy. If you have two, it becomes a special case you handle differently with the cross direction. If it's many, you may try all potential combinations, picking the one which is closest to the players input? Whatever, it's another special case.
That's certainly higher complexity and more potential issues than allowing penetration to happen, but then resolving it afterwards. A well defined optimization problem without special cases, and the behavior is intuitive to predict and play as well. This has its own problems and limitations, but just saying.

Gnollrunner said:
If the 3rd contact in the touching list is blocking the cross product of the other two, you are still blocked as you should be.

But the outcome depends on the order of which two faces you use to form the first cross? How do you determine this order?

Gnollrunner said:
There are some details, but I thought it was obvious if you know about the sweep algorithm, that you can't move through geometry.

That's the goal, but there is no guarantee it always works. It works as long as there is enough empty space, but if you fill the space with enough characters penetration will happen.
Or you have things like doors, elevators, moving platforms, etc. If the player blocks their path, penetration will happen.
If you have some physics going on with joints or large mass ratios, joint limits will be violated and penetration will happen.
Even with only static geometry and a single player, make the geometry noisy and complex enough and penetration will happen.

So it depends on your game and geometry. But often it's necessary to deal with penetration, if only for the cases where things go wrong.

JoeJ said:

My point is not that some cases are hard or easy, but that you need to treat cases differently at all. If you have one contact, it's easy. If you have two, it becomes a special case you handle differently with the cross direction. If it's many, you may try all potential combinations, picking the one which is closest to the players input? Whatever, it's another special case.
That's certainly higher complexity and more potential issues than allowing penetration to happen, but then resolving it afterwards. A well defined optimization problem without special cases, and the behavior is intuitive to predict and play as well. This has its own problems and limitations, but just saying.

I'm going to ignore most of your rant because that's what it sounds like to me. There are two general cases one for single geometry collisions, and one for two or more. That's it. If you want to count if statements, any collider will have a lot of them. For instance, in the general stock algorithm, you check for behind the plane, intersecting the plane and in front of it before or after movement. To be optimal if you never reached the plane, you skip all the edge checks and therefore vertex checks since those are now impossible. OMG! more if statements!!

It's a silly argument especially from someone who posted stuff about vectors flying round inside a corner or creeping into the corner slowly. I'm not even sure what constates a corner in your book. Geometry can go in all directions.

But the outcome depends on the order of which two faces you use to form the first cross? How do you determine this order?

There is no dependency. You check all combinations which except in very rare cases will be like 3 max. Even in the rare cases it handles it. The order only effects the direction of the cross product which is easy to handle as I posted before.

That's the goal, but there is no guarantee it always works. It works as long as there is enough empty space, but if you fill the space with enough characters penetration will happen.

That's simply false and a mischaracterization. It always works for any sphere (pill etc.) bound to mesh collision. That's what it's designed for. If you add player collisions that's just an easy bound collision which is what EverQuest did. WoW doesn't even support that. I'm not claiming there is no place for a physics engine. If you have a lot of bouncing objects colliding with each other a physics engine is probably necessary, however for a character moving around a world that's not necessarily true. This supports player to mesh collision and for that it's fine (i.e. there is NO PENETRAION OF THE MESH).

If you have some physics going on with joints or large mass ratios, joint limits will be violated and penetration will happen.
Even with only static geometry and a single player, make the geometry noisy and complex enough and penetration will happen.

So it depends on your game and geometry. But often it's necessary to deal with penetration, if only for the cases where things go wrong.

None of this is relevant to what I wrote. If you want to use something else, use it. What I posted works for the intended purpose. Have you actually written any kind of character controller collider from scratch? Because it doesn't seem like it.

Gnollrunner said:
I'm going to ignore most of your rant because that's what it sounds like to me.

Why do you begin any response with such provoking tone?

If you don't want to discuss ups and downs, lets leave it at this. I doubt there is a clear winner here, because i have never seen any method which has no failure cases.
If you think your method is perfect, my questions are silly and just annoying, but still need to be constantly outsmarted without addressing / understanding them, i'll stop right here and ignore the rest as well.

JoeJ said:

Why do you begin any response with such provoking tone?

Really? How about you attacking my solution while knowing nearly nothing about it?

That's certainly higher complexity and more potential issues than allowing penetration to happen, but then resolving it afterwards. A well defined optimization problem without special cases, and the behavior is intuitive to predict and play as well. This has its own problems and limitations, but just saying.

First, I think this is just false. Second you, at the same time, propose some crazy looking ray bouncing for corners and/or incremental stepping which seems FAR more specialized than anything I'm doing. Even so I said nothing about it until you started looking for deficiencies in my solution which frankly don't exist, or at least none that you brought up. You're just trying to “win” a thread. Note that I posted this same solution to another question a while back, and when the OP decided to go with some other suggestion, I didn't flip out about it and start trying to poke holes in someone else's post. You seemed so sure that my algorithm will fail even though I've tested it running through procedurally generated random terrain. It has handled all cases so far and is well defined. You check for a single collision solution, and if none is found, you check for double collision solutions. If there is more than one you pick the best one. That's it. And again, there is NO WAY to penetrate the geometry because sweeping stops at any blocking geometry.

Also, you seem obsessed with moving into a corner. That's just one small case, which by the way I handle without issue. You can also be contacting two edges, a face and a point, an edge and a point, three faces, three edges, two edges and a face, three points, etc. etc. etc. etc. And then you have an infinite number of directions you can be trying to go with each combination. Geometrically the path forward can only be defined by at most two contacts at any given time, unless you want to start talking about a rotating capsule or some such, which is a more complex problem. In any case that's where the cross-product comes from. Two contacts give you two vectors. I didn't just pull the whole thing out of thin air.

As for being “perfect”, I don't know how you define that. So far it works for anything I've thrown at it, and I haven't devised a case where it fails. Maybe there is a faster solution, so I never say anything is perfect. It's also possible that I've missed something because that's the nature of algorithms, but nothing you have said fits that description.

Gnollrunner said:
Really? How about you attacking my solution while knowing nearly nothing about it?

Read the whole thread again. It was you quoting me on each post i did, making additions, assumptions, and questions.
Which have responded to. But i did not comment on your proposal at all, which i did not understand. I have also said more than once that i do not make any recommendation on any method we have listed up.

Your reactions after that still imply there should be a winning method. You talk about rats nests or wish good luck otherwise.

I get the impression you feel somewhat sulky although there is no reason. So i show interest on your method, and ask for a more detailed explanation. Maybe you feel better if you can talk about your algorithm in detail.

But it didn't work. Quite the contrary. You say my question does not make sense. You don't answer it, but instead tell me ‘it just works’.

I reformulate my question. Because if you would explain the steps your algorithm takes to solve this problem, i would understand it. I also make clear that i don't understand your explanations.

Your response is: 1. I'm just too stupid, bringing up problems which are no problems at all. 2. My example problem questions your algorithm to work properly. But you assure again it just works.
At least it clears up how you use the cross product.
So i realize: Your algorithm is no about resolving collisions, but about constraining the player movement to prevent collisions. Which is something new to me.

I clear up some misunderstandings and differing associations on semantics, and i allow myself to express some doubts on your algorithm. For the very first time, just here above on page 3.
It is true i personally rule your algorithm out for those reasons: At multiple contacts, there are varying results depending on an arbitrary solution of a combinatorial problem, or time complexity growing exponentially if we want to avoid this.
Maybe i get it wrong, but that's my conclusion following the explanations you gave.
I prefer to resolve just the penetration, and not constraining player movements. That's my personal preference, choice and opinion, which i am allowed to express on a form like this.

If you interpret this as an ‘attack’ from my side on your algorithm, fine. I don't care.
If you think i'm silly because i don't understand your algorithm because you fail to explain it, fine. I don't care.
But imo it's much more an attack on my person than on your algorithm which has happened here. But you don't care about this either, i guess.

Gnollrunner said:
Second you, at the same time, propose some crazy looking ray bouncing for corners and/or incremental stepping which seems FAR more specialized than anything I'm doing.

My crazy ray bouncing is simple to implement for dynamic vs. static, robust, and actually an implementation of the ‘sweeping’ method, you seemingly seem to praise.
Like your proposal it prevents intersections.
It's mainly useful for fast moving objects, not so much to model resting contact, in my experience.

Gnollrunner said:
Even so I said nothing about it until you started looking for deficiencies in my solution which frankly don't exist…..

I'm happy for you.

But i'm not willing to continue this non-discussion. I'm no expert with those things. Maybe i'm wrong, but currently i have no need or interest to be enlightened further.
If you have a bad week and just want somebody to argue, look somewhere else.

@JoeJ Cry more. I don't go on the warpath unless someone else does first. In this case that's you. I even said if the OP is not using sweeping, he should ignore my post. I really couldn't care less what anyone else uses. I give my solution and if someone thinks it works for them fine, if not also fine. It's not a competition.

Gnollrunner said:
Cry more.

lol :D

Gnollrunner said:
I really couldn't care less what anyone else uses.

I don't believe you don't care what others do or think. Otherwise you would just shut up finally, or get back to civil behavior.

No need for quarrel, guys. As for where I'm standing, the task for which I started this thread is purely for studying purpose, and I'm not being confined to a particular method or approach. What I'm really looking for is ideas and tips based on other experienced people so I can dive deeper into my task at hand and come up with my own method. For that, both of you guys have given enlightening proposals, which did me a big favour. Big thanks.

zzaustin said:

No need for quarrel, guys.

But …. but ….. but …… quarrelling is a long standing internet tradition. Don't worry, we're likely separated by thousands of kilometers, so it won't come to blows. :D