Issues with Collisions.
by Matthew Genge · in Torque 3D Professional · 06/22/2014 (4:21 am) · 7 replies
Hi All,
I am currently working on a new release of Forester Pro, the tree creator for T3D, and it will feature new collision types for trees. Specifically we are adding bevels to the canopy collision mesh, a simple trunk collision mesh, a collision mesh based on an LOD, and a collision mesh based on the LOD of the trunk only. Two of these are shown below:
The collision meshes aren't, however, behaving like I expect even though they look fine in the model.
I have a number of questions:
(1) Does T3D simplify/recalculate collision meshes during import? For example, if the collision mesh is a concave mesh (such as the second example shown above) is it recalculated?
(2) Is there a way to view the imported collision mesh?
(3) If concave meshes are not imported is it possible to construct a collision mesh from several convex shapes? If so how are these specified in the node structure of the model (e.g. col_1, col_2, col_3 etc).
(4) How accurate is the collision mesh of the standard player model? Is this unexpected collision behaviour just a function of a precision issue in T3D.
(5) Is there a way to specify the precision of collisions?
Many thanks for any advice in advance.
Matt
www.hptware.co.uk/forester.php
I am currently working on a new release of Forester Pro, the tree creator for T3D, and it will feature new collision types for trees. Specifically we are adding bevels to the canopy collision mesh, a simple trunk collision mesh, a collision mesh based on an LOD, and a collision mesh based on the LOD of the trunk only. Two of these are shown below:
The collision meshes aren't, however, behaving like I expect even though they look fine in the model.
I have a number of questions:
(1) Does T3D simplify/recalculate collision meshes during import? For example, if the collision mesh is a concave mesh (such as the second example shown above) is it recalculated?
(2) Is there a way to view the imported collision mesh?
(3) If concave meshes are not imported is it possible to construct a collision mesh from several convex shapes? If so how are these specified in the node structure of the model (e.g. col_1, col_2, col_3 etc).
(4) How accurate is the collision mesh of the standard player model? Is this unexpected collision behaviour just a function of a precision issue in T3D.
(5) Is there a way to specify the precision of collisions?
Many thanks for any advice in advance.
Matt
www.hptware.co.uk/forester.php
About the author
I am an Earth Scientist who likes writing games for fun.
#2
2.There is a button in the upper toolbar, the second from right it says "toggle rendering of collisionmeshes in the preview window" when you are in the shape editor, this renders the collisionmeshes.
3.I think you can have multiple collisionmeshes, but I never used it, I always merge them to one mesh.
4.Not very accurate, since the player is a cube in default Torque3D. The collision is calculated out of his bounding box.
5.Not that I know of, I just make everything of a certain size collision and small things not. For example if you have a tree with a branch so big someone could climb or walk on it, then make it with collision.
But on your shown example I could not decide if to make the branches with collision or not, depends how big it will be in the game and the collision for the branches should be simplified for performance, since such little spiky meshes do not work well with Torque collision and you have to consider the tree is moving anyway a little in the wind, so I would leave the branches out and just make the trunk and only make massive branches with collision.
06/22/2014 (5:07 am)
1.No it does not recalculate them, however there may be errors with absurd shapes, but had not much of that so far.2.There is a button in the upper toolbar, the second from right it says "toggle rendering of collisionmeshes in the preview window" when you are in the shape editor, this renders the collisionmeshes.
3.I think you can have multiple collisionmeshes, but I never used it, I always merge them to one mesh.
4.Not very accurate, since the player is a cube in default Torque3D. The collision is calculated out of his bounding box.
5.Not that I know of, I just make everything of a certain size collision and small things not. For example if you have a tree with a branch so big someone could climb or walk on it, then make it with collision.
But on your shown example I could not decide if to make the branches with collision or not, depends how big it will be in the game and the collision for the branches should be simplified for performance, since such little spiky meshes do not work well with Torque collision and you have to consider the tree is moving anyway a little in the wind, so I would leave the branches out and just make the trunk and only make massive branches with collision.
#3
2. There is the toggle collision mesh visability button second from the end of the shapeEditor toolbar. Also if the collision mesh has a material it will be visible if you slide the LOD bar down past the detail levels to the col-1 etc detail.
3. Both should work. Vehicles are made up of multiple convex collision meshes.
4. The player, and all dynamic objects which need transmitting over a server, must be convex. The player actually only uses it's bounding box for collision which is set in the datablock of the player object art/datablocks/player.cs (I think). The stock collision is a box bigger than the player.
5. Not really. Collision meshes can be set in script when the object loads using TSshapeConstructor (I think that's what it's called). Check out the Artist Guide in the documentation, there "might" be some info on it.
Just to note, I modeled seperate model just for collision, 2 simple boxes, and then had it added to the tree model using the tree model onLoad() script in TsShapeConstructor.
06/22/2014 (6:49 am)
1. Actually static objects can have a concave collision mesh called "col-1 (object), colMesh-1(actual mesh)". However it takes a lot more processing than a standard convex mesh. col-1, colBox-1. Torque gets what it's given, no recalculating.2. There is the toggle collision mesh visability button second from the end of the shapeEditor toolbar. Also if the collision mesh has a material it will be visible if you slide the LOD bar down past the detail levels to the col-1 etc detail.
3. Both should work. Vehicles are made up of multiple convex collision meshes.
4. The player, and all dynamic objects which need transmitting over a server, must be convex. The player actually only uses it's bounding box for collision which is set in the datablock of the player object art/datablocks/player.cs (I think). The stock collision is a box bigger than the player.
5. Not really. Collision meshes can be set in script when the object loads using TSshapeConstructor (I think that's what it's called). Check out the Artist Guide in the documentation, there "might" be some info on it.
Just to note, I modeled seperate model just for collision, 2 simple boxes, and then had it added to the tree model using the tree model onLoad() script in TsShapeConstructor.
#4
06/22/2014 (3:35 pm)
Whoops, I forgot statics could have concave collision now :P.
#5
06/22/2014 (4:09 pm)
Everything is pretty well covered above. I will say one thing though, if you can get away with it try using simple box & sphere shapes for the collision geometry.
#6
For example in some FPS-games there are situations where you are behind cover and think "Well maybe I could throw a grenade through the hole there" but when you actually do it, it bounces right back in your face, explodes and completely obliterates you, because the designers decided "Well lets put a big collisionbox around the whole object to make it simpler".
Other situations are where you don't know if you can shoot through the railing or not, sometimes you shoot enemies that are completely exposed behind a railing, but no bullet hits them, thanks to big collisionboxes around the whole thing.
So best thing would be to stick with an as exact as possible low poly representation of the shape itself.
06/23/2014 (9:15 am)
No, don't use simple boxes as collision, as a gamer I know how frustrating this can be. For example in some FPS-games there are situations where you are behind cover and think "Well maybe I could throw a grenade through the hole there" but when you actually do it, it bounces right back in your face, explodes and completely obliterates you, because the designers decided "Well lets put a big collisionbox around the whole object to make it simpler".
Other situations are where you don't know if you can shoot through the railing or not, sometimes you shoot enemies that are completely exposed behind a railing, but no bullet hits them, thanks to big collisionboxes around the whole thing.
So best thing would be to stick with an as exact as possible low poly representation of the shape itself.
#7
Thanks for all the input. My issues were indeed with the size of the player bounding box.
Since Forester is used to produce models for a large range of applications we'll give you the maximum possible choice. It is easy to generate a simple box collision so we will make this one option. We've also kept the old simple meshes, but added means of customizing these (shrinking and beveling the canopy), then a detailed LOD mesh, with a branch size limit that will only include LODs of branches larger than a certain size. This should give the flexibility to meet everyone's needs. We want ensure it isn't routinely necessary to fiddle with Forester Trees and Plants before using them.
Best,
Matt
06/24/2014 (1:51 am)
Hi Guys,Thanks for all the input. My issues were indeed with the size of the player bounding box.
Since Forester is used to produce models for a large range of applications we'll give you the maximum possible choice. It is easy to generate a simple box collision so we will make this one option. We've also kept the old simple meshes, but added means of customizing these (shrinking and beveling the canopy), then a detailed LOD mesh, with a branch size limit that will only include LODs of branches larger than a certain size. This should give the flexibility to meet everyone's needs. We want ensure it isn't routinely necessary to fiddle with Forester Trees and Plants before using them.
Best,
Matt
Torque Owner Daniel Buckmaster
T3D Steering Committee