def _set_raster_pos(x, y): # staticmethod
"""
"""
# If x or y is exactly 0, then numerical roundoff errors can make the raster position invalid.
# Using 0.1 instead apparently fixes it, and causes no noticable image quality effect.
# (Presumably they get rounded to integer window positions after the view volume clipping,
# though some effects I saw implied that they don't get rounded, so maybe 0.1 is close enough to 0.0.)
# This only matters when GLPane size is 100x100 or less,
# or when drawing this in lower left corner for debugging,
# so we don't have to worry about whether it's perfect.
# (The known perfect fix is to initialize both matrices, but we don't want to bother,
# or to worry about exceeding the projection matrix stack depth.)
x1 = max(x, 0.1)
y1 = max(y, 0.1)
depth = 0.1 # this should not matter, as long as it's within the viewing volume
x1, y1, z1 = gluUnProject(x1, y1, depth)
glRasterPos3f(
x1, y1, z1
) # z1 does matter (when in perspective view), since this is a 3d position
# Note: using glWindowPos would be simpler and better, but it's not defined
# by the PyOpenGL I'm using. [bruce iMac G5 070626]
### UPDATE [bruce 081203]: glWindowPos2i *is* defined, at least on my newer Mac.
# There are lots of variants, all suffix-typed with [23][dfis]{,v}.
# I need to check whether it's defined on the older Macs too, then use it here. ####FIX
if not glGetBooleanv(GL_CURRENT_RASTER_POSITION_VALID):
# This was happening when we used x, y = exact 0,
# and was causing the image to not get drawn sometimes (when mousewheel zoom was used).
# It can still happen for extreme values of mousewheel zoom (close to the ones
# which cause OpenGL exceptions), mostly only when pos = (0, 0) but not entirely.
# Sometimes the actual drawing positions can get messed up then, too.
# This doesn't matter much, but indicates that re-initing the matrices would be
# a better solution if we could be sure the projection stack depth was sufficient
# (or if we reset the standard projection when done, rather than using push/pop).
print "bug: not glGetBooleanv(GL_CURRENT_RASTER_POSITION_VALID); pos =", x, y
# if this happens, the subsequent effect is that glDrawPixels draws nothing
else:
# verify correct raster position
px, py, pz, pw = glGetFloatv(GL_CURRENT_RASTER_POSITION)
if not (0 <= px - x < 0.4) and (0 <= py - y <
0.4): # change to -0.4 < px - x ??
print "LIKELY BUG: glGetFloatv(GL_CURRENT_RASTER_POSITION) = %s" % [
px, py, pz, pw
]
# seems to be in window coord space, but with float values,
# roughly [0.1, 0.1, 0.1, 1.0] but depends on viewpoint, error about 10**-5
pass
return
def _set_raster_pos(x, y): # staticmethod
"""
"""
# If x or y is exactly 0, then numerical roundoff errors can make the raster position invalid.
# Using 0.1 instead apparently fixes it, and causes no noticable image quality effect.
# (Presumably they get rounded to integer window positions after the view volume clipping,
# though some effects I saw implied that they don't get rounded, so maybe 0.1 is close enough to 0.0.)
# This only matters when GLPane size is 100x100 or less,
# or when drawing this in lower left corner for debugging,
# so we don't have to worry about whether it's perfect.
# (The known perfect fix is to initialize both matrices, but we don't want to bother,
# or to worry about exceeding the projection matrix stack depth.)
x1 = max(x, 0.1)
y1 = max(y, 0.1)
depth = 0.1 # this should not matter, as long as it's within the viewing volume
x1, y1, z1 = gluUnProject(x1, y1, depth)
glRasterPos3f(x1, y1, z1) # z1 does matter (when in perspective view), since this is a 3d position
# Note: using glWindowPos would be simpler and better, but it's not defined
# by the PyOpenGL I'm using. [bruce iMac G5 070626]
### UPDATE [bruce 081203]: glWindowPos2i *is* defined, at least on my newer Mac.
# There are lots of variants, all suffix-typed with [23][dfis]{,v}.
# I need to check whether it's defined on the older Macs too, then use it here. ####FIX
if not glGetBooleanv(GL_CURRENT_RASTER_POSITION_VALID):
# This was happening when we used x, y = exact 0,
# and was causing the image to not get drawn sometimes (when mousewheel zoom was used).
# It can still happen for extreme values of mousewheel zoom (close to the ones
# which cause OpenGL exceptions), mostly only when pos = (0, 0) but not entirely.
# Sometimes the actual drawing positions can get messed up then, too.
# This doesn't matter much, but indicates that re-initing the matrices would be
# a better solution if we could be sure the projection stack depth was sufficient
# (or if we reset the standard projection when done, rather than using push/pop).
print "bug: not glGetBooleanv(GL_CURRENT_RASTER_POSITION_VALID); pos =", x, y
# if this happens, the subsequent effect is that glDrawPixels draws nothing
else:
# verify correct raster position
px, py, pz, pw = glGetFloatv(GL_CURRENT_RASTER_POSITION)
if not (0 <= px - x < 0.4) and (0 <= py - y < 0.4): # change to -0.4 < px - x ??
print "LIKELY BUG: glGetFloatv(GL_CURRENT_RASTER_POSITION) = %s" % [px, py, pz, pw]
# seems to be in window coord space, but with float values,
# roughly [0.1, 0.1, 0.1, 1.0] but depends on viewpoint, error about 10**-5
pass
return
def display_screen(self):
glDisable(GL_LIGHTING)
glColor3f(1, 1, 1)
# Projection
glMatrixMode(GL_PROJECTION)
glLoadIdentity()
gluPerspective (self.fov,float(self.width)/float(self.height),self.clippingplanes[0],self.clippingplanes[1])
# Initialize ModelView matrix
glMatrixMode(GL_MODELVIEW)
glLoadIdentity()
# View transformation
mat = se3.homogeneous(self.camera.matrix())
cols = zip(*mat)
pack = sum((list(c) for c in cols),[])
glMultMatrixf(pack)
labels = dict([ (k, T[1]) for (k, T) in vantage_point_xforms.items() ])
for (k, v) in labels.items():
try:
labels[k] = gluProject(*v)
except:
labels[k] = None
glMatrixMode(GL_PROJECTION)
glLoadIdentity()
glOrtho(0,self.width,self.height,0,-1,1);
glMatrixMode(GL_MODELVIEW)
glLoadIdentity()
for (s, p) in labels.items():
if p:
glRasterPos3f(p[0], self.height - p[1], p[2])
gldraw.glutBitmapString(GLUT_BITMAP_HELVETICA_12, s)