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

It could mean a variety of things. Maybe it's just that you thought
about the implications of these trends as you were writing the renderer.
That way when you get questions in your interview about how you would
handle parallelism, you'll have a thoughtful answer. Often being able to
say "well, it wasn't worth the time to implement, but I designed it make
that easy in the future because I..." is totally sufficient. If you want
something more tangible, try something like dynamic GI or one of the
more advanced types of AA which, depending on the hardware you are
targeting, might involve a fair bit of back and forth between the GPU
and the CPU (while making sure that neither is ever starved for work).

 

Another way to put it is that folks tend to be impressed when you solve
problems that are contemporary or even a bit future looking. A couple
decades ago, showing a demo of a bunch of bouncing env mapped sphere
rendered in OpenGL would have been pretty cutting edge. Now, it's not
quite so impressive. Similarly, shader permutations is something that
people were wrangling 5+ years ago, but is pretty sorted out now (unless
you are talking about a toolchain/workflow idea in which case, as Jon
says, could be quite cool). IMHO, most of today's interesting graphics
problems involve a lot of parallelism.

 

Lastly, I realized while writing this that you might get more out of
targeting interesting features (terrain rendering, realtime GI,
whatever) and over time evolving those features into a renderer than
trying to start very broadly. Again, I don't want to tell you what
project to do or where you should start, just hoping that this
perspective informs your ideas and helps you chose the most productive
course.

 

-Nathan

 

From: [email protected]
[mailto:[email protected]] On Behalf Of
Massimo Del Zotto
Sent: Sunday, March 20, 2011 3:21 AM
To: [email protected]
Subject: Re: [Sweng-Gamedev] Architecting and programming a graphics
engine in C++ & OpenGL

 

2011/3/19 Nathan Martz <[email protected]> 

but if your goal is to land a job at a high end game dev studio, there
are, for my money, few more impressive things you could demonstrate than
a renderer that is thoughtfully and productively parallel. 

 

I find this very interesting but in practice, what does that mean?

When I talk about the way I deal with shader combinatorial explosion I
have an easy way to show the benefit. I talk about the "basic" shaders
(admittedly choosen ad-hoc to maximize drama), I show some slides, I
estimate the benefit in terms of production gained.

But this is more performance oriented, more technical. Perhaps it
involves specific "performance patterns", perhaps it needs adeguate
workload. If I had to demo this thing, I wouldn't know where to start.

 

I'd like to read some further elaborations on that.

 

Thank you in advance.

Massimo

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