Physics a bit hit and miss
by Andy Hawkins · in Torque Game Engine · 10/15/2005 (6:50 pm) · 11 replies
I've notice if the frame rate drops - in this case because I had added a lot of trees with collision objects the interaction with their collision boxes is a bit hit and miss. Sometimes when it chugs a little and I head toward a tree there's like a surge from one frame another and sometime I hit an invisible trunk before I get to the tree. Other times I can sort of shuffle through the tree if I keep pushing forward.
I have checked the tree by itself and I can't pass through if the frame rate is high enough.
It seems like the code is predicting where I'm going to be when it chugs and the collisions switch off and on randomly when the frame rate drops.
Are there any known work arounds for this?
I have checked the tree by itself and I can't pass through if the frame rate is high enough.
It seems like the code is predicting where I'm going to be when it chugs and the collisions switch off and on randomly when the frame rate drops.
Are there any known work arounds for this?
#2
Here's vid... hope you can see the problem...(2meg WMV)
www.drewfx.com/Torque/Col_Probs_Trees.wmv
In this pic the light green ones are done using fxFolliage and run at a blistering rate - it's only when I added the darker trees along the path that the frame rate dropped and the collisions started stuffing up...
10/15/2005 (10:04 pm)
About 120 trees in total. 200 polys at close range down to 20 at long range, using 6 fxShapeReplicators that create 20 each. Here's vid... hope you can see the problem...(2meg WMV)
www.drewfx.com/Torque/Col_Probs_Trees.wmv
In this pic the light green ones are done using fxFolliage and run at a blistering rate - it's only when I added the darker trees along the path that the frame rate dropped and the collisions started stuffing up...
#3
10/15/2005 (10:06 pm)
Well my first guess is the collision meshes on the second type of trees you added, but that's just a guess! 
#4
10/15/2005 (10:16 pm)
The collision system itself in Torque does have it's share of problems. I really do believe that is something the GarageGames staff should focus more attention on... a complete rewrite of the collision detection and response system.
#5
Secondly, he's using dts shapes, which by nature (ability to have concave-ness) drastically decreases the performance of collision checking.
Finally, when you take into account that everything in Torque is organized around networking and the ability to play multi-player games over the internet, a lot of not just the accuracy, but sheer performance needed becomes huge--and when you start looking into cross-platform needs, deterministic physics become extremely daunting, if in some cases nigh impossible.
A -lot- of people have tried (and some succeeded) in getting external physics libs integrated into Torque, but pretty much everyone will say that networking and cross-platform determinism make it one of the most daunting tasks encountered!
10/15/2005 (10:42 pm)
Well, for this circumstance in particular, you need to keep in mind that he is using foilage replicators which don't include any physics in the first place, so milage is going to vary.Secondly, he's using dts shapes, which by nature (ability to have concave-ness) drastically decreases the performance of collision checking.
Finally, when you take into account that everything in Torque is organized around networking and the ability to play multi-player games over the internet, a lot of not just the accuracy, but sheer performance needed becomes huge--and when you start looking into cross-platform needs, deterministic physics become extremely daunting, if in some cases nigh impossible.
A -lot- of people have tried (and some succeeded) in getting external physics libs integrated into Torque, but pretty much everyone will say that networking and cross-platform determinism make it one of the most daunting tasks encountered!
#6
Maybe I should just generate bounding boxes zone in scripts instead? Or maybe it's because I'm using the fxShapeReplicator? Maybe the shape replicator doesn't work as well as if I just used individual trees?
10/16/2005 (2:14 am)
For the record the trees which have collision detection on use invisible cubes along the trunk to collide with. The fxReplicator stuff doesn't have any collision detection - it is intended to be too far away to worry about.Maybe I should just generate bounding boxes zone in scripts instead? Or maybe it's because I'm using the fxShapeReplicator? Maybe the shape replicator doesn't work as well as if I just used individual trees?
#7
I seem to remember fxShapeReplicator having some bugs in this regard. I also hit this issue a while back, using the replicator to replicate trees, then being able to walk through some. What I seem to remember is, a seed is created to generate all the trees, that way, instead of passing every single trees location (which would take a long time), just the seed is passed over the network. I think the bug was that the seed was getting incorrectly passed sometimes, so the client side and server side seeds were different. This resulted in the client being able to walk through some trees he could see (because the server had no tree there) and then the client being blocked by some invisible object in other cases (a server side tree was there, but no client side tree was there)
I'd do a search for fxShapeReplicator bug or some variation of that and see what you can find.
Good luck!
- Drew
10/16/2005 (5:10 am)
Hi Andy,I seem to remember fxShapeReplicator having some bugs in this regard. I also hit this issue a while back, using the replicator to replicate trees, then being able to walk through some. What I seem to remember is, a seed is created to generate all the trees, that way, instead of passing every single trees location (which would take a long time), just the seed is passed over the network. I think the bug was that the seed was getting incorrectly passed sometimes, so the client side and server side seeds were different. This resulted in the client being able to walk through some trees he could see (because the server had no tree there) and then the client being blocked by some invisible object in other cases (a server side tree was there, but no client side tree was there)
I'd do a search for fxShapeReplicator bug or some variation of that and see what you can find.
Good luck!
- Drew
#8
Spot on guys!!!! For everyone else here's the fix...
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=6947
fixes fxShapeReplicator.cc and fxShapeReplicator.h to over come the collision detection problem plus invisible trees.
Thanks again!!!!
10/16/2005 (5:12 am)
@Drew - ahhhh this sound like the same thing - I'll have a look and report my findings to this thread for others in future....Spot on guys!!!! For everyone else here's the fix...
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=6947
fixes fxShapeReplicator.cc and fxShapeReplicator.h to over come the collision detection problem plus invisible trees.
Thanks again!!!!
#9
10/16/2005 (7:20 am)
Great catch Drew, and glad it worked for you Andy :)
#10
I'm just happy someone else already fixed the bug and posted a resource. :)
@Andy
I'm glad that took care of your problem!
10/16/2005 (8:09 am)
@StephenI'm just happy someone else already fixed the bug and posted a resource. :)
@Andy
I'm glad that took care of your problem!
#11
I found that there was a huge performance hit from an M16 weapon I mounted on the bad guys and my avatar. It was causing problems with the frame rate because it had irregular sized jpgs mapped to it.
When I changed them to 64x64, 128x32 etc, instead of 102 x 26 that sort of thing, the frame rate peaked again. I think this is a DirectX issue that required texture maps to be sizes using a power of 2.
I originally thought it was my forrest of trees, but they do not slow down the frame rate since I fixed the textures mapped on the M16.
10/27/2005 (5:56 am)
Just an update for the curious - texture sizes can cause slow downs.I found that there was a huge performance hit from an M16 weapon I mounted on the bad guys and my avatar. It was causing problems with the frame rate because it had irregular sized jpgs mapped to it.
When I changed them to 64x64, 128x32 etc, instead of 102 x 26 that sort of thing, the frame rate peaked again. I think this is a DirectX issue that required texture maps to be sizes using a power of 2.
I originally thought it was my forrest of trees, but they do not slow down the frame rate since I fixed the textures mapped on the M16.
Torque 3D Owner Stephen Zepp