Strange Artifact. Completely Stuck! Please Help!

If I had to guess, I'd say it looks depth-buffer/depth-testing related since it only occurs close to the camera. I'd try playing around with depth parameters. Have you tried disabling depth-testing entirely to see what happens? It's not going to fix it but it might shed some light on what's going on.

Well I did have it set as follows

glEnable(GL_DEPTH_TEST);
glDepthFunc(GL_ALWAYS);
glDepthMask(GL_TRUE);
glBlendFunc (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
glEnable(GL_BLEND);

Because I had it depth sorted before render and I had previously been using depth data for depth of field calculations. It probably would be a good idea to just disable it all together when not needed. Any additional ideas?

By the looks of it you could move the near clip plane forward slightly to cure this. Ex. if you have 0.1 then try 0.2

Tried moving the clipping plane around. Didn't have any effect. Good idea though. One thing which is especially strange, if you step through the video frame by frame, you can see the glitch stays in the exact same position on multiple frames which points to something a little bit stranger than just the clipping plane.

Doesn't look like a clipping artifact at all to me. It looks like this particle suddenly gets its transform or projection matrix messed up.

You say you use 'manual' billboard techniques. What exactly do you mean by this ? Do you handle all corner cases correctly, especially those involving projection plane intersections ?

How do you detect/remove particles that quit the view frustum ? Are you sure you don't have a bug where a particle that went out of the frustum is still drawn with its last valid coordinates, yet not updated anymore ? That would entirely explain the effect.

Yann,
This sounds like you might be onto something. The reason which I had doubted this originally is that I never saw this on my PC, any other PC, or my MAC, but your right, its such a strange bug that this seems like it might be the only explination, although why would it react differently on my machine?

The basic billboarding technique used is as follows (Note that it is somewhat simplified but you'll get the idea)

float mat[16];

glGetFloatv( GL_MODELVIEW_MATRIX, mat );

vector3f vRight( mat[0], mat[4], mat[8] );
vector3f vUp( mat[1], mat[5], mat[9] );
vector3f vPoint0;
vector3f vPoint1;
vector3f vPoint2;
vector3f vPoint3;
vector3f vCenter;
vector3f rAxis = vector3f::crossProduct(vRight, vUp);

vPoint0 = vCenter + ((-vRight*tempASx - vUp*tempASy ));
vPoint1 = vCenter + (( vRight*tempASx - vUp*tempASy ));
vPoint2 = vCenter + (( vRight*tempASx + vUp*tempASy ));
vPoint3 = vCenter + ((-vRight*tempASx + vUp*tempASy ));

glVertex3f( vPoint0.x, vPoint0.y, vPoint0.z );
glVertex3f( vPoint1.x, vPoint1.y, vPoint1.z );
glVertex3f( vPoint2.x, vPoint2.y, vPoint2.z );
glVertex3f( vPoint3.x, vPoint3.y, vPoint3.z );

I hadn't even noticed that I didn't normalize the vectors. I haven't seen any side effects on my computer, however, if the OpenGL implementation on my Beta Tester (who's getting the bad result) computer is not as stable with the matrix, this could cause some issues. Any one else have any observations? I know my matrix algebra, but I don't the Model view matrix enough to think of any exception cases right off hand. Time to consult the red book. Any tips would be appreciated.

Quote:

Original post by DJHoltkamp Tried moving the clipping plane around. Didn't have any effect. Good idea though. One thing which is especially strange, if you step through the video frame by frame, you can see the glitch stays in the exact same position on multiple frames which points to something a little bit stranger than just the clipping plane.

Ah I didn't try the frame-step observation, just paused the video at the right spot.

Yann's explanation does sound worth exploring.
Apart from that, I've seen a similar (but different) side effect when using glPolygonOffset() at a near-plane intercept...I doubt you're using that here though, so sorry pass!

Upon review, I do not know if it would make sense to say that this error is coming from the bad billboarding. I am deriving the right and up vectors only once for all of the sprites seen. However, the error is only happening sometimes and it always happens to only the sprite nearest the screen. If the vector was wrong it should mess up all of the sprites for that frame. I find it strange also that the sprite always locks to the viewable screen when there is an error (Perhaps an Inf. or NaN condition?) Good idea with the Polygon_Offset by the way. I may explicitly disable it in case it is just a bug in the implementation which has it enabled by default. Any other ideas?

just a thought, since it does not happen on your machines, but others, is the hardware/OS the same on the other machines? if it happens depending on the machine, this might seem odd, it might be an uninitialised value somewhere; if you have the project running under Linux, you can try to use valgrind to help hunt down uses of uninitialised values, be warned though: when it is in use the application goes really, really slowly.

The only major difference is in the graphics card, so I am guessing that it is something I am doing in OpenGL that this particular implementation is not liking. I have spent a lot of time making sure that it was not a memory bufferflow of some type (perhaps the memory lines up differently on the two machines?) but have not found anything. Thanks for the idea though!

Still looking for a solution... Anybody else have any ideas to throw out there? In case it helps, the person who is debugging has an NVIDIA card.

Would it be something about the cross product?

In the code you post, there are some variables depend on cross product. Normally, you should get a non-zero vector from cross product. However, it will end up with a zero vector when you cross two parallel vectors. And, this exception can become a problem sometimes.