I've added some debugging options into the GPU physics demo program. You can download it from:
* Merged in your MacOSX support.
* Added a ton of command-line debug options (see DEBUGGING_README)
* Changed to ZLib license.
My hope is that by running it with the various command line options, we can narrow the problem down to just one of the 'exotic' features that the program uses.
1) Run without any shaders at all:
This should produce a grey screen with a neat grid of randomly coloured cubes that are sitting completely motionless. If this doesn't work then render-to-texture and shaders are not the problem and we have some very basic OpenGL problem to worry about.
2) Run with just one shader - but no render-to-texture:
Just like '-s', this should produce a grey screen with a neat grid of randomly coloured cubes that are sitting completely motionless. This time, the vertex shader is reading the positioning information from a texturemap. If this doesn't work then render-to-texture isn't the problem but something is amiss in shader-land.
There are several possibilities - the nastiest of which might be that either:
a) Your graphics card/driver doesn't support floating point textures. (This is pretty much 'Game Over' for you because without that, doing physics in the GPU is going to be virtually impossible).
b) Your graphics card/driver doesn't support vertex shader textures (or it supports them but sets the maximum number to zero - which is the same thing). This means that we can't move things around using GPU textures - but we can still use the GPU to accellerate physics calculations. In practical game scenarios, I think the CPU needs to know where all the objects are - so this may not be the serious issue it sounds like. What it mostly does is to clobber the idea of running physics on particle system types of effect where a vast number of objects are involved but where individual objects have zero effect on game play.
3) Run without forces being applied:
This sets the cubes off moving at constant speed (each cube going at a different speed and spinning).
4) Run without collision against the ground:
The cubes move under gravity - but don't interact with the notional ground plane so the eventually fall off the bottom of the screen..
If either (3) or (4) fails but (1) and (2) worked then the problem is probably something to do with render-to-texture.
This is the most likely scenario and it is a pain - but fixable.
5) Run with everything:
...exactly as per my previous releases (ie everything is enabled).