Zombies sharing triangle selector???

You are an experienced programmer and have a problem with the engine, shaders, or advanced effects? Here you'll get answers.
No questions about C++ programming or topics which are answered in the tutorials!
kendric
Posts: 71
Joined: Tue May 29, 2007 9:05 pm

Zombies sharing triangle selector???

Post by kendric »

My zombies!!!

Bad zombies.

They appear to be sharing a triangle selector, either that or because they all come from the same mesh, the auto generation that happens from the bounding box triangle selector seems to be making them share.

Here is the symptom:
When zombies have no corpse(ie they go from being alive to dead and removed from the scene) the projectiles in my game work fine.

But if a zombie is dead, and thus having a lieing down on the ground animation(and hence a very low profile) there is a randomness of me not being able to shoot zombies(bullet passes right through). However if i get into this state where i cant hit a zombie, if i simply point near his feet(where he would be if the triangle selector was using the wrong animation to collision check) i can hit him.

So is it intended that multiple scene nodes comming from the same mesh should behave like this? Am i doing something wrong? Any thoughts would be great. Here is the snippet of relevance:

ITriangleSelector* selector=myGameSceneManager->createTriangleSelectorFromBoundingBox(sceneNode); sceneNode->setTriangleSelector(selector);
selector->drop();

where scene node is an IAnimatedMeshSceneNode and this is called for every zombie in my game once upon their creation.

and then to check collision:

bounding box check code from
bool hit=myGameSceneManager->getSceneCollisionManager()->getCollisionPoint(ray,current->getTriangleSelector(),point,triangle);

any input would be great. Thanks!
kendric
Posts: 71
Joined: Tue May 29, 2007 9:05 pm

Post by kendric »

I tried as an alternative building a fresh triangle selector from the mesh at the scene node's current frame but that didnt seem to help either. Totally stumped on this one. For now I just make the bodies vanish quickly to avoid this.
omaremad
Competition winner
Posts: 1027
Joined: Fri Jul 15, 2005 11:30 pm
Location: Cairo,Egypt

Post by omaremad »

I had a similar bug for .x meshes are you using that format.
"Irrlicht is obese"

If you want modern rendering techniques learn how to make them or go to the engine next door =p
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

.x has a problem with non-animated meshes because the bounding box is not updated and is hence very small.
kendric
Posts: 71
Joined: Tue May 29, 2007 9:05 pm

Post by kendric »

No i am using ms3d format.
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

Maybe you should still visualize the bounding box to see what happens when the selection fails.
kendric
Posts: 71
Joined: Tue May 29, 2007 9:05 pm

Post by kendric »

Wow i didnt know about that. THats nice. Ok so confirmed. The bounding boxes seem to come from some shared mesh. If i kill some zombies the other zombies box's flicker between lieing down and standing up. So some zombies that are actually standing up have lieing down bounding boxes and some zombies dead on the ground have standing up bounding boxes. Any its not constant. They can flip between the 2 depending on when i kill a zombie in game.
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

Ok, this might be a good candidate to check with the new animation system. Could you try to run your code with the branch from SVN?
BTW: You use the latest SDK?! You could also try the older versions (1.2 and 1.3) because we had several major changes in the way the updating is performed.
kendric
Posts: 71
Joined: Tue May 29, 2007 9:05 pm

Post by kendric »

I can most likely figure out how to do that. Yes i am on the latest code. Ill try going back a version if the new branch doesn't help.
kendric
Posts: 71
Joined: Tue May 29, 2007 9:05 pm

Post by kendric »

Do i want to use branches\SkinnedMesh?
or trunk.

Also if you have time to answer another question while I have your attention :)
I am trying to optimize my bullet code. I use something i saw in the engine code and here is the line of note:
if (currentSceneNode->getAbsoluteTransformation().getInverse(mat))

thats a check thats done for every bullet, against every object in the game, every frame. It was in the engine code but I don't pretend to know my matrix math enough to know what to do with it. The problem is with that line in there, as more bullets appear on the screen the framerate goes from 70 to 30 and just onward down as long as the # of bullets is going up. If I comment it out it runs fine, if i comment out everything after it, its still slow, so I know thats the trouble maker.

