How would one go about doing this? I know that in some games actual box type things are created for the different parts of a character. Is this something that is created through script or should this be something that is added to the model via Maya? If it is from maya how do you set that up, are there any rules or guidelines to make it where the bounding box is not rendered? do you bind it to a new group?

So many questions but I wouldnt even know what to look for in the way of a tutorial. Any links or suggestions would be of great help. Thanks!

EDIT: did some searching on this forum for the word bounding box, most seem old and outdated, a few of them give us some hints as to what to do but the main issue is we have objects that have varying shapes and sizes and some of them without bones. How do we make a bounding box for the mesh's that do not have bones?

It depends on your physics engine and goals. Either you use a tri-mesh as collision mesh or single primitives (capsule, box, sphere). For (almost) static object like trees, chests etc. I would use a tri-mesh, for moving characters I would start with a simplified representation, often a single capsule.

Once you really need more detailed information, you need to choose between hit-detection and collision-detection. A hit-box is useful to determine if a ray (e.g. bullet) hits this character, whereas when you want to use full collision detection, you should support a skeletal animation system. Here you would use two LODs of the skeleton, a hi-detailed one for the model animation (visual) and a low detail one, which will be approximated by several primitives and joints, to interact with the world (often used for rag-doll animations).

Back to maya:

- tri mesh: modelled as simple mesh

- simple bounding box, either OOB or AABB: could be exported by the modelling tool (use scripts), or calculated on the fly when reading the model into your engine

- primitive approximation: use some description to get the data into your game, start with a simple format and write it by hand, export the data by your modelling tool once the management gets too complex (e.g. skeleton)

It depends on your physics engine and goals. Either you use a tri-mesh as collision mesh or single primitives (capsule, box, sphere). For (almost) static object like trees, chests etc. I would use a tri-mesh, for moving characters I would start with a simplified representation, often a single capsule.

Well, without any knowledge of this, my idea was to create a simple box ( for the relative size and shape of each race ) and attach that to the bones but not render it, only use it for serverside prediction of collision. Capsule type of mask would work in general but one day we would certainly like to move to a more complex setup.

Once you really need more detailed information, you need to choose between hit-detection and collision-detection. A hit-box is useful to determine if a ray (e.g. bullet) hits this character, whereas when you want to use full collision detection, you should support a skeletal animation system. Here you would use two LODs of the skeleton, a hi-detailed one for the model animation (visual) and a low detail one, which will be approximated by several primitives and joints, to interact with the world (often used for rag-doll animations).

I think we would need both? Some of our objects do not have bones where as others do. A chest does not have any bones associated with the system so a basic LOD0 would work. A human on the other hand would need collision detection associated with him. The main question is how do we get the different LOD mesh's to load and not render or render? I have worked with other games where you created these elements and exported them all together but the game itself did its magic behind the scenes. That is really the part I am missing as there is no clear guidance on how our engine should use/react to the different LOD parts. I have some basic questions as well that are associated with this that I will try and get answered after I understand the process a bit more.

Back to maya:

- tri mesh: modelled as simple mesh

- simple bounding box, either OOB or AABB: could be exported by the modelling tool (use scripts), or calculated on the fly when reading the model into your engine

- primitive approximation: use some description to get the data into your game, start with a simple format and write it by hand, export the data by your modelling tool once the management gets too complex (e.g. skeleton)

So, say I have an already modeled mesh ( most likely the LOD1 since it is high polygon count ).

I take that same mesh and reduce the polygon count and call it LOD0 or LOD2, doesnt really matter as we can change the meaning in code.

How would I export these from maya so that the game can use them the way they should?

Do I make them separate exports as I am almost certain I would not combine the mesh's into one?

We are using a form of Collida Loader if that helps ( that we had to create custom since there is no loading Library for C# and SharpDX that we know of. )

I hate to keep asking so many questions but we are in a part of the game development that many things are unknown to us. Some tutorials help but as most of them are XNA based and very outdated we are kinda in the big blue ocean without a ship to sail on. So again I thank you for the help in advance.

I actually find your questions interesting in that they give us another view of the challenges in making your game. You guys have been at it for a long while and we can see you're making a lot of progress along the way.

It's not uncommon to have a few levels of collision checking volumes. Use a capsule or large bounding box enclosing your character to do the first check with contact with the character. If the collision enters this volume, you do a deeper search with the OBBs that attach to the bones, for example. From here, you can go on a finer level by using a triangle mesh. This should always be the last step as checking many thousands of triangles in one go can get expensive.

As for your problem on exporting collision meshes, it is possible to set up a dummy mesh consisting of several boxes that are attached to the same rig as your character and treating it as a separate mesh in your game. This will be your collision mesh and the boxes should be big enough to enclose the other mesh entirely.

I think this is a naive implementation but you could make your dummy a second, invisible character, as you suggested, but the boxes of the dummy mesh will move along with the bone transformations. You might define a character as containing the "real" mesh and the dummy mesh and having one skeleton control them both. Maybe export the dummy from Maya separately, and later bind it to the skeleton in the program.

From there, a good idea is that you could possibly toggle rendering between the character mesh and the dummy (or both at once), to make sure that your hit boxes are moving accordingly, and that way you could check for possible dead spots where the mesh might be partially outside a box. So basically, have a separate vertex buffer for each mesh and depending on a debug render flag, tell the program which vertex information to send to the graphics code for rendering.

Very informative and thank you for the kind words. We certainly have not gone the easy route with this process. I look back and see how easy it would have been to make this for XNA or for Unity and it pains me... but honestly we have learned things that will make us all better in the long run. There is a massive learning curve but the kind people of this website, like yourself, are helping to curb the sting! Anyway thanks

The seemingly most expensive solution is not always the best. E.g. if you try to control a character which has an exact physical represenation of each limb including inverse kinetics to influence the control, you will have fun when suddenly an arm get stuck in a closing door and you can't move or turn your character any longer. Might be cool at first, but in the long run it is really frustrating.

Therefor, if you want to control a character, think about how easy it should be for the player, then think about how to improve the visual response e.g. when a foot hit the floor or the player hits a wall, because the latter must not be done using the physics engine, only the animation of the model needs to be modified.