Hello,
I see peculiar behavior on Intel builds when using glBufferSubData to update just the color data in a VBO. (This is on a Mac Pro with a GeForce 7300 GT. Disabling VBOs eliminates the artifacts, running the PowerPC build under Rosetta on the same machine or on a native PPC Macintosh eliminates the artifacts, as well.)
The model looks fine, so the vertex and normal data do not appear to be affected. When initially filling the VBO with the vertex, normal, and color data, everything appears fine. (The vertex and normals are interleaved, followed by the colors, which are 3 GL_FLOATs.) However, when changing the color with glBufferSubData, a section of the color at the end of the color data is not updated, and left whatever color was filled in the initial construction, and a section of the color at the beginning is shifted with (r,g,b) showing as (g,b,r). I double-checked the offset, size, and data being passed to glBufferSubData.
Anyone else see anything like this?
If I replace the glBufferSubData call and use glMapBuffer instead to update the color data, the problem disappears.
#if 0
glBufferSubDataARB(GL_ARRAY_BUFFER_ARB, colorOffset, colorSize, colorArray);
#else
GLubyte* dest = glMapBufferARB(GL_ARRAY_BUFFER_ARB, GL_WRITE_ONLY_ARB);
dest += colorOffset;
for (int i = 0; i < fNumVertices; i++) {
*(ColorArrayElement*)dest = colorArray[i];
dest += sizeof(ColorArrayElement);
}
GLboolean success = glUnmapBufferARB(GL_ARRAY_BUFFER_ARB);
assert(success);
#endif
What should that tell me? I would have expected those calls to be equivalent, so I must be misunderstanding something. Does the glBufferSubDataARB require some additional synchronization? (Wrapping glBufferSubDataARB with glFlush or glFinish as a test did not eliminate the artifacts.)
The artifact is shown at
http://www.PacificT.com/glBufferSubDataArtifact/
The sphere was initially all red, correctly, then glBufferSubData was called to update the colors to all green. The top portion at the end of the buffer was not touched. The middle portion was updated correctly. The initial portion of the buffer was touched, but appears to be shifted.
Since using glMapBufferARB appears to work fine, is there any advantage to diagnosing and fixing the problem with glBufferSubDataARB? Would one expect glBufferSubDataARB to be faster? Asynchronous?
For more context on the surrounding code using the color array, see
<http://lists.apple.com/archives/mac-opengl/2004/Sep/msg00124.html>
(This new problem does not appear to be related to that one, which was resolved at the time, though it is in the same code.)
- Ron
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden
This email sent to email@hidden