difference between Bound & Collision?

#1 Well, each model you export require a bounds mesh that surrounds the mesh you are exporting. If your model is a TSStatic, you can use the model's bounds mesh as collision by changing the collision type field to "bounds" in your TSStatic mesh.

As for items, you'll need a collision mesh since it's not a TSStatic type class. The difference here between bounds and collision is that when you touch the bounds nothing really is supposed to happen, but when you touch the collision, the player's onCollision function is supposed to be called.

For example: I have a car that i want to specify the collision note: the vehicle class also needs collision meshes. Then i would need a bounds covering the whole mesh, and a collision covering the colliding parts of the vehicle.

Quote:When I export a player model I only need bounds

This is because if you don't define the collision, the engine will use the bounds as collision i think. FYI, The players collision is defined differently than other objects do a search if you want to find out how.

i think this is the longes comment i've written so far, w00t

#2 What Marcus said -

- actually items don't need a collision mesh, they use bounding-box.

#3 @Steve,
I'm not sure I get you. If you don't have a collision mesh, the ray cast won't detect the item.

@Marcus,
Thanks for the cliffhanger on the player model :D I will try to find & look for those information^^

#4 Elvince,

Items are normally picked up by collision using the bounding box of the player and the Item. When you don't want to pick them up automatically by walking over them, but by using a keystroke which performs a raycast, then you need a collision mesh. But then again you don't have to add them as an Item, but you can add them as TStatic or scripted as StaticShape.

#5

Quote:but you can add them as TStatic or scripted as StaticShape.

... or RigidShapeData. I prefer this one because it as physics. If you need it elvince, I could send you my codes for "picking up items with raycast".

#6 @Marcus,

You're right. RigidShapeData is another option.

#7 Thanks for this explanation.

Now it's more clear.

In fact, I used items for button to call an elevator by example. I think I will stick with item as the mask on raycast will filter more elements than with TStatic.

RigidShapeData might useful in some situation as physics (gravity in particular) is managed :D

What do you use for button model? if not item, what was the driver to use other than item?

#8

Quote:What do you use for button model?

I would use a StaticShape because:
1. It is static, no gravity & stuff.
2. It can have a separate datablock with datablock specific functions.

#9 I agree with Marcus. StaticShape will do the trick. In my game I use levers to control gates and so on. I have added these levers as StaticShape. To use them I have assigned a key to a useProp function, which performs a raycast and triggering the open and close functions which you can declare in the StaticShape object datablock.

Example:

datablock StaticShapeData(lever1DB)
{
   shapeFile = "art/shapes/props/lever1/lever.dts";
   mass = "50";
   drag = "0.1";
   category = "Lever";
};

function lever1DB::UseIt(%this,%db,%obj)
{
   if(%obj.isOpen==0)
   {
      %obj.playThread(0,open);
      %obj.isOpen=1;
   }
   else
   {
      %obj.playThread(0,close);
      %obj.isOpen=0;
   }
}

edit: fixed typo

#10 the datablock function might be interesting for the player to destroy button & so on!

I think between item & staticshape, this is the only (but significant) difference.

#11 I was discussing on another threads about bounds boxes, and by checking some stuff in the source code to try to find answer, it seems that player model just use Bounds box for collision and not collision mesh, did I miss something?

#12 Form my first post:

Quote:This is because if you don't define the collision, the engine will use the bounds as collision

It uses collision only if defined.

#13 Are you sure of this?

in C++ player code you have this comment:
// Collision with the player is always against the player's object
// space bounding box axis aligned in world space.

and I read previous post on older engine than T3D that was referencing the fact that player is just using bounding box collision. Maybe this has changed in T3D ?

#14

Quote:Are you sure of this?

No, but I think Steve or someone else would've corrected me if I where worng. Sorry if I caused any confusion =/.

EDIT: I have never exported a player model FYI

#15 I think you are right except on Player, which seems to be specific :(
I'm honestly lost sometimes and I hope the documentation will at some point clarify all those things ^^
and what to export & when.
by example,I read somewhere that collision mesh can be other than convex mesh in T3D... this information is interesting if it's true, and there are no other way than understanding all the source code to know if it's works^^
The good point is that the community is reactive and usually you got appropriate feedback from "experienced" guys!

#16 @elvince

If you need to use non-convex collisions meshes for your geometry, you can enable "visible mesh" collision on the object's properties. By default I believe this is only supported for StaticShape objects. It's otherwise known as polysoup collision. If you want something halfway in between, say for a vehicle (or other Rigid object) you can use multiple convex collision models to define a potentially concave collision profile.

Player objects use bounding because they have an entire physics system specific to their object type, and because their most common interaction is to collide with other, more complex geometry. I believe -- but am not 100% certain off the top of my head -- that Player actually uses a bounding box size defined in its Datablock instead of the BB defined in the model. The BB size is modified if the Player enters another state, say crouching, allowing it to move under obstacles.

Hope something in that is helpful. This stuff really should end up in the documentation, and theoretically will for 1.1 release from what I've heard. For years the community kind of worked to keep each other up to date on how these various systems worked, but that was an era when the engine cost ~$150 -- new users really shouldn't have to rely on the forums for this kind of basic how-to stuff at this price point. =)

#17 Thanks for those clarification.
Things are getting clearer ^^

I clearly expect a lot from 1.1 doc also. I faced so difficulties to know how to to export my model, what should I put in it BB, Col, Nodes and what's the hierarchy, difference between dts & dae...
I don't blame Torque neither, as I clearly know that getting such documentation up to date can be a big amount of work and I think they are getting the end of the line.

#18 The bounds' main purpose is to define the visibility bounding box. The model is only rendered if the bounds touches the view frustum.