how can glFlush() affect rendering correctness?
Upon noticing that there were unexpected artefacts in other OpenGL programs, I did some digging and discovered that you can upgrade the OpenGL stack on Ubuntu: https://launchpad.net/~xorg-edgers/+archive/ppa
After updating, all GL rendering was faster (my test programs below doubled in speed!) and without artefacts.
So to answer my own question: how can glFlush() affect rendering correctness? when the drivers are buggy.
=== original question ===
or, more correctly, what is the fundamental bug with my classic untrendy non-shader-VBO-stuff?
cdef struct xyz:
开发者_JAVA百科 float x, y, z
cdef inline void _normal(xyz b,xyz a):
glNormal3f(a.x-b.x,a.y-b.y,a.z-b.z)
cdef inline void _draw_quad(xyz a,xyz b,xyz c,xyz d):
glVertex3f(a.x,a.y,a.z)
glVertex3f(b.x,b.y,b.z)
glVertex3f(c.x,c.y,c.z)
glVertex3f(d.x,d.y,d.z)
cdef void _draw_grid(xyz a,xyz b,xyz c,xyz d):
glBegin(GL_LINE_LOOP)
_draw_quad(a,b,c,d)
glEnd()
.... # main loop goes through my data array issuing the appropriate functions
while self._buf.remaining() > 0:
op = self._buf.read_char()
if op == _COLOR:
col = self._buf.read_rgb()
#print col
glColor3f(col.r,col.g,col.b)
elif op in (_BOX,_GRID):
tl,tr,br,bl,trb,brb,tlb,blb = self._buf.read_xyz(),self._buf.read_xyz(),\
self._buf.read_xyz(),self._buf.read_xyz(),\
self._buf.read_xyz(),self._buf.read_xyz(),\
self._buf.read_xyz(),self._buf.read_xyz()
if op == _BOX:
#print "box",col
glBegin(GL_QUADS)
func = _draw_quad
else:
#print "grid",col
func = _draw_grid
_normal(tlb,tl)
func(tl,tr,br,bl)
_normal(tl,tr)
func(tr,trb,brb,br)
_normal(tr,tl)
func(tl,tlb,blb,bl)
_normal(tr,tl)
func(tl,tlb,trb,tr)
_normal(tl,tr)
func(bl,blb,brb,br)
_normal(tl,tlb)
func(tlb,trb,brb,blb)
if op == _BOX:
glEnd()
#glFlush()
else:
raise Exception("corrupt serialisation; got %x"%op)
if flush after each cube or wireframe, I get this CORRECT rendering:
if I omit the flush - and I obviously don't want to be flushing, even if I am not treading the most optimal opengl path - then I get this INCORRECT rendering, and this is the bug I don't understand:
For the curious, here is how glutSolidCube
and wires do it: http://www.google.com/codesearch/p?hl=en#xbii4fg5bFw/trunk/FDS/trunk/SMV_5/source/glut-3.7.6/glut_shapes.c&q=glutSolidCube%20lang:c&sa=N&cd=4&ct=rc
I can't say precisely why not calling glFlush()
causes undesired results, but you may want to take a look at a question about the difference between glFlush ad glFinish I asked some time ago. It may have some useful info.
As for solutions, perhaps try putting a glFlush()
after you're done rendering the entire scene, as opposed to each cube.
the glBegin / glEnd calls in the code sample are not property matched, and in some cases they are overlapping. glFlush will effectively force a glEnd, so that is the difference. I suspect the rendered output would be the same if you simply replaced glFlush with glEnd.
For example, this is one way to fix your code:
cdef struct xyz:
float x, y, z
cdef inline void _normal(xyz b,xyz a):
glNormal3f(a.x-b.x,a.y-b.y,a.z-b.z)
cdef inline void _draw_quad(xyz a,xyz b,xyz c,xyz d):
glVertex3f(a.x,a.y,a.z)
glVertex3f(b.x,b.y,b.z)
glVertex3f(c.x,c.y,c.z)
glVertex3f(d.x,d.y,d.z)
cdef void _draw_grid(xyz a,xyz b,xyz c,xyz d):
_draw_quad(a,b,c,d)
.... # main loop goes through my data array issuing the appropriate functions
while self._buf.remaining() > 0:
op = self._buf.read_char()
if op == _COLOR:
col = self._buf.read_rgb()
#print col
glColor3f(col.r,col.g,col.b)
elif op in (_BOX,_GRID):
tl,tr,br,bl,trb,brb,tlb,blb = self._buf.read_xyz(),self._buf.read_xyz(),\
self._buf.read_xyz(),self._buf.read_xyz(),\
self._buf.read_xyz(),self._buf.read_xyz(),\
self._buf.read_xyz(),self._buf.read_xyz()
if op == _BOX:
#print "box",col
glBegin(GL_QUADS)
func = _draw_quad
else:
#print "grid",col
glBegin(GL_LINE_LOOP)
func = _draw_grid
_normal(tlb,tl)
func(tl,tr,br,bl)
_normal(tl,tr)
func(tr,trb,brb,br)
_normal(tr,tl)
func(tl,tlb,blb,bl)
_normal(tr,tl)
func(tl,tlb,trb,tr)
_normal(tl,tr)
func(bl,blb,brb,br)
_normal(tl,tlb)
func(tlb,trb,brb,blb)
glEnd()
#glFlush()
else:
raise Exception("corrupt serialisation; got %x"%op)
精彩评论