getSceneNodeFromRayBB returns the first scene node which the line supplied to the function intersects with using bounding box collision.
As for getTargetsPosition, i've not come across this function before, where is it from?
That code you posted looks a lot like the shooting code from the tech demo, basically it gives you the intersection point with the map and produces a particle effect to show the collision with a bit of smoke. If the shot doesn't intersect with the map then it just extends the line that the shot travels along so that it effectively disappears into the distance.
I guess it works, as the member replied saying "It works like a charm", but I'm unsure...
So the getSceneNodeFromRayBB is for collision (which can be used for shooting), right?
Thanks
Edit - Also can you explain which would be better for a particle effect, a billboard (which I'm usure of what it is) or just a regular particle emitter?
Depends what the effect is, particle emitters use billboards, they basically spew out some billboards according to some parameters and these can be blended together to create effects like fire, smoke etc.
So if you want smoke then the one in the tech demo is good, if you want something to show the impact of a bullet with something then you might want a little explosion sort of effect, which is better done with a billboard (or a quad, this is better because it doesn't rotate to face the camera) and a texture animator to go through a series of images which depict the explosion.
The getSceneNodeFromRayBB isn't the best way to do collision detection.. The example you have there is good for static objects, ones that dont move, but if you have moving objects you need to make changes, because basically what happens in that code is that when you fire the bullet it does all the calculations for the impact right away, which is fine if nothing's gonna move, it's the best way to do it. But if you have moving objects, if your bullet takes time to travel to its pre-calculated impact location then what if the object it was going to hit has moved out the way? Or something moves into its path? In the first case the bullet will impact in the pre-calculated place, which will now just be empty space, and in the second case it will go straight through the object that moved into its path and ignore it. So when you have moving objects you have to fire the bullet off, probably do no impact calculations at that point (though you could determine its impact with any static objects) then, each frame, you test to see if it has intersected with any objects along the line that it moved since its position last frame and its position this frame.
Using triangle selectors is much more accurate than using bounding boxes, but it's much more expensive so it can slow things down if you have a lot of triangles to check collisions with, but things like OctTreeTriangleSelectors can help cut this down, and you can even do bounding box collision tests first and then if you get a collision, then do a triangle collision test on that object to get the better accuracy, that way you dont test loads of unrequired triangles.
Why won't triangle selection work on different platforms? Should be fine! Do you mean due to the loss of performance i mentioned? It will probably be fine really and if you run into problems then there are things that can help that i mentioned before. So give it a go, if it doesn't work then you can always resort to just bounding boxes.
It also depends on what your models are like, if they're almost box like anyway then bounding box would be fine, but if they're a non box shape then the bounding box collision would be too inaccurate and it would look really bad!
JP wrote:Why won't triangle selection work on different platforms? Should be fine! Do you mean due to the loss of performance i mentioned? It will probably be fine really and if you run into problems then there are things that can help that i mentioned before. So give it a go, if it doesn't work then you can always resort to just bounding boxes.
It also depends on what your models are like, if they're almost box like anyway then bounding box would be fine, but if they're a non box shape then the bounding box collision would be too inaccurate and it would look really bad!
Oh, if there isn't that much of a performace lost, then I will give it go. Is triangle selectors for collision covered in the tutorials?
First, getSceneNodeFromRayBB() finds the first scene node in the scene heirarchy that the ray hits, not the nearest one. Vitek has submitted a patch for a collision manager to address that, but I don't think it's in yet (I may be wrong).
Second, triangle selectors are static; if you are using animated meshes, any triangle selector you create will represent one frame of that mesh, and it won't update. I had a patch for that, but its location escapes me. I can dig it out if you need it, but I won't be maintaining it.
First, getSceneNodeFromRayBB() finds the first scene node in the scene heirarchy that the ray hits, not the nearest one. Vitek has submitted a patch for a collision manager to address that, but I don't think it's in yet (I may be wrong).
No, getSceneNodeFromRayBB has always returned the nearest scene node to the start of the ray. The patch I submitted just made the bounding box intersection test more accurate. The old test was using a bb that was potentially much smaller than the actual object bb. The new code should be using the actual object bb for the intersection test. That change was submitted by bitplane in SVN revision 285.
