views:

235

answers:

2

I'm trying to build a (simple) game engine using c++, SDL and OpenGL but I can't seem to figure out the next step. This is what I have so far...

An engine object which controls the main game loop

A scene renderer which will render the scene

A stack of game states that can be pushed and popped

Each state has a collection of actors and each actor has a collection of triangles. The scene renderer successfully sets up the view projection matrix

I'm not sure if the problem I am having relates to how to store an actors position or how to create a rendering queue.

I have read that it is efficient to create a rendering queue that will draw opaque polygons front to back and then draw transparent polygons from back to front. Because of this my actors make calls to the "queueTriangle" method of the scene renderer object. The scene renderer object then stores a pointer to each of the actors triangles, then sorts them based on their position and then renders them.

The problem I am facing is that for this to happen the triangle needs to know its position in world coordinates, but if I'm using glTranslatef and glRotatef I don't know these coordinates!

Could someone please, please, please offer me a solution or perhaps link me to a (simple) guide on how to solve this.

Thankyou!

+2  A: 

If you write a camera class and use its functions to move/rotate it in the world, you can use the matrix you get from the internal quaternion to transform the vertices, giving you the position in camera space so you can sort triangles from back to front.

Blindy
+1  A: 

A 'queueTriangle' call sounds to me to be very inefficient. Modern engines often work with many thousands of triangles at a time so you'd normally hardly ever be working with anything on the level of a single triangle. And if you were changing textures a lot to accomplish this ordering then that is even worse.

I'd recommend a simpler approach - draw your opaque polygons in a much less rigorous order by sorting the actor positions in world space rather than the positions of individual triangles and render the actors from front to back, an actor at a time. Your transparent/translucent polygons still require the back-to-front approach (providing you're not using premultiplied alpha) but everything else should be simpler and faster.

Kylotan
in fact th opaque advice above is what the graphics card manufacturers recommend because switching shader/constant/texture/etc regularly is much more expensive than a polygon failing the early out Z test.
Goz
Yep. Reducing overdraw is good, but not at the expense of numerous state changes.
Kylotan