Re: Architecting and programming a graphics engine in C++ & OpenGL

I would recommend anything by Eric Lengyel, and whatever the latest
iteration is of David Eberly's set of books. Neither is perfect, but both
are written by people who actually have clues (which is somewhat rare in the
tutorials area, I've found :-)

The other thing I would recommend is to spend significant time trying to
develop a game -- any game -- within a number of different game engines.
Panda3D. C4 engine. Torque (if it's still around). UDK. Unity. The list goes
on, but if you try to develop a game idea/concept with each of those tools,
far enough that you actually get to something playable in each, then you
should have learned a number of different ways to do things.

Also, it's important to understand the art creation part of the graphics
pipeline. Learning at least one of the top modeling packages (Max, Maya,
etc) is highly useful, and poking at a variety of art pipelines (Colllada,
Havok, Granny, etc) is also helpful. Most game engines mentioned also come
with art pipelines, but somehow, each of them comes up short in at least one
area -- this is also an important lesson!

No reading can replace the practice of actually doing things, and because
you need to spend a month or two with significant effort on each engine, you
probably won't have the breadth of experience needed completed this year,
but it's an approach I highly recommend!

Good luck, and I hope this helps.

Sincerely,

jw

--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world. Nevertheless,
whether we get there willingly or not, we shall soon have lower consumption
rates, because our present rates are unsustainable.



On Fri, Mar 18, 2011 at 5:52 AM, Tommy Brett <[email protected]> wrote:

> Hi folks,
>
> I've been working as an AS3 programmer / animator for the last 3.5 years,
> and have the strongest desire to leave the marketing industry behind and
> pursue my original intended career as a games programmer, which I sidelined
> due to a very coincidental series of events. To this end, I've been (slowly)
> building a graphics engine using C++, OpenGL and nVidia CG which renders
> very large chunks of terrain using GPU Clipmaps. The idea is that eventually
> it will render planets with atmosphere and real time shadows, or die trying,
> and in any case will serve as my main portfolio piece when I eventually
> start applying for positions. Because I've been outside of my programming
> comfort zone for so long it's been slow going, but now that I've finally got
> a firm grasp on shaders and the OpenGL pipeline it's time to look to the
> future.
>
> This is where my problem lies; although there are many examples on the 'net
> showing me how to animate the most beautiful normal mapped cobbled cube, or
> tutorials on specific rendering / culling / lighting algorithms, I've yet to
> find a resource beside Michael Abrash's Graphics Programming Black Book
> (which sits on my desk, reminding me of what I should have been doing all
> along) which goes into the subject of writing a graphics engine. See
> although I can write perfectly passable C++, and thanks to my AS3
> programming experience which has frequently required that I get my projects
> right 'the first time', I'm fairly adept at planning and designing my
> classes before I begin... But from a C++ standpoint, I'm somewhat in the
> dark. What are the best practices for building a graphics engine in C++?
> Exactly how OOP should I go? How should I handle the use of multiple shaders
> on chunks of geometry? There's just this giant multitude of questions, and
> although I have a knack for over engineering things, I really want to have a
> better picture of what I'm aiming for before I start, or I'll end up with
> the monstrosity that is my terrain prototype (it runs, but it's so, so
> ugly).
>
> Currently my idea for a graphics engine involves something like an engine
> class that takes render packets of data, has some sort of ability to sort
> them into an order that best facilitates speedy rendering, and changes its
> state depending on the information in the packets. E.g. one packet might be
> a chunk of terrain, and could include information about what shaders to use,
> how to determine its potential visible set, and the type of collision
> detection to use (though this deviates a little from the graphics engine
> part). There might be an arbitrary number of terrain packets, followed by
> some character models or buildings using a different type of culling
> algorithm. My worry aside from the obvious problem of the whole idea
> possibly being crap, is that it's too general. How could I possibly create
> an engine that handles every possible rendering type, shouldn't I perhaps
> start with the assertion that I'm building a terrain engine, and base
> everything around rendering sphere like chunks of geometry with varying
> levels of detail? But on the same token, I don't just want to end up with
> another terrain engine prototype as seen on youtube(tm).
>
> So I suppose what I'm looking for are book suggestions, or perhaps
> open-sourced graphics engines that I could look at and learn from, or maybe
> I should just try and get a position as a junior-something-programmer and
> learn by doing (the trouble is there aren't any such positions available
> where I live, and relocation would be difficult to justify based upon the
> possibly low salary expectations of a junior position, I'd like at least
> some leverage). Ideas? Suggestions? Is this even the right place to ask such
> broad questions? I'm all ears.
>
> - Tommy
>
> _______________________________________________
> Sweng-Gamedev mailing list
> [email protected]
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
>
>

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com