I understand how to use the triangle selector, and I understand how to use basic collision detection with irrlicht, but I am attempting to do something a bit more advanced then I could find help for. I searched the forums quite extensivley so I aplogize if this is something that has been answered before.
I am attempting to create a health system that controls a health point amount for seperate body parts of a character. This is for an FPS style game, so I need to know which part of the character is hit by a weapon. Is this a situation where i should create bones in the character and test a collision with the bone for each body part...or do I need to use the vertices of the character to identify each part. Or am I not thinking of something that would be a "good" solution.
Any help or recommendations would be very much appreciated.
Collision Point from a vector
-
rogerborg
- Admin
- Posts: 3590
- Joined: Mon Oct 09, 2006 9:36 am
- Location: Scotland - gonnae no slag aff mah Engleesh
- Contact:
There are some stumbling blocks here.
First, ITriangleSelector et all are static. If you build a triangle selector from a frame of an animated mesh then it stays that way; it doesn't animate along with the model. You either have to re-create the triangle selector from the correct mesh every time you want to test collision (which is fairly expensive, even if you use bounding boxes or other methods to narrow it down). If you want to rebuild from source, this patch might help; see the modified Collision example for per-triangle hits on animated meshes.
Second, triangle selectors just hold arrays of triangles. They don't have any references back to the original meshes, and even if they did, IFooMesh doesn't expose anything like group information which might let you tag various parts of the mesh. As you've noticed, the closest that you can get is joints. However, this might be good enough, if you find the nearest joint to the collision point, and use it to determine what part of the model was hit. You'll get some spurious results though, and may have to add some extra joints just to "flesh out" the model for collision purposes.
Please let us know how you get on, as it's something that's likely to be a common requirement.
First, ITriangleSelector et all are static. If you build a triangle selector from a frame of an animated mesh then it stays that way; it doesn't animate along with the model. You either have to re-create the triangle selector from the correct mesh every time you want to test collision (which is fairly expensive, even if you use bounding boxes or other methods to narrow it down). If you want to rebuild from source, this patch might help; see the modified Collision example for per-triangle hits on animated meshes.
Second, triangle selectors just hold arrays of triangles. They don't have any references back to the original meshes, and even if they did, IFooMesh doesn't expose anything like group information which might let you tag various parts of the mesh. As you've noticed, the closest that you can get is joints. However, this might be good enough, if you find the nearest joint to the collision point, and use it to determine what part of the model was hit. You'll get some spurious results though, and may have to add some extra joints just to "flesh out" the model for collision purposes.
Please let us know how you get on, as it's something that's likely to be a common requirement.
It seems that my biggest limitation here is the inability to group different portions of a mesh. I remember when I was using Ogre a while back it had the ability to control sub-meshes of an object, and I could perform ray-queries on the sub mesh any way I liked.
I think one major drawback to irrlicht is the lack of a standard high speed file format. Of corse I have heard some major complaints on the forums about this issue...but I don't see much of a solution.
I am definitly no strager to the world of open source software, and I understand that using open source systems (especially large ones) often requires the developer to do there own research and modifications. There are many features of this rendering engine I enjoy, mostly its ease of use, and I'm very appreciative of all its contributers.
I am working on a fairly large project, therefore I would like my systems to be effecient, and my systems clean, easy to use, and expandible. I'm more then willing to step up and write what I have to write to get this done. I'm considering designing a custom file format to use with irrlicht that is similar to the .mesh format of Ogre. I sat down this evening and considered the requirements of such a format, and came up with the following:
Sorry to change the topic of this thread, but it seems that it would solve my problems once completed. It just seems that if I use whats currently available to me, the solution will be "sub-par" in that it would be inaccurate, and likely to be slow. If anyone has any other suggestions on this topic, please do let me know, and of corse if anyone is interested in helping thats great too.
I think one major drawback to irrlicht is the lack of a standard high speed file format. Of corse I have heard some major complaints on the forums about this issue...but I don't see much of a solution.
I am definitly no strager to the world of open source software, and I understand that using open source systems (especially large ones) often requires the developer to do there own research and modifications. There are many features of this rendering engine I enjoy, mostly its ease of use, and I'm very appreciative of all its contributers.
I am working on a fairly large project, therefore I would like my systems to be effecient, and my systems clean, easy to use, and expandible. I'm more then willing to step up and write what I have to write to get this done. I'm considering designing a custom file format to use with irrlicht that is similar to the .mesh format of Ogre. I sat down this evening and considered the requirements of such a format, and came up with the following:
- Basic Mesh data - That is vertices and indices, and important vertex information such as position, format, color, and normal information
- Frame Transformation Data - Most likely stored in matrices as its the easiest to work with (at least in my experience)
- Material information - That is U-V coordinates and perhaps some type of material script that can be used to "template" different material "effects" or maps
- Serializer
- Access to vertex/index buffers
- Bounding box/ellipse
- Sub-Meshes - These would have to be created by the modeling program by spliting a mesh into different polygons, which varies depending on the program.
- Skeleton - Structure for storing bone information. Not sure if I would take the same approach as Ogre did by using a seperate file for skeleton structures, or just embed the information into one file.
Sorry to change the topic of this thread, but it seems that it would solve my problems once completed. It just seems that if I use whats currently available to me, the solution will be "sub-par" in that it would be inaccurate, and likely to be slow. If anyone has any other suggestions on this topic, please do let me know, and of corse if anyone is interested in helping thats great too.
Break the body parts into nodes and check for node selection on collision.
Take your model in your editor of choice and break it up into body parts.
What you will do is make a copy of your model file for each body part and then in each separate file delete the vertexes that are not for that body part.
You can then load each body part as a separate child node on the parent model node. Load each child node with no texture (you don't need it for collision) and make them invisible. When you animate your model make sure you send the same animation commands to the child node body parts.
Now you can test for collision on each of the child node body part separately.
Take your model in your editor of choice and break it up into body parts.
What you will do is make a copy of your model file for each body part and then in each separate file delete the vertexes that are not for that body part.
You can then load each body part as a separate child node on the parent model node. Load each child node with no texture (you don't need it for collision) and make them invisible. When you animate your model make sure you send the same animation commands to the child node body parts.
Now you can test for collision on each of the child node body part separately.
