Slashdot Mirror


Rendering a Frame of Deus Ex: Human Revolution

An anonymous reader writes "Video games are among the most computationally intensive applications. The amount of calculation achieved in a few milliseconds can sometimes be mind-blowing. This post about the breakdown of a frame rendering in Deus Ex: Human Revolution takes us through the different steps of the process. It explains in detail the rendering passes involved, the techniques as well as the algorithms processed by a computer — 60 times per second."

40 of 81 comments (clear)

  1. Re:forget the gameplay! by beelsebob · · Score: 2

    Right, it's not an interesting technical problem to render a scene with lots of interesting lighting effects. No one would ever want to read about that, because game play is more important.

  2. Sounds hard by Kohath · · Score: 1

    Let's outsource the boss fights.

  3. Re: forget the gameplay! by Anonymous Coward · · Score: 3, Insightful

    Omg I've landed on you tubes comments pages - and to think I thought I was being linked to a tech site

  4. Re:Bad form.... by Anonymous Coward · · Score: 1

    It stops if you mouse over it.

  5. Vents by ehiris · · Score: 4, Funny

    Didn't know it takes that much to render the inside of vents.
    That game was played by finding vents and going through them.
    The police station mission was cool but the rest, vents, and more vents.

    1. Re:Vents by Coren22 · · Score: 2

      I guess it all depends on your play style. I spent nearly no rime in vents, but I prefer combat.

      --
      APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
  6. Wow by ledow · · Score: 3, Interesting

    Over 500 draw calls per frame. I've only ever tinkered in basic OpenGL stuff, but does that seem like an awful lot to anyone else? I was always told to reduce draw calls and to use the newer OpenGL features as they were able to batch commands on thousands of vectors, etc. (or are we talking about different types of draw calls?)

    Especially as a lot of the work is done in shaders and shared between passes according to the article?

    Wonder what kind of texture etc. bandwidth that's pushing.

    1. Re:Wow by fleeped · · Score: 4, Informative

      No, 500 draw calls per frame is not *that* much. The majority of the calls are for different materials: For your toy project, that won't be a lot. For an AAA title, it's more like hundreds of material combos.

    2. Re:Wow by Anonymous Coward · · Score: 1

      500 per frame isn't even much. Based on some apitrace runs I've done, MMOs can easily hit a few thousand draw calls and 10k+ API calls total per frame.

      There's just that many things visible at once and batching the work is hard because of unique object graphics and legacy APIs used to support as many legacy Windows systems as possible.

      Intel must love these games --- no AMD CPU is going to run them well when half the work is in a single thread managing a bloated graphics API's state.

    3. Re:Wow by Wootery · · Score: 1

      Precisely what Vulkan and the new Direct3D hope to address.

    4. Re:Wow by Anonymous Coward · · Score: 1

      500 draw calls per frame is tiny. This is actually a rather boring scene -- it's indoors, you don't need to render anything outside the walls (save for the room through the glass window in the back), and even then the scenery is somewhat sparse. In open world games or any game with a detailed horizon, this blows up to many thousands of draw calls per pass (so 10k+ for frame).

      Graphics pipelines are pretty good at stomping through draw calls as long as you don't make expensive state changes (e.g. changing blend modes, shaders, render targets, textures, etc..) in between. Which state changes are "expensive" from graphics card to graphics card, but without these state changes the most expensive part is the potential cache miss (which is often hidden) at the start of the new draw call. In general, a good deal of effort is put into minimizing state changes, especially the expensive ones, and not much effort is really put into minimizing draw calls (unless it truly becomes a bottleneck, like drawing hundreds of thousands of individual rectangles, each with a draw call, for some sort of dazzling UI effect).

      > Especially as a lot of the work is done in shaders and shared between passes according to the article?
      Aye, this isn't deferred rendering, but it has deferred steps in a pretty common multipass scheme. One of the big wins for doing this is deferred lighting. One of the passes mentioned is where they render the contribution from non-directional lights (e.g. point lights, spot lights, but not sunlight). Imagine you've got the scene of a city and you're looking out over the top of a building. How many point and spot lights would you have? Thousands? In a renderer where the contribution of all spotlights is considered in one pass, the same pass that outputs the final color for a pixel, each pixel produced by a drawcall must consider any light that intersects the volume being rendered. This amount is commonly 20 lines and often more -- that's a lot of lights to burn time for on every pixel, each light's calculation can be nontrivial, and the worst part is most the time a specific won't change the pixel color! If you defer this computation into a light buffer, you can draw the lights directly, each one once and where it's far more likely to be noticed. However, to do this you'll need to know the depth information (so you can compute where the pixel is vs. where the light is) and normal (so you can compute how much the surface is catching the light) -- both of which you generate in one pass. You're basically trading computation time for memory bandwidth, but the magnitude of computation time for the lighting effects you want is so severe it's almost always worth it.

      And since we've got a depth buffer anyway, the screen space ambient occlusion (SSAO) can be performed at this stage. This is advantageous so we can treat it like a shadow instead of kludging it into a full-screen effect later where it might just simply dim pixels. (This would cause funny things like ambient occlusion + shadows being even darker than shadows.)

      Also, since we're computing SSAO (which is likely a full-screen effect) before the main pass anyway, we might as well compute the final shadows while we're reading in the depth buffer information already (which can be done in the same full-screen effect).

      > Wonder what kind of texture etc. bandwidth that's pushing.
      They're showing things like "FXAA" taking a very short amount of time. FXAA is fast, but it's not a trivial operation. Supposing the cost of FXAA was just reading some data and shoveling it into another buffer, we can do some math: their FXAA length is about 0.7% of their total 60fps bar on their graph which works out to .0001167 seconds. Assuming they're rendering 1080p, that's 1920*1080*3 bytes per low dynamic range color buffer. (5.93MB) That works out to about 50GB/s. FXAA seems to take about twice the length of simple copy operation (and their bloom operation seems to be a little more than half of their FXAA time), so double that to 10

    5. Re:Wow by gl4ss · · Score: 1

      of course they do that.

      if you drew 1 triangle / draw call or old school like that, just the hand in the scene would exhaust 500.

      --
      world was created 5 seconds before this post as it is.
    6. Re:Wow by friesofdoom · · Score: 1

      We are up to 7000 draw calls being just about OK on the ps4/xbone.

  7. Re:forget the gameplay! by Anonymous Coward · · Score: 1

    People who work on games will find it interesting. I know I did.

  8. Re:Frames by fleeped · · Score: 4, Informative

    So you can't tell the difference between movie and home video? Source for you, in a any case:
    http://www.100fps.com/how_many...
    Whatever floats your boat: I can personally see difference of 60fps to less, and I quite like 60fps.

  9. Re:forget the gameplay! by RogueyWon · · Score: 4, Interesting

    I'd have more sympathy with you if the new-releases list on Steam these days wasn't completely buried by "retro 8-bit style" indie roguelikes which look dreadful and usually play that way as well.

    These days, I've gone beyond "it's not the graphics that matter, it's the gameplay" to "they both matter, seriously". The former has become a go-to excuse for lazy development.

  10. Re:forget the gameplay! by dunkelfalke · · Score: 4, Insightful

    This is Deus Ex we are talking about so the gameplay is good by definition. Even the shitty Invisible War was better than most of other similar games of the period.

    --
    "It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
  11. Re:forget the gameplay! by Anonymous Coward · · Score: 1

    Pretty sure quantitative analysis is where money intersects with math.

  12. Re:forget the gameplay! by Cederic · · Score: 1

    Gameplay is king, but the game mechanics are relatively trivial to write.

    Graphics are fluff but damn there's some serious engineering involved.

  13. Re:forget the gameplay! by microTodd · · Score: 1

    Ha, good point! I didn't think IW was that good yet I played it to completion (which I don't do very often with games) so it must have been good enough.

    The problem, other than the console-itis, was that the original DE was SOOOO good, it would have been hard to step into those shoes.

    --
    "You cannot find out which view is the right one by science in the ordinary sense." - C.S. Lewis on Intelligent Design
  14. What? by Lunix+Nutcase · · Score: 3, Insightful

    Video games are among the most computationally intensive applications

    This is a joke right? Simulating fluid dynamics, simulating weather patterns, finding large primes, factoring primes, etc. are all far more computationally intensive. And that isn't even close to an exhaustive list. Rendering a video game is kiddy stuff in comparison.

    1. Re:What? by westlake · · Score: 3, Interesting

      Rendering a game is kiddy stuff...

      --- until you are expected to believer a theatrical quality experience while running a game on hardware costing no more than $500 retail list.

    2. Re:What? by Anonymous Coward · · Score: 2, Funny

      This is a joke right? Simulating fluid dynamics, simulating weather patterns, finding large primes, factoring primes, etc. are all far more computationally intensive.

      Errr... factoring primes is one of the least computationally intensive problems possible. The factors are always 1 and the number itself. I think you meant finding prime factors.

      In any case you are being a bit pedantic. It is clear that the author was referring to computationally intensive retail software running on commonly available retail hardware. There is no mass-market for weather forecasting software or fluid dynamics simulators.

    3. Re:What? by drinkypoo · · Score: 2

      Video games are among the most computationally intensive applications

      This is a joke right?

      Barring being taken over and being used as part of a botnet for grinding out cryptocoins, the most computationally intensive program most people's computer will ever run will be a video game.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    4. Re:What? by Ungrounded+Lightning · · Score: 1

      Errr... factoring primes is one of the least computationally intensive problems possible. The factors are always 1 and the number itself. I think you meant finding prime factors.

      I'm sure he means "factoring the PRODUCT OF large primes".

      It's an easy slip to make. (I've done it myself. B-b )

      --
      Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
    5. Re:What? by gl4ss · · Score: 1

      yeah so how much does normal folk use their cpu/gpu time for that? they don't. furthermore, having latency on the results is expected in those.

      but the games use all the resources available quite often, due to you wanting to run them at as high settings as the computer permits.

      --
      world was created 5 seconds before this post as it is.
    6. Re:What? by phorm · · Score: 1

      A lot of the real-world tough stuff can apply to video games (but often doesn't because as you say, it's computationally hard to do realtime). However, some stuff like physics modelling did start to take off when it finally got adopted in games. Similarly, a lot of fluid dynamics/simulations are being looked at to improve game realism (which is useful for stuff from water flow to realistic body movement such as fat, breasts, or buttocks).

    7. Re: What? by Anonymous Coward · · Score: 1

      Wait, a fucking theater? OMG are they really a thing? Holy shit, I'd love to go to a fucking theater, that would be awesome!

      Where can I find one? Are the girls good looking?

  15. Re:Frames by Kjella · · Score: 2

    What's annoying is that none of these sites seem to give a straight answer to how many frames per second we can actually distinguish. Yes, even an extremely short flicker of light is detectable but can we notice the difference between a 60 fps and 250 fps video? Here's my proposal:

    1. Get some *extremely high* fps footage, for example the Phantom Flex4K can do 1000 fps for 5 seconds.
    2. Make interpolations that play at normal speed, like:
    7 -> 1 frame for 142.8 fps
    8 -> 1 frame for 125 fps
    10 -> 1 frame for 100 fps
    12 -> 1 frame for 83.3 fps
    14 -> 1 frame for 71.4 fps
    16 -> 1 frame for 62.5 fps
    20 -> 1 frame for 50 fps
    25 -> 1 frame for 40 fps
    32 -> 1 frame for 31.3 fps
    40 -> 1 frame for 25 fps
    3. Do blind A/B tests on a 144 Hz gaming monitor set to match the video frequency. When do you stop being able to tell the difference? That's the frame rate you need to be visually transparent.

    --
    Live today, because you never know what tomorrow brings
  16. Re:forget the gameplay! by Ksevio · · Score: 1

    I have to agree- especially with all the low cost or free (as in beer to an extent) engines out there now, too many games seem to be going the 2D 8 bit style. Even the 2D can be ok, but at least spend a little more effort to make some HD graphics. A lot of late nineties flash games had better graphics.

  17. Re:forget the gameplay! by gl4ss · · Score: 1

    well that and the bugs.

    pretty crappy though that it had console-itis, yet was slow on computers vastly more powerful than the xbox.

    still, played it through... but the inventory system.. damn.

    --
    world was created 5 seconds before this post as it is.
  18. Instructive to see how far we have come by EmBeeDee · · Score: 2

    I love reading this stuff. I remember, back in the days of Amigas and Atari STs where I cut my 3D-programming teeth, it was a struggle simply to render each pixel of the frame buffer once, even at a juddery 10fps. Shadow maps! Bloom effects! Even the supercomputers couldn't do this stuff in my day, or would take hours of rendering time. A little bit sad that I left this world just as computer power started to make it interesting. Mind you, I think the most impressive 3D game of all time, in terms of getting the maximum from the minimum hardware, is still Revs for the BBC Micro. How Geoff managed to get that little old machine to render solid 3D I do not know.

  19. Re:forget the gameplay! by praxis · · Score: 1

    That would be "rended". Rendered is something different: molten, melted.

  20. Re:forget the gameplay! by DNS-and-BIND · · Score: 1
    So, because of a temporary trend, we should throw away one of the foundations of gaming as a recreational activity? WTF? You know what lies down that path, right? We've been there before. It sucks ass down there.

    "Arborea was covered in several Amiga magazines, which predictably focused on the graphics, sound, and music rather than the actual gameplay elements. (The May 1991 review from CU Amiga begins by giving thanks that "the days [are gone] when a role-playing game meant little more than a great leap of the imagination, a plot with trolls and gameplay along the lines of a special maths paper." You want to know when RPGs started getting "dumbed down"? This is it, right here.)"
    -- The CRPG Addict, http://crpgaddict.blogspot.com...

    --
    Shutting down free speech with violence isn't fighting fascism. It IS fascism!
  21. Re:Frames by Kjella · · Score: 1

    Can I tell the difference between 60 and 250? Absolutely. Heck, I can tell the difference between 60 and 75 fps, and can identify a frame rate below 100 pretty readily if things onscreen are moving quickly. (...) When I was gaming regularly, I couldn't stand playing at less than 100 fps.

    Games don't have natural motion blur, if I throw a ball in front of the camera it'll travel during the 1/24th second and leave a smear while a game rendered at 24 fps will have the ball jump in discrete steps like filmed with a strobe light. The easiest way to fix that is to render more frames so the steps become smaller and a better approximation to reality's infinitely smooth motion. What you're measuring isn't how important the frame rate is for the display, but how important the sampling speed is for the simulation. For example if you modeled a realistic camera flash you'd probably need to render at 1000+ FPS to catch the flash going off. Of course that would be a stupid way of doing it, but that's why fps in games don't really say anything about how many fps you need for video.

    --
    Live today, because you never know what tomorrow brings
  22. Re:forget the gameplay! by RogueyWon · · Score: 1

    And yet... I have had masses of fun over the last 6 months with Farcry 4, Dragon Age 3, Alien Isolation and Forza Horizon 2. Big, AAA technical-powerhouse games. And all of them more enjoyable than anything I've seen come out of the indie-sector.

    It is a commonly-held myth - but a myth nonetheless - that good graphics and good gameplay are mutually exclusive.

  23. Re:Frames by Darinbob · · Score: 1

    Context matters a lot here. When I see a good frame in a game, I am not moving so everything looks great. But that's for the sort of games I have. 30fps is definitely good enough for lots of things, in an MMO 15fps is probably good. However I guess for testosterone fueled shooter games that higher FPS makes a difference just because the view point is changing so rapidly.

    Basically I can't see the problem with 15-20fps unless I take the mouse and jiggle it back and forth rapidly, which is something never done in the games I play. But for those kids on the shooters they do that all the time, but then they're spending tons more on their computers than I would ever dream of.

    A big problem is lack of motion blur there, not necessarily the frame rate. Which is why TVs could run at a slower frame rate and with interlacing and you'd rarely notice it unless it was a fast paced sports game. But in a game the realism is just not at the point where the frame rate should matter, the extra realism isn't present even in a still frame. A bigger problem for me is hitching, which has nothing to do with frame rate but I have noticed online that a lot of players confuse hitching with having a substandard video card.

  24. Re:forget the gameplay! by Cochonou · · Score: 1

    Have you played Samurai Gunn ?

  25. Re:forget the gameplay! by RogueyWon · · Score: 1

    No, but I just looked at its Steam page and it looks like yet another pseudo-8-bit sprite art game. Local multiplayer oriented... no singleplayer to speak of and, looking at the trailer, nothing particular gripping about the concept either. Not interested.

    I'll stick to Farcry 4 and Tokyo Twilight Ghost Hunters for now, until Bloodborne comes out in a couple of weeks.

  26. Pretty amazing but who stole all the colors? by johncandale · · Score: 1

    Pretty amazing, Really. But why does it still look worse then a modded eldersign? Now that is so impressing shit. Also, who stole all the colors? The death of PC gaming was herald by brown and tan in every game.