0

I do apologize, as it seems this sort of question has been answered in degree in other posts, but I haven't yet found the sort of answer I need.

My intent is, as many other users of openGL, to create a simple 3D environment, and despite my usage of various resources, I seem to be stuck on one of the most essential components, navigation... Though I have seen many uses of gluLookAt() to navigate the scene, it seems rather inefficient to compute a "facing" point, as well as "up" point, via three angles, when those angles are ultimately recomputed for transformation by openGL. (Though this sort of thing seems very useful for orbiting an object)

I have seen however another seemingly more practical method that applies a series of operations like such (in pythonic fashion)

def goto(x,y,z,pitch,yaw,roll):
    glLoadIdentity()
    glRotatef(pitch,1,0,0)
    glRotatef(yaw,0,1,0)
    glRotatef(roll,0,0,1)
    glTranslatef(-x,-y,-z)

But upon trying this method, I have found that not only does (to my limited understanding) zFar cut off most of the rendered objects, but z coordinates act dysfunctional or are altogether ignored. Further, it seems that rotation still occurs about the origin, rather than the camera.

If in case the error lies in the entirety of my program it can be found here (https://www.dropbox.com/s/5ysn5jgzgci17vm/faulty_program.py?dl=0), but the central functionality is as follows:

gluPerspective(45, 1, 0.1, 50.0)

def sin(x): return math.sin(math.radians(x))

def cos(x): return math.cos(math.radians(x))

def drawTriangle():
    glBegin(GL_TRIANGLES)
    glVertex3f(0,0,0)
    glVertex3f(0,1,0)
    glVertex3f(1,0,0)
    glEnd()

def goto(x,y,z,pitch,yaw,roll):
    glLoadIdentity()
    glRotatef(pitch,1,0,0)
    glRotatef(yaw,0,1,0)
    glRotatef(roll,0,0,1)
    glTranslatef(-x,-y,-z)

x=0
y=0
z=5
pitch=0
yaw=0
roll=0

while True:
    glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT)

    pygame.event.get()

    if pygame.key.get_pressed()[pygame.K_w]:
        z+=.1
    elif pygame.key.get_pressed()[pygame.K_s]:
        z-=.1
    elif pygame.key.get_pressed()[pygame.K_a]:
        x+=.1
    elif pygame.key.get_pressed()[pygame.K_d]:
        x-=.1

    if pygame.key.get_pressed()[pygame.K_UP]:
        yaw+=1
    elif pygame.key.get_pressed()[pygame.K_DOWN]:
        yaw-=1
    elif pygame.key.get_pressed()[pygame.K_LEFT]:
        pitch+=1
    elif pygame.key.get_pressed()[pygame.K_RIGHT]:
        pitch-=1

    goto(x,y,z,pitch,yaw,roll)
    drawTriangle()

    pygame.display.flip()
    pygame.time.wait(20)
    os.system("cls")

I guess, more than anything, I am asking for the correct means of this operation, as I clearly have no idea what I am doing...

  • 1
    You shall use `glMatrixMode(GL_MODELVIEW)` in `goto` and `glMatrixMode(GL_PROJECTION)` before `gluPerspective`. – Yakov Galka Dec 13 '16 at 16:10
  • That may not yet be the total end of my problems, but it seems in a single sentence, you have saved me a great deal of agony... –  Dec 13 '16 at 16:20
  • 1
    What will save you even more agony (long term; it'll probably cause some agony short-term....) is to stop using Legacy OpenGL functions and learn proper [Modern OpenGL](http://www.learnopengl.com/#!Introduction). It's written with C++ in mind, but all the concepts translate 1:1 to Python. – Xirema Dec 13 '16 at 17:53
  • Also, rotating by pitch, yaw, and roll axes (i.e. euler angles) results in **gimbal lock**. This basically means that when you rotate one of your axes to match one of the other two axes, you lose a degree of motion. You might want to take a look at [this video](https://www.youtube.com/watch?v=zc8b2Jo7mno) to help visualize gimbal lock. `gluLookAt` gets around this by using an **axis-angle** representation, where you are rotating around an arbitrary axis instead. People often represent these axis-angle rotations using **quaternions**, but it can be tricky to understand those! – CodeSurgeon Dec 17 '16 at 01:31

0 Answers0