|
Author Topic:   Renderer
ostra
Member
posted September 08, 1999 12:22 PM            
Hi!
Iīm currently programming a renderer for a game, and Iīd like to receive oppinions about it. I wrap OpenGL in a class called GLRenderer, which has methods for setting OpenGL flags, managing the viewing frustrum, etc. Also, it has method for drawing triangles and vertex arrays. Then I have the Object3D abstract class. All drawable objects derive from it. They use the draw() method to draw themselves, and the renderer is passed as parameter. The objects can call any renderer command (for example, disabling depth test) and just output triangles.
I donīt know if this is the best way to do things, primarly because it is an Inmediate Mode renderer. Another bad thing is that an object might leave the depth test off and all other objects will be drawn without depth test, but thatīs a programmers concern.
Also, I canīt render transparent polygons this way, Iīll have to create other method for that (collect all the transparent tris in a list, sort it and then draw them). So, I will have a mixed engine (part IM part RM).
Well, waiting for posts then...

Marco

IP:

LDA Seumas
unregistered
posted September 08, 1999 12:53 PM           
Hi Marco,

That sounds pretty good, and it's similar to what I do for my non-terrain objects in Tread Marks.

One thing about letting Objects set render states through callbacks into the Render object is that it's easy to trap duplicate state changes and not bother setting those OpenGL states (which should be faster than resetting the same OpenGL state multiple times). Then each Object can simply ask for the states it needs, and if any happen to be already set, the Render object simply won't bother setting them again. Then you won't have any problems with no depth test when you need it, or whatever. Texture binds should especially be checked like this, so if you happen to render a bunch of Objects in a row with the same texture, you only tell OpenGL to set the texture once.

As for transparent vs. opaque objects, it depends partly on whether you need object-level or polygon-level sorting. If your transparent objects are mainly Additive blended (which is 100% order independent), or you can live with a few minor artifacts when you do use Alpha opacity, then you can use object-level sorting only. This is easy, as you just throw your Object objects into a list, and qsort the list by camera Z (one dot product, if you don't have it computed already) before you render them as normal. This is what I do in Tread Marks. If you need polygon-level sorting, you'll still have a fairly easy time since you're calling back into the Render object to draw your triangles; just batch the triangles up and sort them by Z, then render them all at once after all other rendering is done. If transparent objects won't do much intersecting of each other, you can use object sorting and poly sorting, and only batch polies until the object is done, meaning you'd have to save a lot less state info with each batched poly.

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP: