Created attachment 35687 [details] python opengl test python/opengl/pygame Hi, We have a bug report in blender3d on linux which reports a drawing problem with both Intel and ATI graphics cards (32 and 64bit x86 - linux). I didn't get the problem with me nvidia driver so I compiled the latest mesa (7.8.1) and ran blender with Mesa's software libGL.so LD_PRELOAD'd to redo the bug. I made a simple example of this bug in python (depends on pygame and pyopengl) to show how this bug happens in an isolated testcase. See attached, will attach an image of the bug next.
Created attachment 35688 [details] Image displaying the bug.
Note that this bug happens in Blender3d and in a very simple testcase so its (C and Python application), so its very unlikely the bug is in either PyOpenGL or Blender.
Here is the report in blenders bug tracker: http://projects.blender.org/tracker/index.php?func=detail&aid=22346
Created attachment 35692 [details] C program which demonstrates bug Maybe C program would be useful for debugging.
The GL_LINE_LOOPs around the 5461st and 10921st vertex are closed prematurely after the aforementioned vertices. You can change all other GL_LINE_LOOPS to GL_LINE_STRIPS without changing the extra lines(Obviously, you will be missing some closing lines). Moving the 5461st and 10921st vertex and the first ones of the given LOOP around confirms that the extra lines is between these vertices. Looks like the vertices are collected before drawing and then the primitives are incorrectly split leaving at least one GL_LINE_LOOP where there should be two GL_LINE_STRIPS. I could not find the code responsible for this.
Created attachment 35695 [details] python opengl test python/opengl/pygame (Switching states) Hi, I added a modified version of the python test case. It switches between 3 states. 0: draw the first part of the shape 1: draw the second part of the shape 2: draw both parts. You can see that only when both parts are drawn the bug is visible. therefor I think the bug is not in the use of glBegin(GL_LINE_LOOP);
Created attachment 35697 [details] Fixed version of C program Pardon, previous archive was incorrect (i've used GL_LINE_STRIP instead of GL_LINE_LOOP for investigation and there was no atrifacts, but there should be GL_LINE_LOOP).
My investigation till now : Because the test code call twice the glBegin(GL_LINE_LOOP);glVertex3fv(); glEnd() and then glFlush() if we add an intermediary glFlush() between those sequential call then the bug is fixed. Seems a trouble with last status of glBegin(GL_LINE_LOOP) after the same call, in case not flushing was done.
(In reply to marius predut from comment #8) > My investigation till now : > Because the test code call twice the > glBegin(GL_LINE_LOOP);glVertex3fv(); glEnd() and then glFlush() > if we add an intermediary glFlush() between those sequential call then the > bug > is fixed. > Seems a trouble with last status of glBegin(GL_LINE_LOOP) after the same > call, in case not flushing was done. Pretty sure this is more or less coincidence, since in this example a single loop fits into the max size of some buffer before it will be flushed internally. Make it bigger and it will still fail. (Also see https://bugs.freedesktop.org/show_bug.cgi?id=81174 for a related bug and some mroe explanation).
Please keep the QA contact as mesa-dev, so that we can receive all messages.
This is the same as bug 81174. I've documented the root issue and fix there. *** This bug has been marked as a duplicate of bug 81174 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.