Collision Issues (with images)
by Vernon Finch · in Artist Corner · 09/19/2005 (4:53 am) · 3 replies
So thanks to Nigels awesome tutorials I got my first blender model ingame today without many dramas. Nothing to write home about, but I was happy nonetheless.
I have 2 issues with my model though.
1) I can run the orc into it fine, so the collision works, but if I shoot a crossbow bolt at it, it goes right through it. Is this possibly because its quite a thin rectangle collision mesh (see the blender image).
2) If I run into it repeatedly I can get the orc stuck on the model. Are there tricks to avoid this?
Here are two images, the first ingame with the orc stuck to the model, the second is in blender, with the collision box selected so you can see it.
I have 2 issues with my model though.
1) I can run the orc into it fine, so the collision works, but if I shoot a crossbow bolt at it, it goes right through it. Is this possibly because its quite a thin rectangle collision mesh (see the blender image).
2) If I run into it repeatedly I can get the orc stuck on the model. Are there tricks to avoid this?
Here are two images, the first ingame with the orc stuck to the model, the second is in blender, with the collision box selected so you can see it.
#2
It is my belief that is has everything to do with optimisations within TGE for collision detection.
The bolt flying through I beleive is because the collision of the bolt can only be calculated at so many discrete points in time. Thus it get calculated once on this side of the model, and then on the other side and no collision detected. Solution is to increase the sampling rate in the engine (drops frame rate) or increase the collision box for your model. Alternatively slow the bolt down for more collision samples per unit of distance as sampling is constant per unit of time.
As for the Orc getting stuck I think this is because of again too low sampling rate for collision detection coupled with the fact his collision box is quite large compared to the object. If his large Collision box can move into the small one without being detected due to too ow sampling rate, it is possible one face of his box can not then "jump" back as he is no moving fast enough to have the "jump" out of the overlap not to be detected.
Hope that makes sense. These are just limitations of the starter.fps implementation of TGE and can be changed if they are troublesome but changing scripts and/or code.
P.S. Glad you like the tutorials and good to see NZ being represented :)
09/19/2005 (3:52 pm)
Yes, I've found this problem with thin models.It is my belief that is has everything to do with optimisations within TGE for collision detection.
The bolt flying through I beleive is because the collision of the bolt can only be calculated at so many discrete points in time. Thus it get calculated once on this side of the model, and then on the other side and no collision detected. Solution is to increase the sampling rate in the engine (drops frame rate) or increase the collision box for your model. Alternatively slow the bolt down for more collision samples per unit of distance as sampling is constant per unit of time.
As for the Orc getting stuck I think this is because of again too low sampling rate for collision detection coupled with the fact his collision box is quite large compared to the object. If his large Collision box can move into the small one without being detected due to too ow sampling rate, it is possible one face of his box can not then "jump" back as he is no moving fast enough to have the "jump" out of the overlap not to be detected.
Hope that makes sense. These are just limitations of the starter.fps implementation of TGE and can be changed if they are troublesome but changing scripts and/or code.
P.S. Glad you like the tutorials and good to see NZ being represented :)
#3
I'm more a programmer than an artist, so I was just making sure there weren't any tricks of the trade that I wasn't aware of when making the collision boxes.
09/19/2005 (5:45 pm)
Cheers. I suspected it might be the low sampling rate. I'd read several rather in depth discussions on the SDK forums, but its not something thats bad enough for me to warrant spending much time on (especially during term time).I'm more a programmer than an artist, so I was just making sure there weren't any tricks of the trade that I wasn't aware of when making the collision boxes.
Torque Owner Gustavo Munoz