• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

JoryRFerrell

Members
  • Content count

    16
  • Joined

  • Last visited

Community Reputation

143 Neutral

About JoryRFerrell

  • Rank
    Member
  1.   Well.....EMBARASSING. I overlooked how the texture coords are stored in obj file. I expected coords to be in .mtl file, not .obj. NEEEEEVEEEEEEERMIND.
  2. I need to know of some formats which export texture maps so I can simply parse that and avoid having to hand map a texture to my models. I tried figuring out how .mtl files store their texture mapping. However, they just seem to reference the texture rather than recording the actual mapping. Any suggestions?
  3. I figured out a method and posted a vid on it:   http://youtu.be/wwMD2UX0rQ4
  4. Yea, I already know about cross-product method. I have made one, but Newell's Method is more accurate.   Like I was saying, my method grabs all neighboring verts, and forms a projected face from them on each axis. For each created face, I find the normal of the face via the cross product method. Then with all those calculated face normals, I take the average and I end up with the more accurate per-vertex normal. My problem was correctly finding the neighbor vertices in a consistent clockwise/counter-clockwise order. They often get reversed with my current algorithm. But, if I could find a way to correctly determine the order of the verts after finding them, I could simply reverse the per-vertex normal whenever it was facing the wrong direction. However I found a way to ensure the normal is facing the correct direction no matter what, and I don't need to determine the handedness of the neighbor verts order to do it. Look at explanation below.
  5.   I do the same thing with pen and paper. There is something different about HOLDING a set of physical objects and solving the problem with them, that seems to make problems less complex. Makes sense considering how the brain works I guess.
  6.   I have the same problem. You need to study everything as a building block. You have a phd in physics so that shouldn't be hard. :P Pretend you are playing with lego's. The entire structure can be complicated as a whole, but broken down, it's pretty simple. In fact, once broken down to the individual blocks, the mechanics behind the build are pretty intuitive. Unfortunately the building blocks of programming languages are not as simple as lego's, but once you start learning to keep looking at the basic blocks, you start to intuitively get a better grasp of whats efficient and what isn't. It's easier said than done, but this IS the way to view it. Start by learning the  basic types and the general do's/do not's on how to use them. Then use those blocks to build a small, tightly packed (i.e. efficient) larger lego structure. Now that you have that efficient block put together, you can stop looking at the underlying specifics behind it every time you need that function, and use it to build and even larger lego structure made up of other tightly packed, pre-structured code. Now again, easier said than done. I have  learned that you will eventually hit parts of code where it seems so abstract and non-straight forward, like a dot product can be, that it's hard to find an efficient way to string  together blocks into an efficient struct. It's the same in physics. It's easy to calculate gravitational effects on a baseball thrown in an arc on earth. It's not so simple to calculate the effects on a baseball thrown into a binary-blackhole system. :P Sometimes you'll just run into problems that seem so abstract and removed from a certain paradigm you are use to working on, that it will just be a mother*******. :P But remember:   KISS.   Keep. It. Simple. Stupid.   I constantly have to remind myself of that. I'm extremely tired, and still, I have to retrain myself to break things down like this no matter how tired or discouraged I am. Once you train  to the point that you start noticing that programming certain types of problems efficiently becomes intuitive, you'll be more motivated and actually possibly come to enjoy sifting through some forum posts, which were seemingly inane previously, on how to improve this algorithm or that. Patience is a big factor. I am no where near expert, but I have noticed the more time I invest in the basics instead of trying to skip ahead and make something, the more I just naturally understand. Having a high level degree, you have already experienced the kind of pace you need to think at when programming. It's long term, methodical work. And as usual, it's best to not try to cram overnight before the big exam. No one writes a Far Cry 3/Battlefield 3 overnight, especially not as a loner, fly-by-night programmer. The more methodical and slow your approach at programming in the beginning, the faster you will actually begin writing better code. Also, don't forget to do back-research. You should have some understanding of different os platforms since each handle windowed apps differently (unless you use scripted languages which are often able to handle much of the thinking there for you). You also need knowledge of your individual compiler, and os file system/path requirements.This is currently annoying the hell out of me. I have been fooling around with python seriously for the past year, and I just started earnestly trying to learn C++. C++ requires all kinds of weird linked in file types and organization. The IDE/compiler alone feels more complex than any of the C++ programming concepts themselves.   But again, that's because I naturally slip back into viewing the IDE as a whole rather than it's simple pieces. KISS. Lordy KISS, KISS, KISS.   In short:   - Learn the general overview of the problems you need to solve. Then find out the basic starting points you need to start solving the smallest problems. You can't solve 3d rotation without trig, and you can't figure out trig without understanding basic arithmetic.   - Remember to break the whole problem into manageable pieces that you easily, and intuitively can solve. Those then combine with the other smaller pieces you have already solved.   - Keep reminding yourself to not throw yourself headlong into a brickwall trying to solve the problems immediately. It causes undue stress, making the problems even harder to solve. If you are apt to doing this out of your very nature as I am, I feel sorry for you because I know what you are in for. :P But again, keep working at it, while just taking up the additional task of purposefully, and intently, retraining yourself to break this habit and remind yourself of the mindset needed to solve the paradigm at hand.   Have fun. Once I get the initial roadblocks out of the way, I know I will be doing so.
  7. Yes. Objects are guaranteed to be closed (for now) and must account for both convex and concave geometry. Is their an algorithm which will do this for both with a single equation? Or would it require different equations/logic-branches for each?   Also, I want it to handle weird geometry with verts forming concave shapes which bow in past the objects local origin. Say you take a unit cube a split two opposite faces, along the z axis, into four faces each. then you take the center vertices of those four faces and translate them both -1.5 along the z axis. You'd have one vert which went inwards (forming a concave surface) past its own origin, so I can't rely on a vector from the origin to each vert, that compares with the generated normal to check the total angle between the two or something.
  8. <p>How do I determine if a the normal for a vertex has been created by ccw ordered verts or cw wound verts? I assign each vert's neighbors to a list in the order they wind around, but it doesn't assign them in a secific clockwise/ccw order consistently. I have just decided to calculate the normal then determine whether the verts are cw, or ccw, and then change the signs of the normal vector components accordingly.</p> <p>&nbsp;</p> <p>Some suggested using a secondary vector to compare the angle between the secondary and the generated normal. If greater than 90, or less than, that would tell me if the normal vector is facing the direction I need. But I don't think this works for concave (NOTE: I originally wrote &quot;CONVEX&quot;. I meant &quot;CONCAVE&quot;. :\) shapes (normals can face toward origin, allowing for angles less than 90 degrees when compared with a vector drawn from the origin of object.</p>
  9.   Bit late...but ty. I ended up getting the answer before you replied. TY for notes though, as you did help with a few issues.
  10. Also, as for the ground_1 object rendering weirdly....I screwed up the order of the verts. Instead of writing them in the order they appeared in the face, I simply wrote each verts in the order they appeared in list of all verts. The result was that the last 2 verts are actually supposed to be switched, but I failed to do so. So IT WAS rendering properly, just not how I expected it to. :P
  11.   Cool beans. You answered my question and you helped me a lot with the info on Push and Pop funcs. I had read about them but I didn't really pay attention. Patience is not my strong suit. :P As for calling rotation before translation, it wasn't intentional, but I didn't really care. I have read in the bookmthat provided a large part of this code, that you should rotate before translation because trans affects rotation, but for now, I was just worried about fooling around with rots. As for the diff between rotatef and rotated, I have noticed no I'll effect's in the program.   TY for your help!
  12. Why are my cubes randomly rotating near the end of their animation? Also, why is the flat, stationary plane drawing with one edge"bending" into the origin?   SCREEN_SIZE = (800, 600) import sys from math import radians from OpenGL.GL import * from OpenGL.GLU import * import pygame from pygame.locals import * from gameobjects.matrix44 import * from gameobjects.vector3 import * import random def resize(width, height): glViewport(0, 0, width, height) glMatrixMode(GL_PROJECTION) glLoadIdentity() gluPerspective(90.0, float(width)/height, 0.1, 10000.0) glMatrixMode(GL_MODELVIEW) glLoadIdentity() def init(): glEnable(GL_DEPTH_TEST) glShadeModel(GL_FLAT) glClearColor(1.0, 1.0, 1.0, 1.0) glEnable(GL_COLOR_MATERIAL) glEnable(GL_LIGHTING) glEnable(GL_LIGHT0) glLight(GL_LIGHT0, GL_POSITION, (10, 10, 10, 0)) class ground(object): def __init__(self): self.position = (0.0, 0.0, 0.0) self.color = tuple([random.uniform(0.0,1.5), random.uniform(0.0,1.5) , random.uniform(0.0,1.5)]) def render(self): glColor(0.0, 1.0, 1.0) glBegin(GL_QUADS) glNormal(0.0, 0.0, 1.0) glVertex3f(1.000000, 0.000000, 1.000000) glVertex3f(-1.000000, 0.000000, 1.000000) glVertex3f(1.000000, 0.000000, -1.000000) glVertex3f(-1.000000, 0.000000, -1.0000000) glEnd() class Cube_Projectile(object): def __init__(self, position): self.position = (0.0, 0.0, 0.0) self.color = tuple([random.uniform(0.0,1.0), random.uniform(0.0,1.0) , random.uniform(0.0,1.0)]) self.life = 1000 def render(self): if self.life > 0: glColor(self.color) # Adjust all the vertices so that the cube is at self.position # vertices = [tuple(Vector3(v) + self.position) for v in self.vertices] # Draw all 6 faces of the cube self.life -= 1 glTranslatef(self.position[0], self.position[1], self.position[2]) glRotate(30, 1, 1, 0) glBegin(GL_QUADS) glNormal3f(1.000000, 0.000000, 0.000000) glVertex3f(-2.000000, -2.000000, -2.000000) glVertex3f(-2.000000, -2.000000, 2.000000) glVertex3f(-2.000000, 2.000000, 2.000000) glVertex3f(-2.000000, 2.000000, -2.000000) glNormal3f(0.000000, 0.000000, 1.000000) glVertex3f(-2.000000, 2.000000, -2.000000) glVertex3f(2.000000, 2.000000, -2.000000) glVertex3f(2.000000, -2.000000, -2.000000) glVertex3f(-2.000000, -2.000000, -2.000000) glNormal3f(-1.000000, 0.000000, -0.000000) glVertex3f(2.000000, 2.000000, -2.000000) glVertex3f(2.000000, 2.000000, 2.000000) glVertex3f(2.000000, -2.000000, 2.000000) glVertex3f(2.000000, -2.000000, -2.000000) glNormal3f(0.000000, 0.000000, -1.000000) glVertex3f(-2.000000, -2.000000, 2.000000) glVertex3f(2.000000, -2.000000, 2.000000) glVertex3f(2.000000, 2.000000, 2.000000) glVertex3f(-2.000000, 2.000000, 2.000000) glNormal3f(0.000000, -1.000000, 0.000000) glVertex3f(-2.000000, -2.000000, 2.000000) glVertex3f(-2.000000, -2.000000, -2.000000) glVertex3f(2.000000, -2.000000, -2.000000) glVertex3f(2.000000, -2.000000, 2.000000) glNormal3f(0.000000, 1.000000, 0.000000) glVertex3f(2.000000, 2.000000, 2.000000) glVertex3f(2.000000, 2.000000, -2.000000) glVertex3f(-2.000000, 2.000000, -2.000000) glVertex3f(-2.000000, 2.000000, 2.000000) glEnd() glRotate(-30, -1, -1, 0) glTranslatef(-self.position[0], -self.position[1], -self.position[2]) def run(): pygame.init() screen = pygame.display.set_mode(SCREEN_SIZE, HWSURFACE|OPENGL|DOUBLEBUF) resize(*SCREEN_SIZE) init() clock = pygame.time.Clock() glMaterial(GL_FRONT, GL_AMBIENT, (0.1, 0.1, 0.1, 1.0)) glMaterial(GL_FRONT, GL_DIFFUSE, (1.0, 1.0, 1.0, 1.0)) # Camera transform matrix camera_matrix = Matrix44() camera_matrix.translate = (10.0, 2.0, 20.0) # Initialize speeds and directions rotation_direction = Vector3() rotation_speed = radians(90.0) movement_direction = Vector3() movement_speed = 5.0 objects_Render = [] ground_1 = ground() objects_Render.append(ground_1) mouse_pos = pygame.mouse.get_pos() while True: for event in pygame.event.get(): if event.type == QUIT: return if event.type == KEYUP and event.key == K_ESCAPE: return # Clear the screen, and z-buffer glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); time_passed = clock.tick() time_passed_seconds = time_passed / 1000. pressed = pygame.key.get_pressed() # Reset rotation and movement directions rotation_direction.set(0.0, 0.0, 0.0) movement_direction.set(0.0, 0.0, 0.0) # Modify direction vectors for key presses if pressed[K_LEFT]: rotation_direction.y = +1.0 elif pressed[K_RIGHT]: rotation_direction.y = -1.0 if pressed[K_UP]: rotation_direction.x = +1.0 elif pressed[K_DOWN]: rotation_direction.x = -1.0 if pressed[K_d]: rotation_direction.z = -1.0 elif pressed[K_a]: rotation_direction.z = +1.0 if pressed[K_w]: movement_direction.z = -5.0 elif pressed[K_s]: movement_direction.z = +5.0 if pygame.mouse.get_pressed()[0]: print pygame.mouse.get_pressed()[0] new_mouse_pos = pygame.mouse.get_pos() if new_mouse_pos != mouse_pos: # rotation_direction.z = (float(new_mouse_pos[0]) - (mouse_pos[0]))/2.0 if new_mouse_pos > mouse_pos: rotation_direction.z = ((1.0*new_mouse_pos[0]) - (1.0*mouse_pos[0]))/360 elif new_mouse_pos < mouse_pos: rotation_direction.z = -((1.0*mouse_pos[0]) - (1.0*new_mouse_pos[0]))/360 if new_mouse_pos[0] > mouse_pos[0]: rotation_direction.x = SCREEN_SIZE[1]/60.0 * .1 elif new_mouse_pos[0] > mouse_pos[0]: rotation_direction.x = SCREEN_SIZE[1]/60.0 * -.1 mouse_pos = new_mouse_pos mouse_pos = (0, 1) if pressed[K_n]: # Beginning of objects_Render.append() objects_Render.append(Cube_Projectile((0.0,0.0,0.0))) # End of objects_Render.append() # Calculate rotation matrix and multiply by camera matrix rotation = rotation_direction * rotation_speed * time_passed_seconds rotation_matrix = Matrix44.xyz_rotation(*rotation) camera_matrix *= rotation_matrix # Calcluate movment and add it to camera matrix translate heading = Vector3(camera_matrix.forward) movement = heading * movement_direction.z * movement_speed camera_matrix.translate += movement * time_passed_seconds # Upload the inverse camera matrix to OpenGL glLoadMatrixd(camera_matrix.get_inverse().to_opengl()) # Light must be transformed as well glLight(GL_LIGHT0, GL_POSITION, (0, 1.5, 1, 7)) print event.type for obj in objects_Render: """ print "Object: ", objects_Render.index(obj) print "Object Position: ", obj.position, "\n" """ tup = [] tup.append(obj.position[0] + random.uniform(-0.70,0.50)) tup.append(obj.position[1] + random.uniform(-0.70,0.50)) tup.append(obj.position[2] + random.uniform(-0.70,0.50)) obj.position = tuple(tup) obj.render() # Show the screen pygame.display.flip() run()  
  13. I am attempting to find the neighbors for each vert in an object. By finding all the neighbors, adding them to a index in a consistent clockwise/counter-clockwise order, I can then calculate the normals via Newell's Method. But, I have a problem. When I run this with a cube as a test object, I get Half the normals moving in the correct direction (normals facing out of object), and the other half facing inwards. The problem is the order in which the verts are added. I can't figure out how to consistently find which verts to  add to the list of neighbors according to the neighbors position.   for face in faces: if vert_ID+1 in face: if total_Neighbors == 3: if face.index(vert_ID+1) == 0: # print "Located: 0" if vertices[face[1]-1] not in neighbors: neighbors[1] = vertices[face[1]-1] if vertices[face[3]-1] not in neighbors: neighbors[2] = vertices[face[3]-1] elif face.index(vert_ID+1) == 1: # print "Located: 1" if vertices[face[0]-1] not in neighbors: neighbors[0] = vertices[face[0]-1] if vertices[face[2]-1] not in neighbors: neighbors[1] = vertices[face[2]-1] elif face.index(vert_ID+1) == 2: # print "Located: 2" if vertices[face[1]-1] not in neighbors: neighbors[0] = vertices[face[1]-1] if vertices[face[3]-1] not in neighbors: neighbors[2] = vertices[face[3]-1] elif face.index(vert_ID+1) == 3: # print "Located: 3" if vertices[face[0]-1] not in neighbors: neighbors[0] = vertices[face[0]-1] if vertices[face[2]-1] not in neighbors: neighbors[1] = vertices[face[2]-1] For every vert in an object, I iterate through all the faces, checking to see if the vert is contained in the face. If so, I grab the address/index value of the verts position in the face. For every possible position the vert can be in (in a cube, there are obviously 4 possible places it can be...), I add the two verts, which would logically be connected to it, after checking to make sure each is not going to be written over a value already in the list of neighbors (If a value besides zero already occupies the spot, my algor. doesn't overwrite it. I ran into some issues when I did.).   I create the neighbors list and initialize it with values (so I can assign rather than append, which created problems with my partic. algorithm). If the vert is in position 1 (or index value "0") I assign the two neighbors to specific spots in the neighbors list. The order and spot they occupy is important since newells method is non-commutative (the two possible results being complete opposite vectors), meaning I need to ensure all neighbors are added as either clockwise, or counter-clockwise.   The following is a line for each vertice, followed by the list of neighbors. Neighbors: (-1.0, -1.0, 1.0) [(-1.0, -1.0, -1.0), (1.0, -1.0, 1.0), (-1.0, 1.0, 1.0)] (-1.0, -1.0, -1.0) [(-1.0, -1.0, 1.0), (1.0, -1.0, -1.0), (-1.0, 1.0, -1.0)] (1.0, -1.0, -1.0) [(1.0, 1.0, -1.0), (1.0, -1.0, 1.0), (-1.0, -1.0, -1.0)] (1.0, -1.0, 1.0) [(-1.0, -1.0, 1.0), (1.0, 1.0, 1.0), (1.0, -1.0, -1.0)] (-1.0, 1.0, 1.0) [(-1.0, -1.0, 1.0), (1.0, 1.0, 1.0), (-1.0, 1.0, -1.0)] (-1.0, 1.0, -1.0) [(-1.0, -1.0, -1.0), (1.0, 1.0, -1.0), (-1.0, 1.0, 1.0)] (1.0, 1.0, -1.0) [(-1.0, 1.0, -1.0), (1.0, 1.0, 1.0), (1.0, -1.0, -1.0)] (1.0, 1.0, 1.0) [(1.0, 1.0, -1.0), (1.0, -1.0, 1.0), (-1.0, 1.0, 1.0)]   Then the output: Normals: (-2.0, -2.0, 2.0) ( 2.0, 2.0, 2.0)#<- reversed. Should be (-2.0, -2.0, -2.0) ( 2.0, -2.0, -2.0) (-2.0, 2.0, -2.0)#<- reversed. Should be (2.0, -2.0, 2.0) (-2.0, 2.0, 2.0) ( 2.0, -2.0, 2.0)#<- reversed. Should be (-2.0, 2.0, -2.0) ( 2.0, 2.0, -2.0) (-2.0, -2.0, -2.0)#<- reversed. Should be (2.0, 2.0, 2.0) And yes...I have not normalized these, so they are a length of 2. I already have a func for normalizing the values, I just didn't use it. Anyway's, has anyone seen examples of this problem or see any solutions for dealing with it? I have the bulk of this written, but it's useless if every other normal is pointing INTO the object....   I don't need the algorithm in any particular language or anything, you can even help with pseudocode. I'm not picky. Thanks in advance.
  14. [quote name='slicer4ever' timestamp='1358182799' post='5021454'] you translate to the cube's position in the render call, and don't translate back, so now 0.0, 0.0, 0.0 is in relative to the last cube's position, which is relative to the one before it, and that to the one before it, and so on. [/quote]     Soooo...when I use the translate method, I am actually setting the origin for ALL objects to be drawn at that point....not just that specific object? Weird. TY. It's working now obviously. Oh, and any idea what I am doing wrong to cause the "ground" to not render?
  15. When I start my program and press "N" to create a new cube, the cube is added to a list and rendered. However, with the addition of each new cube, it seems to save the position of the previous one and create any new cube at that spot. Feeling a little frustrated. I don't see how it's overwriting the initialized position that I give it :   objects_Render.append(                                        Cube_Projectile((0.0,0.0,0.0))                                        )                                                                                                                       What am I doing wrong?     SCREEN_SIZE = (800, 600) import sys from math import radians from OpenGL.GL import * from OpenGL.GLU import * import pygame from pygame.locals import * from gameobjects.matrix44 import * from gameobjects.vector3 import * import random def resize(width, height): glViewport(0, 0, width, height) glMatrixMode(GL_PROJECTION) glLoadIdentity() gluPerspective(90.0, float(width)/height, .1, 10000.) glMatrixMode(GL_MODELVIEW) glLoadIdentity() def init(): glEnable(GL_DEPTH_TEST) glShadeModel(GL_FLAT) glClearColor(1.0, 1.0, 1.0, 1.0) glEnable(GL_COLOR_MATERIAL) glEnable(GL_LIGHTING) glEnable(GL_LIGHT0) glLight(GL_LIGHT0, GL_POSITION, (10, 10, 10, 0)) class Ground(object): def __init__(self): self.position= (0.0, 0.0, 0.0) self.color = tuple([random.uniform(0.0,1.0), random.uniform(0.0,1.0) , random.uniform(0.0,1.0)]) def render(self): glColor(self.color[0], self.color[1], self.color[2]) glTranslatef(self.position[0], self.position[1], self.position[2]) glBegin(GL_QUADS) glNormal3f(0.000000, 1.000000, 0.000000) glVertex3f(-2000.000000, 0.000000, -200.000000) glVertex3f(-2000.000000, 0.000000, 200.000000) glVertex3f(-2000.000000, 0.000000, 200.000000) glVertex3f(-2000.000000, 0.000000, -200.000000) glEnd() class Cube_Projectile(object): def __init__(self, position): self.position = (0.0, 0.0, 0.0) self.color = tuple([random.uniform(0.0,1.0), random.uniform(0.0,1.0) , random.uniform(0.0,1.0)]) self.life = 1000 def render(self): if self.life > 0: glColor(self.color) # Adjust all the vertices so that the cube is at self.position # vertices = [tuple(Vector3(v) + self.position) for v in self.vertices] # Draw all 6 faces of the cube self.life -= 1 glTranslatef(self.position[0], self.position[1], self.position[2]) glBegin(GL_QUADS) glNormal3f(2.000000, 0.000000, 0.000000) glVertex3f(-2.000000, -2.000000, -2.000000) glVertex3f(-2.000000, -2.000000, 2.000000) glVertex3f(-2.000000, 2.000000, 2.000000) glVertex3f(-2.000000, 2.000000, -2.000000) glNormal3f(0.000000, -0.000000, 2.000000) glVertex3f(-2.000000, 2.000000, -2.000000) glVertex3f(2.000000, 2.000000, -2.000000) glVertex3f(2.000000, -2.000000, -2.000000) glVertex3f(-2.000000, -2.000000, -2.000000) glNormal3f(-2.000000, 0.000000, -0.000000) glVertex3f(2.000000, 2.000000, -2.000000) glVertex3f(2.000000, 2.000000, 2.000000) glVertex3f(2.000000, -2.000000, 2.000000) glVertex3f(2.000000, -2.000000, -2.000000) glNormal3f(0.000000, -0.000000, -1.000000) glVertex3f(-2.000000, -2.000000, 2.000000) glVertex3f(2.000000, -2.000000, 2.000000) glVertex3f(2.000000, 2.000000, 2.000000) glVertex3f(-2.000000, 2.000000, 2.000000) glNormal3f(0.000000, -1.000000, 0.000000) glVertex3f(-2.000000, -2.000000, 2.000000) glVertex3f(-2.000000, -2.000000, -2.000000) glVertex3f(2.000000, -2.000000, -2.000000) glVertex3f(2.000000, -2.000000, 2.000000) glNormal3f(0.000000, 1.000000, 0.000000) glVertex3f(2.000000, 2.000000, 2.000000) glVertex3f(2.000000, 2.000000, -2.000000) glVertex3f(-2.000000, 2.000000, -2.000000) glVertex3f(-2.000000, 2.000000, 2.000000) glEnd() def run(): pygame.init() screen = pygame.display.set_mode(SCREEN_SIZE, HWSURFACE|OPENGL|DOUBLEBUF) resize(*SCREEN_SIZE) init() clock = pygame.time.Clock() glMaterial(GL_FRONT, GL_AMBIENT, (0.1, 0.1, 0.1, 1.0)) glMaterial(GL_FRONT, GL_DIFFUSE, (1.0, 1.0, 1.0, 1.0)) # Camera transform matrix camera_matrix = Matrix44() camera_matrix.translate = (10.0, 1.0, 20.0) print camera_matrix.translate # Initialize speeds and directions rotation_direction = Vector3() rotation_speed = radians(90.0) movement_direction = Vector3() movement_speed = 5.0 objects_Render = [] ground = Ground() while True: for event in pygame.event.get(): if event.type == QUIT: return if event.type == KEYUP and event.key == K_ESCAPE: return # Clear the screen, and z-buffer glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); time_passed = clock.tick() time_passed_seconds = time_passed / 1000. pressed = pygame.key.get_pressed() # Reset rotation and movement directions rotation_direction.set(0.0, 0.0, 0.0) movement_direction.set(0.0, 0.0, 0.0) # Modify direction vectors for key presses if pressed[K_LEFT]: rotation_direction.y = +1.0 elif pressed[K_RIGHT]: rotation_direction.y = -1.0 if pressed[K_UP]: rotation_direction.x = +1.0 elif pressed[K_DOWN]: rotation_direction.x = -1.0 if pressed[K_d]: rotation_direction.z = -1.0 elif pressed[K_a]: rotation_direction.z = +1.0 if pressed[K_w]: movement_direction.z = -1.0 elif pressed[K_s]: movement_direction.z = +1.0 if pressed[K_n]: # Beginning of objects_Render.append() objects_Render.append(Cube_Projectile((0.0,0.0,0.0))) # End of objects_Render.append() # Calculate rotation matrix and multiply by camera matrix rotation = rotation_direction * rotation_speed * time_passed_seconds rotation_matrix = Matrix44.xyz_rotation(*rotation) camera_matrix *= rotation_matrix # Calcluate movment and add it to camera matrix translate heading = Vector3(camera_matrix.forward) movement = heading * movement_direction.z * movement_speed camera_matrix.translate += movement * time_passed_seconds # Upload the inverse camera matrix to OpenGL glLoadMatrixd(camera_matrix.get_inverse().to_opengl()) # Light must be transformed as well glLight(GL_LIGHT0, GL_POSITION, (0, 1.5, 1, 7)) ground.render() for obj in objects_Render: print "Object: ", objects_Render.index(obj) print "Object Position: ", obj.position, "\n" tup = [] tup.append(obj.position[0] + random.uniform(-0.50,0.50)) tup.append(obj.position[1] + random.uniform(-0.50,0.50)) tup.append(obj.position[2] + random.uniform(-0.50,0.50)) obj.position = tuple(tup) obj.render() # Show the screen pygame.display.flip() run()