I am working on an implementation of a water droplet simulator that takes a mesh from 3d studio and creates x amount of particles to run over that surface. This side of the project is working well in openGL.
For the rendering side, I had hoped to set up an array of uniform variables holding the position, texture coordinate, and velocity of the droplets, which I then could update with my particle calculations. Then, per fragment, I was going to basically check to see where I am in relation to all of the droplets, and modify myself accordingly, so make me more specular, apply caustic/shadows, whatever.
I recognize a size limit to what one could expect to pass from openGL, and am cycling a reasonable ,~100, droplets over and over. This seems to keep things in pretty good check, HOWEVER, even for the most trivial of for-loops, like
for int iLoop = 0; i < numParticls; i++
if myPosition.x - particle[iLoop].x
FinalColor = vec4 1.0,0.0,0.0,0.0;
I get ridiculous slow downs. So my question is, for loops of any size at all, which a relatively simple test, am I always going to be screwed speed wise?
Also, as another option, I am trying to let the vertex shader do a check of proximity, then make a basic assumption from that number, such that if one particular triangle has no vertices within a certain distance to a particular drop, then a varying variable will make for a quick reject of all the fragments in that face. But, as above, a simple test of that varying slows it down.
What should I be doing differently or looking to cut the fat?
Thanks for any help,
Al