Torque 3D PhysX Implementation Problems
by Ronald J Nelson · 11/27/2012 (3:03 pm) · 16 comments
Overall my experience with trying to make a vehicle physics kit that works for both Bullet and PhysX has been a serious pain. Not because of Bullet, but PhysX kicks me back a mile for every step I take forward.
I've gotten hover physics, flight physics and buoyancy all working, and they are very stable even in multiplayer, except in PhysX. First is the core problem, PhysX in Torque 3D does not process gravity properly during any sort of load. For example, when you first load the game, vehicles that hover or float will see a massive upward burst as the downward force is not apparently being applied. This is stock, not just my work.
Second, the PhysX implementation does not accurately process gravitational force. The correct formula is mass * gravitational acceleration which in Torque has always been -20.0. In an accurate model, if you apply an opposite upward force to a object it should hover in air. In Bullet, this is very true and works as it should, in PhysX your object will continue to rise meaning gravitational force is not being accurately applied. This simple fact alone makes proper calculations for buoyancy and hover pointless as your object will always be forced past your ideal height and the object will have to be adjusted again through force and damping. This gives an object that won't hover or float calmly, but rather bounces a lot.
Additionally, PhysX only clears once per cycle, this means that if you want to say integrate at 5 processes per time cycle, the forces will not behave in a stable manner. Bullet on the other hand loves this kind of thing.
Finally, PhysX overrides Torque by forcing the angular momentum rather than making angular force adjustments like Bullet does. This gives steering objects like hovercraft, water vehicles and flying vehicles more stability but a total lack of realism as the vehicle never over steers.
I've worked around the last two to make the system more stable and playable. However, the first two problems are quickly becoming deal breakers as I'm not seeing what was wrong in the implementation to cause this and am beginning to believe that PhysX is just not good enough.
The bottom line is, I have to either figure out what causes the first two problems, or scrap making a PhysX version.
I've gotten hover physics, flight physics and buoyancy all working, and they are very stable even in multiplayer, except in PhysX. First is the core problem, PhysX in Torque 3D does not process gravity properly during any sort of load. For example, when you first load the game, vehicles that hover or float will see a massive upward burst as the downward force is not apparently being applied. This is stock, not just my work.
Second, the PhysX implementation does not accurately process gravitational force. The correct formula is mass * gravitational acceleration which in Torque has always been -20.0. In an accurate model, if you apply an opposite upward force to a object it should hover in air. In Bullet, this is very true and works as it should, in PhysX your object will continue to rise meaning gravitational force is not being accurately applied. This simple fact alone makes proper calculations for buoyancy and hover pointless as your object will always be forced past your ideal height and the object will have to be adjusted again through force and damping. This gives an object that won't hover or float calmly, but rather bounces a lot.
Additionally, PhysX only clears once per cycle, this means that if you want to say integrate at 5 processes per time cycle, the forces will not behave in a stable manner. Bullet on the other hand loves this kind of thing.
Finally, PhysX overrides Torque by forcing the angular momentum rather than making angular force adjustments like Bullet does. This gives steering objects like hovercraft, water vehicles and flying vehicles more stability but a total lack of realism as the vehicle never over steers.
I've worked around the last two to make the system more stable and playable. However, the first two problems are quickly becoming deal breakers as I'm not seeing what was wrong in the implementation to cause this and am beginning to believe that PhysX is just not good enough.
The bottom line is, I have to either figure out what causes the first two problems, or scrap making a PhysX version.
#2
I'm still digging, I've seen other posts in the forums in regards to PhysX and the buoyancy code provided. They have seen these issues in those cases as well and that has been for over two years now from what I read. So I'm going to look some more, but in the end, for my own projects, I usually use Bullet anyway. True open source, easy to use and no need to install anything else for the players to play your game are huge selling points for me.
11/27/2012 (9:04 pm)
@Jimmy - I already figure it must be the implementation in T3D as like you said, it has been done before in other games. I'm only using a port that is one or two versions older than the most current as it was the only version compatible with the Torque 3D implementation.I'm still digging, I've seen other posts in the forums in regards to PhysX and the buoyancy code provided. They have seen these issues in those cases as well and that has been for over two years now from what I read. So I'm going to look some more, but in the end, for my own projects, I usually use Bullet anyway. True open source, easy to use and no need to install anything else for the players to play your game are huge selling points for me.
#3
Can Bullet shift its processing load to OpenCL devices? If it can then there is no reason that I can tell to even use PhysX. OpenCL is really not that difficult to use so maybe parts of Bullet could make use of it if it does not already. I also don't like the NVidia PhysX license either. Too much of their fingers in the IP for released games for me.
11/27/2012 (9:31 pm)
@Ronald,Can Bullet shift its processing load to OpenCL devices? If it can then there is no reason that I can tell to even use PhysX. OpenCL is really not that difficult to use so maybe parts of Bullet could make use of it if it does not already. I also don't like the NVidia PhysX license either. Too much of their fingers in the IP for released games for me.
#4
11/27/2012 (10:57 pm)
While I've not worked with the OpenCL code directly, it is definitely there. So I would have to say that it does support it. 
#5
11/27/2012 (11:43 pm)
Pretty sure PhysX uses CUDA, not OpenCL. It is NVIDIA, after all! Anyway, it's great to hear you're still working on this. Can't wait to see some more results! 
#6
11/28/2012 (1:47 am)
Looking forward to your progress Ron - More vehicles that work in Torque 3D and with PhysX / Bullet are needed. It would be awesome if there was a car GUI interface that enabled the import of wheels, car body and other car parts to create the vehicle in script (resize and position them), export and away you go.
#7
The reason I mention OpenCL is because it is a high performance GPU/CPU library. One of the attractive features of PhysX is the usage of a high performance GPU library called CUDA. If Bullet is using or can be made to use OpenCL then there really is no more reason to use PhysX than there is to use Bullet. This being due to both physics libraries having that high performance feature.
11/28/2012 (8:19 am)
@dB,The reason I mention OpenCL is because it is a high performance GPU/CPU library. One of the attractive features of PhysX is the usage of a high performance GPU library called CUDA. If Bullet is using or can be made to use OpenCL then there really is no more reason to use PhysX than there is to use Bullet. This being due to both physics libraries having that high performance feature.
#8
"Bullet 2.80 includes a preview of the GPU rigid body pipeline by Takahiro Harada, running 100% on the GPU using OpenCL. You can check out the Youtube videos or slides and precompiled binaries.
A new AMD Radeon 7970 Tahiti can simulate 110k objects in real-time between 15-30 frames/second. It also works on recent NVIDIA GPUs with latest drivers."
http://bulletphysics.org/wordpress/?p=340
11/28/2012 (1:04 pm)
Hm, interesting:"Bullet 2.80 includes a preview of the GPU rigid body pipeline by Takahiro Harada, running 100% on the GPU using OpenCL. You can check out the Youtube videos or slides and precompiled binaries.
A new AMD Radeon 7970 Tahiti can simulate 110k objects in real-time between 15-30 frames/second. It also works on recent NVIDIA GPUs with latest drivers."
http://bulletphysics.org/wordpress/?p=340
#9
11/28/2012 (1:10 pm)
I'd pay for a proper, full, easy to install, physics integration (bullet, phsyx, whatever), might be a good idea to make it into a pack? 
#10
11/28/2012 (1:14 pm)
@ Chris SOLD lol I always thought that OpenCL didn't work for any Nvidia cards as OpenCL is an ATI initiative to get more support for the Bullet physics engine.
#11
OpenCL calls CUDA for NVidia devices. I thought about mentioning that, but I figured people knew that. Also, if you want to use Intel or AMD processors with OpenCL you must install a driver/library. I installed the AMD one so that I can run OpenCL on my 8 core processor. The AMD library will work with ANY processor with new enough instruction set. I believe they need the SSE3 instruction.
11/28/2012 (1:36 pm)
@Jimmy,OpenCL calls CUDA for NVidia devices. I thought about mentioning that, but I figured people knew that. Also, if you want to use Intel or AMD processors with OpenCL you must install a driver/library. I installed the AMD one so that I can run OpenCL on my 8 core processor. The AMD library will work with ANY processor with new enough instruction set. I believe they need the SSE3 instruction.
#12
11/28/2012 (1:45 pm)
Nice my infromation is out of date. Last time I even looked at bullet was what 3 or 4 years ago. 
#13
11/28/2012 (1:47 pm)
Not much was ever made of it but the Community Edition uses Bullet + OpenCL exclusively in it's physics implementation. Performance comparisons caused us to pretty much ignore PhysX altogether.
#14
Woah, I did not know that. Sounds like I need to pay more attention to the CE. Lately I have been working with the MIT version.
11/28/2012 (2:07 pm)
@Michael,Woah, I did not know that. Sounds like I need to pay more attention to the CE. Lately I have been working with the MIT version.
#15
11/28/2012 (6:02 pm)
Frank: understood, I thought you were implying that PhysX could use OpenCL. Re-reading, I can see I misread you! 
#16
One, ATI doesn't exist anymore, it's just AMD ;) They're phasing out the name ATI completely
Two, OpenCL is a Khronos group initiative (under license from Apple) the non profit organisation that governs the development and sets the standards of the various Open media standards (OpenGL, OpenGL ES, WebGL, OpenCL, etc.).
It's just an open standard, like OpenGL, ,to do scientific computations on a GPU, or even on multi core cpus, or even on distributed systems. It's not a physics thing per se.
OpenCL @ Khronos
07/28/2013 (2:52 pm)
Quote:@ Chris SOLD lol I always thought that OpenCL didn't work for any Nvidia cards as OpenCL is an ATI initiative to get more support for the Bullet physics engine.
One, ATI doesn't exist anymore, it's just AMD ;) They're phasing out the name ATI completely
Two, OpenCL is a Khronos group initiative (under license from Apple) the non profit organisation that governs the development and sets the standards of the various Open media standards (OpenGL, OpenGL ES, WebGL, OpenCL, etc.).
It's just an open standard, like OpenGL, ,to do scientific computations on a GPU, or even on multi core cpus, or even on distributed systems. It's not a physics thing per se.
OpenCL @ Khronos
Jimmy R Armes