So just to sumarize my logic:
for each bullet do:
iterate across all valid targets

if (currentSceneNode->getAbsoluteTransformation().getInverse(mat))
{
// transform vector from world space to object space
core::line3df line(ray); mat.transformVect(line.start);
mat.transformVect(line.end);
const core::aabbox3df& box = currentSceneNode->getBoundingBox();
// do triangle intersection test in object space
vector3df edges[8];
if (box.intersectsWithLine(line)||box.isPointTotalInside(line.start))
{
vector3df point;
triangle3df triangle;
bool hit=false;
hit=myGameSceneManager->getSceneCollisionManager()->getCollisionPoint(ray,current->getTriangleSelector(),point,triangle);
if(hit)
{
yadda yadda yadda
}
}
}
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

Yes, braches/skinnedMesh is the new animation system. trunk is the current development branch.
Getting the inverse matrix is quite costly so it's probably not a good idea to rely on this for the basic test. So either use this code and do all bullet tests inside the if part (i.e. do not calculate the inverse more than once per object) or take a less accurate test first and only test objects which are likely to be hit.
kendric
Posts: 71
Joined: Tue May 29, 2007 9:05 pm

Post by kendric »

I've got the subversion stuff on my work machine now so in the morning i will build it under that and see how it goes.
kendric
Posts: 71
Joined: Tue May 29, 2007 9:05 pm

Post by kendric »

There seems to be something wrong with this branch. Its missing some files, for example the CMS3DMeshFileLoader and can't compile. Removing them from the project gets me further but then I run into linker errors.

Am I missing something? Do i merge this with something else to get it to compile?

I am using the 7.1 solution file.
kendric
Posts: 71
Joined: Tue May 29, 2007 9:05 pm

Post by kendric »

I'm a little confused on this still:
if (currentSceneNode->getAbsoluteTransformation().getInverse(mat))

Is the need for the matrix to rotate your firing line so that its valid with an Axis aligned bounding box? I'm gonna see if there is some way i can skip this step unless collision is likely to reduce the number of times this happens. If you have any other ideas let me know. I also did like you suggested and made it only happen once per frame per object. That helped a lot, But its still quite a lot with say 100 objects that the bullets could possibly hit.
kendric
Posts: 71
Joined: Tue May 29, 2007 9:05 pm

Post by kendric »

Ok here is the logic I came up with to prescreen things to avoid doing this expensive bit. Hopefully this logic is not more expensive then the thing im trying to avoid heh. I may have made an error here in my reasoning so if anyone sees one please point it out:

given a bullet traveling along a line ray

vector3df extent=currentSceneNode->getBoundingBox().getExtent();
//Use the largest extent so we don't have to rotate it
f32 largestExtentSQ=max(extent.X,max(extent.Y,extent.Z));
largestExtentSQ*=largestExtentSQ;
vector3df position=currentSceneNode->getAbsolutePosition();
//distance from start of ray to center of scene node in question
f32 distanceSQ=ray.start.getDistanceFromSQ(position);
//if that scene node is farther away from this ray's start then the length of the ray and the largest extent of the scene node
bool tooFarFromStart=distanceSQ>largestExtentSQ&&distanceSQ>lengthSQ;
distanceSQ=ray.end.getDistanceFromSQ(position);
//do the same for the end of the ray
bool tooFarFromEnd=distanceSQ>largestExtentSQ&&distanceSQ>lengthSQ;
//if its too far from both it cant be along our trajectory
if(!tooFarFromStart||!tooFarFromEnd)
{
do normal logic here


Update on this: It seems to work fine and my framerate doesn't drop anymore woopie! Still if there is a logic error let me know :)

Update 2:I added a *2 on the extent. I was seeing misses when bullet time was enabled. Slow moving projectiles can avoid the 2nd half of the too far check because their total length is small, and then if a bounding box is centered at say the feet of a zombie, then the bullet line would have to stop directly on the top of their head to pass the first check. With a X2 i get a much wider sweep for that first test. Seems to work. I added in custom built triangle selection based on current frame. Since it only happens when a bullet is right on top of you now, the impact seems minimal. I was able to get a shots of with high persicion of wether or not they hit. Like a head shot vs a bullet sailing just over their shoulder and missing their head would not
Post Reply