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

Hey Guy (and everyone else),

Thanks for that interesting read, I do have a (sort of) specific look that I
want for the engine which given my current lack of knowledge of industry
terms is a little hard to describe. When I showed my terrain renderer
prototype to a few friends on a forum I sometimes visit their first reaction
was 'but it would look great with normal mapping'. When I think of normal
maps, or bump maps, I always see the same extremely high contrasting cave
walls from Oblivion, or the lighting in Doom 3, and how there seemed to
literally be no ambient lighting at all, no attempt to even trick the player
into thinking that any sort of radiosity existed. This is something I want
to studiously avoid. I want my terrain to look real in a Half-Life 2 sort of
real, not in an almost unreal Oblivion (or in some cases the first Crysis,
with its massive over abundance of rocks and pebbles) style. Which is not to
say that I wouldn't want to use normal or bump mapping, but your post made
me consider the kinds of features I want the engine to include.

My goal before I begin writing a graphics *engine* that handles terrain is
to get my prototype looking the way I want the finished engine to look, that
way I will have learnt all the rendering methods I'll require to create the
engine. In the mean time I'm also looking forward and considering how I
might begin building the engine, hence my post to the mailing list.

Tommy

On Mon, Mar 21, 2011 at 6:16 AM, Guy Rabiller <[email protected]> wrote:

>  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]>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 [email protected]://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