Rigid.cc and rigidShape
by Demolishun · in Torque Game Engine · 09/21/2006 (10:31 pm) · 10 replies
Is there any way to speed up the the existing physics code?
I placed 7 spherical objects in the engine that roll down the hills and huddle together to get a bunch of collisions going. They are isospheres with a subdivision of 2 when creating in Blender for the collision mesh. The engine just slows to a crawl. I tried limiting the number of iterations inside the resolveCollisions do while loop, but it still slows down to a crawl with 6 to 7 objects. I have to imagine that you could get the code to be faster than that. I guess what I am asking is where is the real bottle neck in the rigidShape/rigidClass code?
Thanks,
Frank
I placed 7 spherical objects in the engine that roll down the hills and huddle together to get a bunch of collisions going. They are isospheres with a subdivision of 2 when creating in Blender for the collision mesh. The engine just slows to a crawl. I tried limiting the number of iterations inside the resolveCollisions do while loop, but it still slows down to a crawl with 6 to 7 objects. I have to imagine that you could get the code to be faster than that. I guess what I am asking is where is the real bottle neck in the rigidShape/rigidClass code?
Thanks,
Frank
About the author
I love programming, I love programming things that go click, whirr, boom. For organized T3D Links visit: http://demolishun.com/?page_id=67
#2
09/22/2006 (10:47 am)
The same way vehicles do from what I can tell. 
#3
09/22/2006 (11:27 am)
Spheres for rigid poly collision??? If you want accurate spherical physics, you'll want a custom physics method programmed around all the assumptions you can make with a spheroid object. Otherwise you should be using the absolute lowest approximation of a spherical shape in poly count as possible.
#4
09/22/2006 (2:13 pm)
I understand, but the original question was to try and understand ways to speed up the existing code. My goal is not spherical collision. This was merely a test to stress the code to see what I can do. I do understand that as you add faces the collision resolution speed goes way down. I am will try a slightly simpler shape to see how it scales now. Thanks for the mind jog.
#5
I am going through my old phyics book to relearn all the equations. Hopefully I can reduce the complexity for the general case. I would like to add utlra simple physics with the ability to add more complexity for specific objects. This is a lot of fun to play with!
09/22/2006 (2:24 pm)
Interesting I dropped the complexity of the collision mesh to 1 subdivision icosphere and the frame rate still drops off at the magical 6 to 7 objects. Evidently the slow part of the code is not directly related to the number of collision faces. I am going through my old phyics book to relearn all the equations. Hopefully I can reduce the complexity for the general case. I would like to add utlra simple physics with the ability to add more complexity for specific objects. This is a lot of fun to play with!
#6
If you needed physics in a non-multiplayer environment (or just for client effects), maybe go with an external lib (Rocket Bowl and Tube Twist did that). If you need them networked, use the Rigid sparingly with only as much detail and updates as you need, or consider a custom physics solution tailored to exactly what you want.
09/22/2006 (2:33 pm)
Well yes, the rigid code is based off the vehicle code, so it was never intended for use on more than a few low poly collision hulls flying/driving around a level. It's made to be as light weight and networkable as possible while still providing some kind of reasonable physics. There were some optomizations made to the Rigid, I think mainly pertaining to keeping them from updating in an "idle" state. I'd imagine most "optomizations" you can make would be relative to the scoping and detail the physics are updated at over the network. It's possible there are optomizations in the collision routine and such as well, but that's beyond my scope of knowledge. I really doubt there's much you can do to every get a ton of them going on in one place at once though.If you needed physics in a non-multiplayer environment (or just for client effects), maybe go with an external lib (Rocket Bowl and Tube Twist did that). If you need them networked, use the Rigid sparingly with only as much detail and updates as you need, or consider a custom physics solution tailored to exactly what you want.
#7
09/22/2006 (2:41 pm)
Yeah, I am thinking I will develop a small subset of rigid or use another lib. I am hoping to retain network play though. I could reduce a lot of complexity by completely throwing out the rotation stuff, except when airborn. One thing I really dislike about the current rigid is the stop when hitting another rigid object. I was thinking of doing a quick mass ratio tweak to stop it from doing that. I am kind of looking at doing a linguistic evaluation of certain situations to determine output of collisions. I think it could be used to generalize certain parts of the code. I am hoping I can get a few hundred objects moving around and smacking stuff, but we shall see.
#8
My guess would be that the spheres intersecting each other will cause a lot of expensive collision testing for mesh:mesh. If this is the case, you'll be a lot better off using actual sphere collision proxies instead; sphere:sphere collision testing is pretty darn cheap :-)
What I would do, if I wanted real rigid body physics, is integrate some physics package. Probably Ageia if doing it for payware, or ODE if doing it for freeware. I'd have to work pretty hard on deciding how to distribute physics, and for what objects, though, as a 100-box stack/wall would use significant amounts of networking if distributed as regular entities :-)
09/22/2006 (6:11 pm)
If you need to speed something up, the first step is to profile it, so you know where it is actually spending time.My guess would be that the spheres intersecting each other will cause a lot of expensive collision testing for mesh:mesh. If this is the case, you'll be a lot better off using actual sphere collision proxies instead; sphere:sphere collision testing is pretty darn cheap :-)
What I would do, if I wanted real rigid body physics, is integrate some physics package. Probably Ageia if doing it for payware, or ODE if doing it for freeware. I'd have to work pretty hard on deciding how to distribute physics, and for what objects, though, as a 100-box stack/wall would use significant amounts of networking if distributed as regular entities :-)
#9
www.continuousphysics.com/Bullet/
I have been thinking real hard about putting it in. It is under the Zlib license which is a very liberal license. It is written by some of the people who wrote Havoc I think.
09/22/2006 (6:32 pm)
After I found this:www.continuousphysics.com/Bullet/
I have been thinking real hard about putting it in. It is under the Zlib license which is a very liberal license. It is written by some of the people who wrote Havoc I think.
#10
Note: there is some talk on the ODE mailing list about merging some of the Bullet collision detection into ODE, and continuing forward perhaps as one engine.
09/22/2006 (10:01 pm)
Bullet is an interesting emerging engine. However, I'd probably go with something a little more proven, like ODE. Bullet is a little slower than ODE right now, for example.Note: there is some talk on the ODE mailing list about merging some of the Bullet collision detection into ODE, and continuing forward perhaps as one engine.
Torque Owner Stefan Lundmark
I'm not sure how rigidShape updates forces/position, though.