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

Hi Tommy,

 

I would recommend doing both: try Megan’s suggestion of trying an existing
graphics API before diving straight into the lower levels. It’s always good
to check out how existing solutions work, but I still think you will find
value in building your own from the ground up. While Nicholas is right –
you’re never going to build one better than one that’s already available –it
will nevertheless be a great learning experience (and fun!) It also means
you’ll begin to understand the design decisions made by the other graphics
engines that you will have tried out in the meantime. 

 

It’s the difference between being a racing driver and a mechanic, really: If
you like the high-level (writing shaders, making pretty things) stick to an
existing one. If you like the low-level (architecture, speed), roll your
own. Or do both in whichever order you want :) 

 

Regarding your choice of programming paradigm, there’s been a recent shift
away from OOP and more towards data-oriented architectures. (Sorry to throw
in more things to confuse you at this early stage, but the power of the
internet compels me.) Rendering engines tend to deal with large subsets of
data that need to be processed very fast, so OOP tends to be
counter-intuitive. I recommend reading the Managing Coupling series of
articles on the BitSquid blog if you want to know more about the reasoning
behind this. (http://bitsquid.blogspot.com/2011/01/managing-coupling.html)

 

P.

 

 

From: [email protected]
[mailto:[email protected]] On Behalf Of Nicholas
Aelick
Sent: 18 March 2011 14:16
To: [email protected]
Subject: Re: [Sweng-Gamedev] Architecting and programming a graphics engine
in C++ & OpenGL

 

I would tend to agree with Megan. Building a graphics engine from scratch
for the learning experience is a little like building a computer by
soldering bits of wire together for the learning experience. You're unlikely
to get far, and even if you succeed, you're unlikely to end up with
something nicer then is already available.

 

I would recommend looking into existing solutions (partially because any
place you work for will have you working with those, anyways). If you're
really serious about building a custom graphics engine, find one that's open
source, and see how they solved the problems you've been having. 

 

Nicholas

On Fri, Mar 18, 2011 at 10:03 AM, Megan Fox <[email protected]> wrote:

To take it in another way, I would generally recommend no one set out to
write their own graphics engine from scratch without first using another.
Simple example - OGRE.  Great jumping-off point, great community, etc.
Build up a game around it, then burrow down and start changing OGRE to suit
your needs, then burrow down further and tweak the graphics, and so on.

There's very little reason to write a graphics engine yourself, unless
you're addressing the faults of a pre-existing engine you tried and found
insufficient.  Without that grounding, you're stumbling in the dark, and it
will likely take quite some time and a hundred dead ends for you to get
within spitting distance of even the bad current graphics engines.  You're
also needlessly re-inventing the wheel, unless Graphics Programming is
specifically what you're aiming at - there's a lot more to games programming
than rendering, and your portfolio would need to be more than rendered
planets to break in (ie. what happens on or with those planets, and why
they're fun to walk around / fly around / whatever).

----
Megan Fox
http://www.shalinor.com/
http://www.glassbottomgames.com/





On Fri, Mar 18, 2011 at 7:58 AM, Rémi Papillié <[email protected]>
wrote:

Hi Tommy,

While this might not answer completely such a broad question, I would
recommend you look at this site:
http://gamearchitect.net/

More specifically, some articles called 'An Anatomy of Despair'
explain the design of the author's engine. See for instance:
http://gamearchitect.net/2008/04/19/an-anatomy-of-despair-orthogonal-views

I would also recommend the excellent book 'Game Engine Architecture',
by Jason Gregory.

Note, however, that these resources are mainly oriented towards game
engines as whole. AFAIK, there are not many resources on the specifics
of graphics engine design and architecture but, as you said, mainly a
lot of very technical articles one some technologies and
implementations.

For what it's worth, here is the structure I currently use on my
personal engine. It works, but has not been confronted to a real prod,
so what follows is definitely not bullet-proof.

The technical API (OpenGL/DirectX) is abstracted away in a thin layer.
I use this layer mainly for readibility purposes (e.g being able to
write texture->enableFiltering(BILINEAR) instead of two or three
cryptic OGL/DX calls), but with a bit more work, you can also use it
to make the engine cross-api (with many simple but error-prone
details, such as matrix transpositions).

On top of that, two modules are present:
- The graphics scene contains an abstract description of graphical
elements that are part of the world. No shading algorithms here, just
plain buffers augmented with various information (transforms...). The
scene handles all issues about traversal and culling. Whenever a
render is asked, a render list is built by querying the spatial
partitioning structure, and then sent to the renderer (see below).
- The renderer is just the raw implementation of shading algorithms.
It receives a render list + a frustum and draws everything, using
various techniques (e.g forward or deferred shading).

The render list basically contains packets in the form <transform,
mesh, material> (+ lights), but this is highly dependent on how the
rest is implemented.

Hope this helps! I'll also be very happy to learn about other ways of
designing graphics engines, if someone else has good resources on the
subject ;)

Rémi

2011/3/18 Tommy Brett <[email protected]>:

> 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


_______________________________________________
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