Files
bullet3/Extras/GPUphysics/DEBUGGING_README

68 lines
2.4 KiB
Plaintext

I have added some command line options to hopefully
help with our debugging problems.
1) Run without any shaders at all:
GPU_physics_demo -s
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:
GPU_physics_demo -p
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:
GPU_physics -f
This sets the cubes off moving at constant speed (each cube
going at a different speed and spinning).
Run without collision against the ground:
GPU_physics -c
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.