Hey Norbo,
I'm getting a really big stall when my character controller walks into the edges of collision, such as the edge of a step and over the 'lip' of an object. I've added Profile and Checkmath and managed to grab these screenshots. I took two random 'default' shots from the 360 (the ones on the left) of the game running while the player is standing still. The ones on the right are when I moved over a small edge/step and paused it (the pause menu corrupted some of the debug text). Any idea why it would slow down here so much? It's the same codebase as Bulkhead and that doesn't do this! Though I remember having some stall problems in Vampire Slayer which is also the same codebase! - viewtopic.php?f=4&t=1808 - I think it might be the same problem.
Given that it did not appear in Bulkhead, my first guess would be character-content interaction related:
1) the character has just walked off the top off of a ledge has a step a steppable distance away, and
2) the character has no contacts with its former support, and
3) the character attempts to validate the step location, and
4) the geometry is somehow complex and requires the full 5 allowed query attempts, and
5) the geometry is somehow complex enough that each query takes dozens of milliseconds.
However, #5 is real tricky to satisfy. Perhaps if there are a few hundred triangles right in that one spot, or perhaps if any of the geometry is explicitly degenerate (zero-area triangles, NaNs and so forth). The collision detector is built to gracefully handle degenerates without spitting NaNs everywhere, so the default usage of CHECKMATH may not catch such geometry.
Also, the above slowdown should only last for a single frame. If the slowdown persists, then this is likely not the specific nature of the issue. Note requirement #2: if the character has support contacts, it won't go through the effort to perform the query to begin with.
Deeper relevant performance measurements might be helpful.
Ok, so yesterday I wasn't entirely sure what BeforeSolverUpdateables was measuring but it seems to be TryToStepDown() /TryToStepUp() (as you said). The other thing I realised is that Bulkhead doesn't have any steps as such, only ramps. Which made me consider placing collision ramps at each trouble spot, but that would involve a lot more modelling.
I did some more debugging, and when I 'step up' in the screenshot over the obstacle in the direction of the arrow I find that it's the step down test that is taking a long time. And it judders over 4 or 5 frames (it feels like anyway). If I come from the left of the picture and run off the end of the obstacle there is no problem.
So in the end, I have removed the entire step down check in CharacterController.cs/IBeforeSolverUpdateable.Update() , and this has "fixed" it. The character control may be a little more floaty but I have gravity higher in my games and I can't really see any difference and it's solved the stall. If you need me to dig further just let me know.
That's very strange- lasting multiple frames is definitely not expected (even if 80 milliseconds for a downstep test turned out reasonable somehow).
If you're up to it, reproducing this in the demos would be very helpful in diagnosing the issue. It sounds like pulling the content in question into the latest development version might be able to replicate the problem. If you can get it to happen in the demos, I can debug it from there.
