well if he has internal knowlege of OGL drivers he'd be good to have around just in an advisory role, even if he can't give specific details due to NDAs.
taylor is going to love you.
there is a good deal of discussion right now in the graphics department, I am the only person with D3D knowlege and I'm unrelyable, so there has been a lot of discusion on weather we should keep D3D.
for the last few years, I've been trying to work out a way to implement the most flexable way to implement shaders and materials in general, I'm currently planning on a teired material system that will use (in OGL termonology) display lists to save states for one or more rendering passes, the display lists will be constructed by either filling in a basic text based data file (a table, this is what freespace uses for most game data of this nature) or by running a script. the actual drawing of the geometry will have a similar split in useage, there will be a simple set_display_list(); draw_geometry(); loop that will run through each list (there will be two versions of each pass, one for normal drawing, another for additive lighting, the main diference being that the second will almost always have additive alpha blending for handeling more than 8 lights), and a slower but far more custumiseable scriptthat will basicly take over all aspects of drawing.
that's MY plan at the moment, haven't quite convinced the others of it, and I'm not implementing it untill after our next release. after this I will redesign the way our models are handeled (inclueding a new file format) wich will allow for more flexable vertex data (as well as stuff like neighbor data for the polies wich can be used for shadow volumes and decals) wich should allow full shaders, with full customiseability of geometry on a per material basis, to be easily implemented.
the biggest thing I need for this is to make our API abstraction more... abstract, so I need someone with OGL understanding to write high level interfaces for the diferent states.
