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

Hi,

It's interresting to see that most answers to a the "architecting and 
programming a graphics engine in C++"  question are geared toward a 
"game" graphics engine.

While this is understandable, there are many forms of graphics engines.

As an exemple, take the game graphics engines on one side, and the 
automotive oriented graphics engines on another side.

The first ones must be scalables, work on (relatively) old graphic 
cards, must be real time and and from my point of view have this 
inevitable "game look" rendering, even the lastest incarnation of some 
high end graphics/game engines.

The second ones are not always realtime, rather work at interactive 
rates, work on the most recent cards, but show realistic rendering.

IMHO I think the first question you have to answer is what kind of 
renderer you want to achieve, and what kind of result - or visual look - 
you want to achieve because this answer alone has a lot of implications 
in a graphic engine design.

Visual look is not just a question of features, but a question of image 
culture and understandings about what makes a picture considered as 
"realistic rendering" - if it's the goal, of course.

Regarding realistic rendering, you have to work in the VFX industry to 
understand how this works. Most peoples in the game industry don't 
understand this, despite all the tools and features they have.

Linear workflow ( sRGB framebuffer.. ), ambient occlusion, global 
illumination, HDR, etc.. all came from the VFX/CGI industry and it's 
funny to see, for instance, that even nowadays, some game engines SDK ( 
UDK ) still invite you to use ambient occlusion with diffuse ( multiply 
), wich is obviously totaly wrong. Ambient occlusion has been created to 
be use with the ambient part of a lighting process wich splits ambient 
lighting from diffuse lighting ( as an attempt to cheat global 
illumination and it works pretty well in the VFX/CGI industry ), but 
this ambient lighting is totaly absent from the graphics engine 
rendering pipeline. How then it is supposed to work correctly ? It can't.

My point beeing that designing a graphics engine is one thing, it is 
certainly hard, but with time it can be done, so I encourage you to go 
on, but, what is perhaps more important - and I think this is where 
you'll learn the most - is to understand what kind of look your renderer 
will be able to achieve, and you will be able to answer this question by 
first understanding *what* make a rendering having this look you want 
and how to achive it ( realtime or not ).

Cheers,
Guy.
--
guy rabiller | radfac founder / ceo


Le 20/03/2011 22:02, Jon Watte a écrit :
> 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] 
> <mailto:[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]>
>     [mailto:[email protected]
>     <mailto:[email protected]>] *On Behalf
>     Of *Massimo Del Zotto
>     *Sent:* Sunday, March 20, 2011 3:21 AM
>
>     *To:* [email protected]
>     <mailto:[email protected]>
>     *Subject:* Re: [Sweng-Gamedev] Architecting and programming a
>     graphics engine in C++ & OpenGL
>
>     2011/3/19 Nathan Martz <[email protected]
>     <mailto:[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]
>     <mailto:[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