Thanks for the test results!
As a whole- not bad, keeping in mind this has no acceleration structure yet- neither OctTree
The level itself is accelerated with octree. The 2 dwarfs could easily have octree, too. For the larger one, it might worth it. But for testing purposes, I let them alone with a simple mesh triangle selector. You also need to know that this selector should only be used for low polygon meshes. (so the dwarf with it's 2000 polygons is not the best example...
)
By the way, in most modern games they do not use the same geometry for rendering and collision detection. They have highly simplified meshes. K-dops, convex hulls. I've got convex hulls already on my todo list. They're also using blocks in some situations, for what the planned box selectors will be perfect. Also, there are some situations where they render the mesh, but it has no collision geometry at all. Think about small things on the floor, or very thin pipes on the wall, etc.
Here's an
updated .exe, just copy to the funCollisionDemo3 folder. No improvements here, I just have added the ability to turn "gravity" off, and increased the minimal vector length that is ignored. This will result a little bit more "squared" movement, but it also should reduce jumping. You can also turn the info off and see how it performs.
Once again, I've made some tests with the previously collected contacts to reduce this unwanted effect, but unfortunately I didn't make progress: where moving was smooth previously, it became worse.
But we still have options:
1# The current solution, what the updated .exe does. This reduces jittering on a close range. The strength of this solution is still, the speed. The higher the FPS is, the smaller the jittering is. Cons: squared movement, does not solve complicated situations.
2# Like what 1# does, but add a user controllable "maximum number of iterations" value. This would make it a bit slower in complicated situations, but more accurate.
3# Precalculating. Simplifying the geometry, and then saving the data. In the very beginning the system worked like this. The simplification itself is very slow, but it just have to be done once. It would remove about 80% of the jittering, I guess.
4# Turn the whole system into continous collision detection. Pros: 95% less jittering, even in complicated situations; no worrying about moving with high speed. Cons: this solution will reduce FPS pretty much.
Anyway, I don't worry about this too much. I've seen many commercial games with this unwanted "feature"
. (For example, the Unreal Tournament series) And, in normal situations, it's still less noticeable than Irrlicht's. I've just tested it. (And, in complicated ones, it's much worse
. Irrlicht would simply stop the character there, make it "stuck")
create your funCollision sytem out of the box of Irrlicht, which would mean that no modified .dll would be needed
You can bet on that! It's just a couple of h and cpp files, no modified dlls at all.
Thanks for the link! I've planned something similar.
I managed to stuck under the stairs every time I tried with the ellisoid, but it`s ok for now. Here`s one question I have: Do you use the model`s meshbuffer data for collisions or you transform it somehow? 
Download from rapidshare
