collision is my Enemy [HELP]

[anandh]

Hi all,

Code: Select all

----------------------------
         ||
         ||
  
----1 <------------> 2----

         ||
         ||
----------------------------

I have one Enemy running between 1 to 2 and Vice-versa.
I'm using FPS camera with gun attached is player.
1. How to find that player is in front of the Enemy?(From Enemy camera).
I saw this getSceneNodeFromCameraBB in collision example it is clear.
can you brief me how to pass the value for getSceneNodeFromRayBB.

[CuteAlien]

I don't think I really got what you are looking for. Maybe you could tell what you need that for exactly? Is this for finding out if an enemy player will hit you when shooting? Or is it about if he can see you?

If it's about shooting you need a line - object collision. If it is about seeing the player you could start by checking the angle between his look-at vector and the vector from enemy to player.

[anandh]

In collision ex using getSceneNodeFromCameraBB we can pick scenenode in which our camera is looking.
How to pick scenenode that the Enemy is looking at.consider enemy is moving in a single direction.

[CuteAlien]

Ok, then you need the line - object collision. You can use the getSceneNodeFromRayBB. It needs a line as parameter. That lines starts at the enemy and the endposition is the point at which he is looking. That's usually calculated as endposition = enemypos + viewvector * somelength. The length is up to you (it decides how far he can look. The viewvector can be obtained by rotating the original view vector of your object by the same matrix which is used for the enemy node.

Lets say your model looks originally in (0,0,1) - that's rather usual, but this is really defined in your modeler (the direction where his nose is - if in doubt draw the line or try (1,0,0) and (0,1,0) ). Then you should get the lookvector like that:

Code: Select all

core::vector3df view(0,0,1);
const core::matrix4 & mat = enemySceneNode->getAbsoluteTransformation ();
mat.rotateVect (view);

Be careful not to include the enemy itself in it's collision (you can exclude it by id's or by setting the startpoint of the line outside the radius of himself).

[anandh]

CuteAlien,not able to pick the node properly.May be problem with my code.Help me.
Here is my code.
Render Loop

Code: Select all

core::vector3df botr  = BotNode->getRotation(); 
core::vector3df botv =  BotNode->getPosition();

Bot Rotation

Code: Select all

core::vector3df bot_direction = botv  - target; 
botr  = bot_direction.getHorizontalAngle(); 
botr.Y+=90;
BotNode->setRotation(botr);

target is my position where my Bot want to move.
Bot Movement

Code: Select all

	botv.X	= botv.X +	( cos(botr.Y *	3.14159265f/180.0f)*speed ); 
	botv.Z	= botv.Z -	( sin(botr.Y *	3.14159265f/180.0f)*speed );

[rogerborg]

Code: Select all

blah blah
core::vector3df bot_direction = botv  - target; 
blah blah blah blah

target is my position where my Bot want to move.

Then target is all that you need to create your vector, if you've described your problem correctly.

You've got bot_direction backwards though; botv - target will produce the vector from the target to the bot. You want the vector from the bot to the target.

Also, if you start a default ray check from within the bounds of a default scene node, then you will hit that node, i.e the bot will always hit its own node. You need to use ID bitmasks to avoid this.

Code: Select all

// Done as a macro as some compilers complain about |ing enums
#define HITTABLE_NODE  (1 << 0)
#define IS_A_BOT (1 << 1)
#define IS_A_PLAYER (1 << 2)

// Set appropriate ID bits.  If you don't set any, then by default
// all bits are set - this is not what you might expect!
playerNode = smgr->addAnimatedMeshSceneNode(playerMesh, 0, HITTABLE_NODE | IS_A_PLAYER);
...
BotNode = smgr->addAnimatedMeshSceneNode(botMesh, 0, HITTABLE_NODE | IS_A_BOT);
...


core::vector3df botLookVector = target - BotNode->getPosition();

...

// Before checking for collisions, ensure that the checking bot
// can't hit its own node
s32 botId = BotNode->getID();
BotNode->setID(0); // 0 won't match any bitmask

scene::ISceneNode * selectedNode = smgr->getSceneCollisionManager()->getSceneNodeFromRayBB(botLookVector, HITTABLE_NODE);

BotNode->setID(botId); // restore its ID bitmask

If that doesn't do what you want, then your 'target' position is wrong, or you have a different problem to the one that you described.

[CuteAlien]

I do once more not completely get it. You seem to care about movement now. I told you the way to check for collisions which occur in the direction where the enemy is looking. Do you want collisions in the direction where it is moving? In that case it's like rogerborg already said: the line has to be along targetpostion-currentposition.

Just a minor bug in rorgerborgs code, getSceneNodeFromRayBB does not take a vector but a line as first parameter. So you need to use a line like core::line3d<f32>(currentposition, targetposition).

Or the same using rogerborgs variables should be:

Code: Select all

scene::ISceneNode * selectedNode = smgr->getSceneCollisionManager()->getSceneNodeFromRayBB(core::line3d<f32>(BotNode->getPosition(), target ), HITTABLE_NODE); 

[anandh]

Thx for all your reply.Its working fine.One more problem.

Assuming that passing the ray in some direction.it crossing 2 nodes
1. Wall
2. Player (Player is behind the wall)
The selectedNode returned is Player.How to pick the node that is first in that path.

[CuteAlien]

According to the documenation it should already return the node nearest to ray.start. An additional parameter (or function) to allow returning all nodes along the ray would be incredible useful, but is not yet available. If this really does not work it would be a bug.

[X-prt]

i think the problem may be that your wall doesn't have the HITTABLE_NODE bitmask, does it?

[rogerborg]

Thanks, CuteAlien, I should have compiled that first.

Thx for all your reply.Its working fine.One more problem.

Assuming that passing the ray in some direction.it crossing 2 nodes
1. Wall
2. Player (Player is behind the wall)
The selectedNode returned is Player.How to pick the node that is first in that path.

Assuming that the wall is part of a larger world scene, then...

[Short answer]

See example 07.Collision. After doing all of the above, also do this:

Code: Select all

scene::ITriangleSelector* yourWorldSelector = 0;
selector = smgr->createOctTreeTriangleSelector(yourWorldMesh->getMesh(0), yourWorldSceneNode, 128);

...

core::vector3df intersection;
core::triangle3df tri;

if (smgr->getSceneCollisionManager()->getCollisionPoint(core::line3d<f32>(BotNode->getPosition(), target ), yourWorldSelector, intersection, tri))
{
    // If the distance to 'intersection' is less than the distance to the 
    // scene node returned by getSceneNodeFromRayBB(), then the
    // wall is nearer than the scene node
}

[Long explanation]

Remember that so far we're talking about doing bounding box collisions. If that wall is part of a large world scene, then you're not checking for intersection with the wall, but with the whole world. As the line will presumably start inside the world, it will always hit it. That's not useful information. The reason that the world isn't always selected is that getSceneNodeFromRayBB() treats the distance to each scene node box as the distance from the line start to the nearest edge, even if the line starts inside the box. It should perhaps check if the line starts inside the box and treat that as a distance of 0, but it doesn't, and that wouldn't help here anyway, as we can't use a line/box check on the world anyway.

What we have to do is to perform an actual line/triangle collision with the world, and therefore the wall, and see if that collision is closer than the nearest scene node collision. If it is, then there's a part of the world in the way.


[Towards A Better Solution]

Lobby bitplane, hybrid, and/or niko to incorporate this patch which introduces a new method, getSceneNodeAndCollisionPointFromRay() which will do accurate ray/triangle collision checking on the entire scene, including on animated meshes, as well as an updated collision example demonstrating it which will hopefully make questions like this redundant.