I’m new to these forums, and relatively new to GLSL, although I’ve implemented a couple of basic shaders.
I’m working on a 2D game which focuses mostly around fluid physics (specifically a variation of Smoothed Particle Hydrodynamics, as described in this paper). For the purposes of this discussion, the specific details of the fluid simulation isn’t important, but these points might be:
- The simulation involves particles, which could potentially be modelled as vertex information.
- Each particle needs to know about the particles which are close to it in order to work out what to do next.
- I need to have some representation of the particle positions available on the CPU in order to resolve the interactions between the fluid particles and the solid objects in my physics engine.
So, what I want to do is to have a bunch of information about each particle stored somewhere accessible from my main program (be that in RAM or as a Vertex Buffer Object or something similar on the GPU), but have the ability to hand off the actual fluid physics calculations off to some processor other than the CPU. In other words, I want to handle some of my physics and other game logic in my main program, but get the graphics card to handle most of the fluid physics. So something like (pseudocode):
for(each particle) DoInteractionsWithWorld(); // This updates particle positions if they intersect with solid objects in the physics engine
RenderParticles(); // Before rendering the particles, this invokes a GLSL shader which updates their positions according to the fluid sim.
GetNewParticlePositions(); // This retrieves the results of RenderParticles, so I have the new particle positions to interact with the world in the next timestep.
Is this sort of thing possible with GLSL? Is it sensible? Or is it folly to try to write a vertex shader which has an awareness of other vertices, and which can return the results of its processing t0 the CPU?