Interesting collision (Doors/Animated Collison)
by Glenn Bermingham · in Torque 3D Professional · 06/21/2013 (4:31 am) · 5 replies
So while trying to build a door system I immediately noticed that if you rotate a collision via animation on an object its collision ceases to exist or at the very least reduce itself (in this case a sliding door) the move it moves from its original position.
Diagram as its hard to explain:
Collision box:
___[___]
After moving it via Animation:
[___]
Actual collision after the animation:
___[]
So as shown above here, when the box moves to the left only a small segment is left (Assuming we just moved it on 1 axis). So what that told me is that collision can only work within the bounds the original collision position is.
From this I decided to test this theory by creating 2 collision boxes, one that matched my swinging door and one that covered the entire area of which the door collision would swing (All within the same DAE/Object). Then simply animated the area collision to really tiny after the 2nd frame of animation. The result was that the swinging door collision had collision during its entire animation and this in fact worked.
So what I'm asking is if anyone can tell me whats going on here from a technical stand point, I'm not very savvy with code nor do I have the education to understand it in the source code.
To test this I've added a link to one of my doors: http://www.mediafire.com/?nbkbsascc4z0npo
Copy it into your Torque 3D Game directory then go into the mission editor in-game, add the door from art/shapes/door then find the object ID then type objIdHere.playThread(0, open); , then objIdHere.playThread(0, close); to close it.
Diagram as its hard to explain:
Collision box:
___[___]
After moving it via Animation:
[___]
Actual collision after the animation:
___[]
So as shown above here, when the box moves to the left only a small segment is left (Assuming we just moved it on 1 axis). So what that told me is that collision can only work within the bounds the original collision position is.
From this I decided to test this theory by creating 2 collision boxes, one that matched my swinging door and one that covered the entire area of which the door collision would swing (All within the same DAE/Object). Then simply animated the area collision to really tiny after the 2nd frame of animation. The result was that the swinging door collision had collision during its entire animation and this in fact worked.
So what I'm asking is if anyone can tell me whats going on here from a technical stand point, I'm not very savvy with code nor do I have the education to understand it in the source code.
To test this I've added a link to one of my doors: http://www.mediafire.com/?nbkbsascc4z0npo
Copy it into your Torque 3D Game directory then go into the mission editor in-game, add the door from art/shapes/door then find the object ID then type objIdHere.playThread(0, open); , then objIdHere.playThread(0, close); to close it.
About the author
I spend most of my time working on games.
#2
Also it might be necessary to hide and unhide the appropriate collisionmesh in the onAdd callback.
06/21/2013 (8:38 am)
The technique I am using in my game the Master's Eye is using StaticShape with a mesh with more than 1 collision mesh. For the static (non-moving part) I use a collision mesh which I call collision-1 (standard naming). For the moving part I use 2 collision meshes, 1 for the open position and 1 for the closed position, those I call ColOpen-1 and ColClosed-1. Now, when opening the door you hide the ColClosed mesh and unhide the ColOpen mesh, using the setmeshhidden function. When closing the door you hide the ColOpen mesh and unhide the ColClosed Mesh.Also it might be necessary to hide and unhide the appropriate collisionmesh in the onAdd callback.
#3
06/21/2013 (10:49 am)
Not to go too much off a tangent, but this is IMO one of the big flaws in Torque. Really basic "systems" like a door don't actually exist. Even typing that just feels kinda silly. Torque doesn't support doors. It's kind of weird that it has gone ignored for THIS long. 
#4
Open Animation without collision
Close Animation without collision
then
Open (No animation) with collision
Close (No animation) with collision
Its a longer process but in code you reflect the state of the door and show/hide the appropriate state with collision once the animation has finished.
Collision on Animated doors is a must have without having to do so much to get it working right.
06/22/2013 (9:17 am)
In some cases for doors or revolving garage doors I tend to use 4 states, 2 with collision and 2 without.. Open Animation without collision
Close Animation without collision
then
Open (No animation) with collision
Close (No animation) with collision
Its a longer process but in code you reflect the state of the door and show/hide the appropriate state with collision once the animation has finished.
Collision on Animated doors is a must have without having to do so much to get it working right.
#5
06/24/2013 (5:02 am)
Hi Glenn, I`ve ran into this problem before and its because the animated collision box only updates if it is inside the objects original bounding box. So you have to make sure that the doors bounding box is big enough to encompass the door when it is animated open. The easiest way to do this is make a box in your modelling app, call it bounds, and then edit its visibility to make it invisible. Works very well. Let me know if you cant get it working or if your not sure what I`m on about. :) 
Torque Owner Daniel Buckmaster
T3D Steering Committee
Like I said - that's As Far As I Remember. That's how it worked in TGE and I'm certain that code hasn't changed.