Crushing the hero (collision detection)
-
- Posts: 20
- Joined: Sun Jan 04, 2009 2:47 pm
- Location: Brazil
Crushing the hero (collision detection)
Short version: How can I know my hero is being crushed using only native Irrlicht animators/functions?
Suppose you're making a third person game. Let's say this is the hero (sorry for the use of crappy art, but english is not my native language and I need these images to express myself):
You want your hero to walk over the terrain, climb stairs and so on. So, you can add a ISceneNodeAnimatorCollisionResponse to his node. This will be no big deal because the hero collision surface can be simplified to a ellipsoid and the terrain has a triangle selector, so you have the hero going up and down:
Now let's say the hero has fallen in a deadly trap. A huge block of solid concrete is moving in his direction and there is nowhere to run to:
The hero stays still, waiting for his certain death. What is supposed to happen? The block is supposed to push the hero to the wall and kill him by crushing him. My questions are:
1. How can the block push the player? The player has a collision response animator, but it won't change his position unless the hero is moving. Try it, and you will see.
2. How can the game system know that the player was crushed (by the block or anything else)?
I know I could solve these problems by using a physics engine or writing my own collision algorithms, but I want to know if it is possible to solve them using only native Irrlicht animators/functions/whatever.
Suppose you're making a third person game. Let's say this is the hero (sorry for the use of crappy art, but english is not my native language and I need these images to express myself):
You want your hero to walk over the terrain, climb stairs and so on. So, you can add a ISceneNodeAnimatorCollisionResponse to his node. This will be no big deal because the hero collision surface can be simplified to a ellipsoid and the terrain has a triangle selector, so you have the hero going up and down:
Now let's say the hero has fallen in a deadly trap. A huge block of solid concrete is moving in his direction and there is nowhere to run to:
The hero stays still, waiting for his certain death. What is supposed to happen? The block is supposed to push the hero to the wall and kill him by crushing him. My questions are:
1. How can the block push the player? The player has a collision response animator, but it won't change his position unless the hero is moving. Try it, and you will see.
2. How can the game system know that the player was crushed (by the block or anything else)?
I know I could solve these problems by using a physics engine or writing my own collision algorithms, but I want to know if it is possible to solve them using only native Irrlicht animators/functions/whatever.
Obey.
Just by using what irrlicht provides by default won't do what you need here I think.
1) you could try bbox collisions and move the player manually and also check if it doesn't collide with other block. If it does, the player is "crushed".
2) if you check for bbox collisions yourself you can send some sort of events, if you have event system.
1) you could try bbox collisions and move the player manually and also check if it doesn't collide with other block. If it does, the player is "crushed".
2) if you check for bbox collisions yourself you can send some sort of events, if you have event system.
Working on game: Marrbles (Currently stopped).
-
- Posts: 20
- Joined: Sun Jan 04, 2009 2:47 pm
- Location: Brazil
Let me clarify this: the player can walk over the block if he has the chance. In fact, it might not be a block. It might be a huge cog or a indiana-like killer sphere or even a large hand. That is not supposed to matter because it has a triangle selector and the collision response animator should handle this.1) you could try bbox collisions and move the player manually and also check if it doesn't collide with other block. If it does, the player is "crushed".
Obey.
Well, I'm not that much familiar with collision response animator.CondeNostaw wrote:Let me clarify this: the player can walk over the block if he has the chance. In fact, it might not be a block. It might be a huge cog or a indiana-like killer sphere or even a large hand. That is not supposed to matter because it has a triangle selector and the collision response animator should handle this.1) you could try bbox collisions and move the player manually and also check if it doesn't collide with other block. If it does, the player is "crushed".
*looks at API*
Seems that its possible to do with it.
The animator has:
Code: Select all
virtual void setCollisionCallback (ICollisionCallback *callback)=0
Sets a callback interface which will be called if a collision occurs.
More info:
http://irrlicht.sourceforge.net/docu/cl ... ponse.html
But even though its possible to do it with irrlicht, if you intend to use it in a game, you should use some other physics library for the sake of your CPU.
Working on game: Marrbles (Currently stopped).
-
- Posts: 1215
- Joined: Tue Jan 09, 2007 7:03 pm
- Location: Leuven, Belgium
-
- Posts: 20
- Joined: Sun Jan 04, 2009 2:47 pm
- Location: Brazil
I'll try this. But even if it works when the hero is still, I will have guess where he is supposed to move and change his position by myself.So if you derive from ICollisionCallback and set it you can receive collisions from specific nodes.
I will have enemies walking around and I want them to be crushed as well so it is like an inherited behavior. Does that give any ideas?
Obey.
Well, yeah. You will need to move them yourself. Irrlicht doesn't really do much on the "physics" side. You should just grab bullet physics library, or any other library that looks comfortable to use for you and does what you need.CondeNostaw wrote:I'll try this. But even if it works when the hero is still, I will have guess where he is supposed to move and change his position by myself.So if you derive from ICollisionCallback and set it you can receive collisions from specific nodes.
I will have enemies walking around and I want them to be crushed as well so it is like an inherited behavior. Does that give any ideas?
Irrlicht's "physics" is only meant for small scale stuff like node picking, checking intersections between few nodes.
Working on game: Marrbles (Currently stopped).
if 2 meshes collided returns true:
here, an animator between 2 animated meshes, (the cube is the mesh, the hero is the entity):
Code: Select all
bool nGetMeshesCollide(IAnimatedMeshSceneNode* mesh1,IAnimatedMeshSceneNode* mesh2)
{
return mesh1->getTransformedBoundingBox().intersectsWithBox(mesh2->getTransformedBoundingBox());
}
here, an animator between 2 animated meshes, (the cube is the mesh, the hero is the entity):
Code: Select all
void nSetCollisions(IAnimatedMeshSceneNode* mesh,IAnimatedMeshSceneNode* entity,int mode,
float SX,float SY,float SZ,
float GX,float GY,float GZ,
float OFFX,float OFFY,float OFFZ)
{
IMeshManipulator* meshManipulator = SceneManager->getMeshManipulator();
ITriangleSelector* selector;
switch(mode)
{
case(0):
selector = SceneManager->createTriangleSelectorFromBoundingBox(mesh);
break;
case(1):
selector = SceneManager->createTriangleSelector(mesh->getMesh(),mesh);
break;
case(2):
selector = SceneManager->createOctTreeTriangleSelector(mesh->getMesh(),mesh,meshManipulator->getPolyCount(mesh->getMesh()));
break;
case(3):
selector = SceneManager->createTerrainTriangleSelector((ITerrainSceneNode*)mesh);
break;
}
mesh->setTriangleSelector(selector);
// create collision response using all objects for collision detection
scene::ISceneNodeAnimator* anim =
SceneManager->createCollisionResponseAnimator(selector, entity, core::vector3df(SX,SY,SZ), core::vector3df(GX,GY,GZ), core::vector3df(OFFX,OFFY,OFFZ));
entity->addAnimator(anim);
}
Last edited by nespa on Tue May 10, 2011 7:02 pm, edited 1 time in total.
He said he wants per triangle collisions, I think.nespa wrote:see here:
[/code]Code: Select all
nGetMeshesCollide(IAnimatedMeshSceneNode* mesh1,IAnimatedMeshSceneNode* mesh2) { return mesh1->getTransformedBoundingBox().intersectsWithBox(mesh2->getTransformedBoundingBox()); }
Working on game: Marrbles (Currently stopped).
I agree. Irrlicht's collision system is for more basic stuff, like picking up nodes or to navigate a static map without passing through walls, which is something useful for visualization purposes, perhaps, but for a game, it is too little, and too unoptimized.Radikalizm wrote:I really wouldn't use the built-in irrlicht collision functions for this, Irrlicht is a rendering engine, and you clearly need a physics engine, so it'd make your life much easier to just take that option
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
-
- Posts: 20
- Joined: Sun Jan 04, 2009 2:47 pm
- Location: Brazil