Hi,
Using a "full" triangle selector can be costly. This would evaluate all the tris in the mesh each time the animator check for collision.
Is the "floor" will remain flat? If yes, then you could use the "
createTriangleSelectorFromBoundingBox"
There other way you could try. Convert your mesh to an octree and use this selector "
createOctreeTriangleSelector"
Had the same problem (not as pronounced as yours) and here what I decided to do:
I used another approach (thanks to the recommendations from guys on this forum!
):
I do the "collision test" manually and don't use the animator for this.
Check example 7 (collision example) and look at the
raycollision method. I used conditions to check if the object will be moving, and when it move to a ray test to check if the ray will collide with the land. And get the position height of the collision. (with an ID on the mesh, the test is done exclusively with the ground mesh)
This worked wonder in my current project, because as the character is moving on the ground, I do 3 rays tests:
1 in front, 1 in the middle of the object and 1 in the back then check the height distance between the front and back. Once that is determined, I can choose to set a maximum so the mesh will stop if the distance is too much (giving me a effective way to stop movin if the slope is too steep.)
I use the results to get the position of the collision of the 3 rays, then get the average to position the character. Having a single ray test, is too precise (unless you don't have feets!
) and your model could enter some part of the terrain mesh. Averaging make it smoother. Depending of the performance you have, you can decide to add/lower the ray tests.
As I mentionned before, the test are not done at every frame, it's only done when the mesh is moving. You can fake "gravity" by addind a negative Y vector (as position - vector3df(0,-1,0) for example. With a little more work then you could add a "bounce" when a collision is detected with the ray test. (For the bounce, it will change the negative vector to a positive vector and gradually by using timers, would decrease and make it back to it's negative value. And this will stop at the next collision) Going further and adding "velocity" your would compare the distance from the last frame to the current frame. I would not use this to demonstrate the effects of gravity to NASA
, but for a simple demo or little game... Should do the trick.
With this on my PC, I can have a full scene (landscape, tons of trees, props, and about 15 NPC that are all moving) and still get more than 100+ FPS. So I think doing small ray tests at the proper time is saving some FPS, and is quicker than using an collision response animator. But this method is useful only for "walking/running" on a landscape. The collision response still is useful for me as I used it (bounding box tests) for intercollision with NPC's and objects. (I could simply use a distance test to do that If I want to improve performance further). If you need gravity, friction, buyoancy (floating on water), then think about integrating physic engines (there a couple of nice wrappers on the forum that will ease the work)
I really like that IRRlicht have the possibily to do collision tests "out of the box" and I think it's one of it's advantage. Not every projet need a full physic engine.
Also as Pera mentionned, it's alway a little faster (sometimes much) when you create a "release" build of the application.