Basic Lightning vs. Advanced Lighting

#21 Dear Manoel,

Then how about the buildings? How can i make the collision?

#22 Cai-

just add collision meshes to your models with the col- prefix in front of the name. if you put col-#number for the name of a mesh, the engine will know not to render it but use it for collision. use low-poly concave meshes for the walls of the building.

#23 @Cai: if you can send me a DAE file of one of your buildings I can add collision meshes to it so you can see how it's done.

#24 @ Manoel

A bridge model (maya version) with load (no collision) is at

155.69.101.53/sample/bridge.rar

Thank you so much.

My email address is ydcai@ntu.edu.sg

Seems there is limitation of collision mesh numbers, right? 8? What is use of LOS Collision mesh? If my building is very complex, then how?

#25 @Cai: I'll look into the model now. About collision meshes, I just looked at the source code used by TSStatic to load the collisions and there are no limits on the amount of collision meshes.

I also found some undocumented feature I'll try: you can control which kind of shape each collision mesh will have by using special names. Using only "Col" treats the mesh as a generic convex shape while "ColBox", "ColSphere" and "ColCapsule" will create a box/sphere/capsule which fits the mesh. And finally, you can use "ColMesh" if you want a mesh to use per-triangle collision (same as visible mesh, but you can use it only on parts of your collision that really need it).

-- EDIT --

Looking again the box/sphere/capsule/convex are only used for feeding collision into the physics plugin (PhysX or Bullet). T3D always uses polysoup for other collisions.

#26 Just to add a question to this too, used to working with DIFs and just converting over to DTS. When you've got complex buildings i.e. with stairs, multiple floors, etc would you create seperate collision meshes for every part of the building?

That will add a big chunk of work for our artists when creating buildings as I can imagine needing 50-500 col- meshes

Or would you recommend using visible mesh for buildings?

(Suddendly BSP seems so nice)

#27 @Andy: I just took a good look into the collision code. Even collision meshes use triangle-based collision (so they don't need to be convex) and each mesh has it's own bounding box tested before the per-triangle tests are done.

So, breaking your model into multiple collision meshes will improve performance, but you don't need to split each individual detail into a separate mesh, just the ones which are big (compared to the player) and complex.

Selecting a complex collision structure in Maya and using the "separate" option should offer a good-enough separation already.

@Cai: I finished the model (www.mediafire.com/file/umynnhtnnwd/cai.7z. Here's how the collision mesh looks:
It follows the shape of your highest LOD, but without the details (coarse surface), giving priority to the surfaces the player will directly collide with.

The model has 22 collision meshes, here's the hierarchy:

#28 Wow thanks Manoel that's some of the most useful information I've seen on the collisions, everyone still seems to be under the assumption that they must be convex still.

We've have to nudge Mich to get something like it included in the T3D documentation.

#29

Quote:collision meshes use triangle-based collision (so they don't need to be convex)

0_o Really? When did this happen?

Quote:
everyone still seems to be under the assumption that they must be convex still.

Yes .... yes I am ...

#30 The only time collision meshes need to be convex is if you want them to interact with the stock Vehicle classes. They have some very optimized code built around the assumption that their collision mesh and the collision meshes they will be colliding against are convex (using a rather poor GJK implementation). I looked into moving that into a more generalized arbitrary polysoup solution like the Player and ray casts (Projectile) but it was more work than I had time for.

Torque 3D hasn't had the requirement for convex collision meshes since at least version 1.0 if I recall correctly...it may have even happened in an earlier Beta for 1.0.

#31 Cool, thanks for the heads-up.

#32 Ah, the MB file was seved form Maya 2010, and just now I noticed Cai's file was in 2008 format. So anyone using an older version of Maya (or another program entirely) might want to import the DAE file instead.

BTW, opcode (which T3D uses for triangle collision) stores triangles using AABB trees. This means that it can quickly find out which triangles' bounding boxes intersect the player bounding box.

So here are two key details for getting ultra fast collisions:

1) Keep triangle density low:
This means making sure the player cannot collide with too many triangles at once (I'd say 10 triangles as an average, 20 max). This means avoid small intricate (relative to the player) collision shapes, like bevels, handrail supports, small cylindrical shapes (use rectangular shapes instead). Also avoid having vertices which are shared by many polygons:

In the image above, if the player is at the center of the left cylinder it'll have to collide with 20 triangles. In the right cylinder only 4 or 5 triangles will be tested for collision. I used Maya's "flip triangle edge" tool to change the left cylinder into the right cylinder.

2) Keep your collision geometry aligned:
This one is a bit hard to explain. OPCODE stores triangles using AABB trees, so it can quickly discard tons of triangles from testing. But if your triangles aren't well aligned with the X, Y or Z axis, they'll have large bounding boxes and they'll be collision tested when they should not.

Lucky, the vertices for each mesh are stored relative to their transforms. If you rotate a box in Maya, as example, the box transform will be rotated, but it's polygons will still be aligned with it's internal XYZ axis. But if you rotate the vertices the polygons themselves will be rotated and the bounding box will be bigger than the box itself:

The left box had its vertices rotated, while the right box had its transform rotated. You can see the bounding box of the left box, but the right box's bounding box still fits the box tight.

#33 Great stuff Manoel!

#34 Agree with Matt, great write-up!
Thanks, Manoel!

#35 Idiot proof explanations make me happy! :)

#36 @Manoel

Thank you so much! I will modify my models...

I see that some objects can do the imposter, but some can't, is it because of the mesh name?

#37 Thanks Manoel, this will be a great help.

#38 Is this naming scheme still valid for Torque 3d 1.1 beta1? In shapeBase.cpp starting from line 256 they are iterating over details names ( which I believe is meshes names ) and compare it to "collision-" template and I there is nowhere even single mention about "col-" meshes and no mention at all about special nodes names.

#39 It does not seem like the collision_* fields are required, i can delete them from my scene and stuff still collides on the col-* objects

#40 @Chris and Maxim: The collision_* and detail_* are only necessary if you're exporting to DTS directly (otherwise the meshes will be ignored by the exporter). Collada doesn't need them.