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

In this context:
I've found that engineers who want to talk and think only about the most
cutting edge shading techniques are generally not as useful to a greater
organization than an engineer who can work intelligently in this area, but
also understands the needs of a business.
For example, someone who can write a graphics engine that scales from a GMA
950 to a GTX 580 is a lot more valuable to me than someone who can shave a
HLSL instruction out from a multi-basis global illumination approximation
shader, that only will run on that GTX 580 in the first place.
Similarly, actually getting the math of graphics right is a lot more
important than any particular detail knowledge.

Here are some questions that matter a lot to me, and drive the overall
design of a rendering engine, even though they are generally derived from
the basic math of graphics:

What are the different coordinate spaces, and how do you transform between
them?
What are some examples of work that's done in these different spaces?
What's the difference between global vs local illumination, anyway?
What happens to the tangent space when you skin an animated character?
How do you blend animations without artifacts?
How do you make skinned character armpits not look like ass when applying
blended animations or rag-doll kinetics?
Which rendering techniques to make things look better that use artist
hinting do you use?
How can you make the artist hinting process as foolproof as possible?
 What is an "inverse bind pose?"
Where in the content pipeline does it get applied?
If you support both vertex morphing (blend target animation) and skinning
(bone blending animation), does this change the answers?
Why is it wrong to calculate dynamic ambient occlusion in screen space? What
are some alternatives?
Why is it wrong to blur dynamic shadows in screen space? What are
some alternatives?

You'd be surprised how many "shader experts" would get half of these wrong
:-(

Separately, understanding how to break up all needed work into multiple,
independent units of work, and schedule them across available cores, is
useful, and can actually be useful in areas other than graphics, so being
able to show intelligence in this area is also good. It's quite separable
from graphics, though -- except for the detail of how APIs don't really let
you be multi-threaded (except for D3D11 and some console stuff)

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 Sun, Mar 20, 2011 at 1:08 PM, Nathan Martz <[email protected]> wrote:

>  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
>
>

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