Collision detection System not up-to-date as bounding boxes

[darkmaster83]

I tested SVN 1829, 1.5 branch, and I have to notice a bug in collision detection system.

Even if models' bounding boxes now update correctly during joints' animation (thanks to Rogerborg's good work), collision system works as if they aren't updated yet...so model always stops at the same position and distance from obstacles, while bounding boxes are different for animations.

More information are here http://irrlicht.sourceforge.net/phpBB2/ ... 7&start=15

I hope to be understandable...if not, I'm available for more information and eventually for testing.

[rogerborg]

Can you clarify what you mean by the "collision system"? That you're regularly calling (e.g.)

Code: Select all

core::aabbox3d<f32> box = animatedMesh_robot->getTransformedBoundingBox();
core::vector3df radius = (box.MaxEdge - box.getCenter())*scale;
anm->setEllipsoidRadius(radius);

in your example code, but that the ellipse size isn't changing?

I ask because it looks as though the bounding box of the animated mesh is being updated. If I add this to your example code:

Code: Select all

		 ISceneNode * collision = smgr->getSceneCollisionManager()->getSceneNodeFromCameraBB(smgr->getActiveCamera());
		 if(collision == animatedMesh_robot)
			animatedMesh_robot->setMaterialFlag(video::EMF_LIGHTING, false);
		 else
			animatedMesh_robot->setMaterialFlag(video::EMF_LIGHTING, true);

And then move the robot's arms around, the collision with its overall bounding box appears correct.

[darkmaster83]

I call as "Collision System" the part of Irrlicht code that manages and detects collisions (maybe I'm wrong and/or I don't know well how Irrlich works for collisions...I'm sorry...)
My problem is explained better by these two image:


As you can see collision works as if arm doesn't move...but do you think that this problem is caused by the not updated collision-ellipsoid's radius? Then, in your opinion, is it the problem? I'm sorry to read it as a bug

So, I have to recalculate it!? I would like to use, for collisions, all mesh-buffers' bounding boxes (and not total mesh bounding-box) in order to have a very accurate collision detection (also with other obstacles, smaller than arm's altitude, and between arms and rest of robot's body)...but I think it would be a bit heavy for the program...any suggestions? I don't want to integrate a physics engine because I'm not interesting in dynamics but only in graphics and collisions...

[hybrid]

I think it's a problem with the triangle selector. Those selectors don't work with animated meshes. There are patches in the patch tracker for this issue, but I doubt we will see them in 1.5.

[rogerborg]

As you can see collision works as if arm doesn't move...but do you think that this problem is caused by the not updated collision-ellipsoid's radius?

Well, yes. The collision response animator won't know that you need a different radius unless you tell it. It's a very cheap operation to recalculate and set the radius based on the new bounding boxe, so I suggest that you just do it every frame.

As for more accurate collision detection, I'm afraid that you'll have to implement that yourself. There's currently no built-in Irrlicht collision response animator that uses bounding boxes, let alone a hierarchical check of jointed bounding boxes It would be possible to write one, but it's not a lunchtime job, and I'd like to avoid making any significant modifications to the SVN trunk until after we've got most of the bugs flushed out of 1.5

[darkmaster83]

I understand it...so, if I don't want to write a thousands lines of code, I have to use an external engine to manage collisions more accurately...the problem is that all these engines I know are based on Dynamics and not on Kinematics...

[Dark_Kilauea]

I know that PhysX allows you to set a physics object as kinematic, allowing you to move the object manually and acting on other objects as if it had infinite mass (meaning a box or something won't mess up your animation). This is far better than trying to move an object purely with forces.

I think several of the other Physic's engines have similar things, but I'm not absolutely sure.