I'm coding a Unity game, and unfortunately invested a great deal of time into it before I realized how sub-par the mesh collision system is. After plenty of time spent exhausting every available option for doing it the "Unity" way, I could still not get a platformer movement that didn't feel floaty and physics-based, while also being robust enough to handle fast object speeds. So, I set out on the ironic, degrading task of coding mesh collision from scratch in an engine I paid thousands for.

Anyway, I've gotten as far as coding intersect detection between two arbitrary meshes, using AABB octrees. Now the question I can't seem to find a robust solution for is how to find the push out vector between them. I can assume one is convex but the other (terrain) has to be non-convex. I also might be able to get away with replacing the convex mesh with a mathematical Y axis cylinder (rather than a cylinder mesh which I've been using up to this point).

Rather than fumble around, I looked for a resource on this problem which has no doubt been solved dozens of times. But I couldn't find much.

I considered buying this book but I looked inside and it seems like it doesn't have the info I need. Can anyone point me in the right direction?

Thanks!

Yeah, its more probable you are using Unity wrong. Bear in mind there are no end of platformers written in Unity and I doubt that they all rewrote the collision detection. Were you using the CharacterController rather than trying to model the player with a rigid body?

I'll warn you now, collision detection is probably the easiest part of getting a character controller working. Dealing with the collision response in a robust manner is the hard part and this will just get more and more difficult, the further you proceed. Not impossible of course, but very much non-trivial.

Just as evidence that I know whereof I speak, this is hand-written and took me months and a great deal of dead-ends and frustration to get working. The collision detection part (I implemented GJK for this project) was pretty easy compared to the rest

I'm pretty sure you're taking the wrong direction here. I don't think you realize the amount of work needed to implement collision detection. I'm also convinced that the built-in collision detection in Unity should satisfy your needs. A couple of questions:

- Are you using a mesh collider for your dynamic objects? If so, do you really need that? Character's colliders are usually capsules or sphere for performance reasons.

- Did you try to set this option CollisionDetectionMode.ContinuousDynamic to your fast moving objects?

If you really think you should rewrite the collision detection code, then good luck. The book you want to buy is a great reference. You can also find useful information and code samples there: http://www.geometrictools.com/.

That website is a great reference, thank you!

I'm well aware that this is going to be a ton of work, but I don't really doubt my ability to pull it off given time. I know plenty of people make platformers in Unity, but many of them feel slippery and unsatisfying. I need my controls to be rock solid and Unity's engine just isn't really built for that. Character colliders are out of the question as a capsule collider inevitably leads to bad behavior on platform edges. I need cylinders and unfortunately with Unity that means I'm stuck with mesh colliders, which don't support ContinuousDynamic for mesh-on-mesh.

I also need the physics to be as "fake" as possible (meaning the velocity of the player is 100% determined by my own scripts each frame) which seems possible in Unity with character controllers but very difficult with rigidbodies which I need for a cylinder shape. I think I looked into trying to hybridize a character controller with a mesh collider but it didn't really work and it would have been more of a kludge than anything.

Yeah, its more probable you are using Unity wrong. Bear in mind there are no end of platformers written in Unity and I doubt that they all rewrote the collision detection. Were you using the CharacterController rather than trying to model the player with a rigid body?

I'll warn you now, collision detection is probably the easiest part of getting a character controller working. Dealing with the collision response in a robust manner is the hard part and this will just get more and more difficult, the further you proceed. Not impossible of course, but very much non-trivial.

Just as evidence that I know whereof I speak, this is hand-written and took me months and a great deal of dead-ends and frustration to get working. The collision detection part (I implemented GJK for this project) was pretty easy compared to the rest

As I said above the CharacterController won't work for me. The collision detection part was fairly straightforward for me as well, but I know I've just opened a can of worms as far as handling the collisions goes. I'm not looking forward to that.

Maybe I could simply avoid all this pain with a hack using my current system. I could try using the CharacterController, and after it has moved, run my own intersect function with a cylindrical mesh (or mathematical cylinder) and just move the character vertically until they either aren't overlapping or the algorithm gives up and puts it back where it was. It would definitely be one of the kludgiest systems I can think of but at the end of the day if it feels solid to the player and saves me a ton of work, I'm OK with it. I'm not a masochist who thinks I have to do everything myself, just very particular about player movements.

Hmm, I'm trying to understand what the issues with edges and capsules are, since most 3D platform games use a capsule as the main collision shape. My controller uses a base capsule shape, but then does a variety of raycasts to modify the behaviour.

Maybe you can augment the Unity character controller with some raycasting to get the behaviour you are looking for?

That might be what I have to do. Thanks --- I appeciate the advice. I may have the ability to code this custom collision system, but whether I have the endurance to spend so much time expanding the functionality of an engine I'm starting to loathe is another story.

I would argue that many, if not most 3D platformers use cylindrical collision bounds (usually a little smaller in radius than the actual visual model is). Just take any professional, AAA 3D platformer (i.e. not made in Unity) and gradually walk off the edge of a platform. What you will see is not a gradual, unsatisfying fudge off the edge of the platform (as in Unity) but a deterministic, either-it's-on-or-it's-not sheer drop. The people who made Unity may consider themselves professionals but they have a lot to learn about how to make a rock solid platformer. Just because Unity's documentation says capsules are standard doesn't make it true.

Also you'll notice that, when walking up ramps, many platformers will allow the player's speed in the XZ plane to remain constant, while moving them up and down in Y to match the ramp (difficult to accomplish with Unity's pushout), rather than slowing down. You can also see players stick to declines rather than flying off them (granted, this can probably be kludged with raycasts in Unity).