Live data from Hacker News

How Unreal Renders a Frame

interplayoflight.wordpress.com

111–120 of 167 posts

Re: How Unreal Renders a Frame

#111
post #46

Does anyone know of a good book or course that does a deep dive into unreal engine source? I'm trying to level up my graphics programming skills and that seems like it would be an amazing reference, but I don't currently have the knowledge to navigate it myself.

Don't think there is any such book specifically for UE and its source. But there's a lot of good books on realtime rendering and graphics programming in general.

GPU Gems, Shader X and GPU Pro are good series for learning specific graphics programming techniques.

https://developer.nvidia.com/gpugems/GPUGems/gpugems_pref01....

http://www.realtimerendering.com/resources/shaderx/

For a general game engine overview: Game Engine Architecture by Jason Gregory (Naughty Dog)

Game Programming Patterns: https://www.amazon.co.uk/Game-Programming-Patterns-Robert-Ny...

Realtime rendering overview: https://www.amazon.co.uk/Real-Time-Rendering-Third-Tomas-Ake...

Related math: https://www.amazon.co.uk/Math-Primer-Graphics-Game-Developme...

Other recommendations:

http://mrelusive.com/books/books.html

http://fabiensanglard.net/Computer_Graphics_Principles_and_P...

It's fun to explore the source though, and NVIDIA has some cool experimental branches of the engine with their stuff integrated. https://github.com/NvPhysX/UnrealEngine

Re: How Unreal Renders a Frame

#112
post #8
post #6

So all of this processing happens for one frame? And this is going on at 60 Hz?

Yes, and more. You’ve also got a rigid body (physics) simulation, ai/pathfinding, animation, networking, audio and gameplay logic all to run. If you’re making an open world game, you also need to have streaming code to load and unload parts of the game on the fly. It doesn’t always happen at 60hz (which is 16ms total processing time for all the above plus what’s in the post). Some games run at 30hz(33ms), some run un…

That's not exactly actually (UE VR dev here). When you render a game at 90hz (or 60 or really anything), that means your total throughput needs to be 90hz, NOT that the frame needs to render in 11ms.

Since you're dealing with multithreaded CPUs + an asynchronous GPU, you can parallelize and sequentialize all this. How UE works in its DX11 and OpenGL renderers, on a 90hz game, is that you're gonna have the Game Thread (Physics/Gameplay) running for frame N, while the Render Thread (GPU commands / math ) runs for frame N-1, while the GPU executes frame N-2. This allows you a complete frame time of 33ms on a throughput of 90hz, at the cost of more latency.

Re: How Unreal Renders a Frame

#113
post #86

Earlier quoted context omitted.

Bink is made by the awesome Rad Game Tools. They have some really good engineers on their payroll (ryg, cbloom) and they're consistently churning out cool things :) (Disclaimer: Not affiliated, but I enjoy reading their developer's blogs)

I didn't realize cbloom was a Rad person too. His "Library Writing Realizations" rant is both a) awesome and b) really hard to link to. If you haven't seen it, go to http://cbloom.com/rants.html and search for the title.

I'd never heard of cbloom or his rants. That was an excellent read, thanks for sharing!

Re: How Unreal Renders a Frame

#114
post #103
post #90

Earlier quoted context omitted.

The CPU is going to do some more work because WebGL can't allow the GL app to crash the machine or break into the OS kernel, which regrettably current OpenGL (And DirectX, And Metal, and Vulkan...) drivers allow.

Allowing a userspace application to crash the machine or break into the OS kernel is also a security violation that needs to be prevented; the consequences are less severe than when a web page does it, but it still shouldn't happen. So that should also be the same work in either case.

I agree with the "should" of course - the state of GPU drivers is just horrible and shows no signs of rapid improvement.

Re: How Unreal Renders a Frame

#115
post #97

Earlier quoted context omitted.

> Do game engines make heavy use of threads though? Boy do they, yes.

Can you go into more detail? (Or point me at some up-to-date books or blog posts!) I'm specifically curious about CPU-intensive stuff that is sharded out to multiple threads. That's your classic multithreaded programming, the sort of thing you'd do in scientific computing, but I always got the impression games people were skeptical about it, due to unpredictable performance and the high risk of bugs.

Not an expert, but the version of it that I've heard is your main game loop handles all interaction with the game state to avoid issues. You can offload rendering into another thread pretty safely, and anything that alters game state would queue up its state changes for batch processing.

That way if you're running a multithreaded physics simulation you can get two separate bullet collision detections on one object, and instead of trying to delete the object twice you put both "kill this thing" actions on a to-do list. When it comes time to handle that in the main loop, you sweep through it for conflicts before executing any of the changes.

UE4 in particular I know handles all game logic in a single thread, and you can't touch UObjects from outside of that. But here's an example (without much technical detail) of someone implementing multithreaded pathfinding for UE4: https://forums.unrealengine.com/community/work-in-progress/1...

Re: How Unreal Renders a Frame

#116

I'm a little surprised at how surprised people are here, at how much work is done per frame! Sure, game engines are really complex and impressive, but the same is true of a lot of other kinds of software. If you work on websites, have you thought about how much processing goes on when loading and rendering a page?

How much work the parsers, layout engine and renderer have to do in a browser is far more opaque than what a game engine does. For game engines there is a lot of material out there explaining the basic processes and data flows; there are free or open source games and game engines around as well: Unreal engine, used in the article, is free, including full access to the source code. (This is by far the most widely used…

UE4 is not the most widely used game engine in the industry. That would be Unity by a wide margin.

If you are restricting to AAA, I’m not even sure if that holds. There are a good amount of big teams that use UE4, I think I’d go with Frostbite due to the sheer amount of titles that EA pushes out that are now based on Frostbite. It’s certainly more big games than UE4 is shipping. I’d probably put Ubisoft ahead of them too with their internal engines.

Re: How Unreal Renders a Frame

#117
post #86

Earlier quoted context omitted.

I didn't realize cbloom was a Rad person too. His "Library Writing Realizations" rant is both a) awesome and b) really hard to link to. If you haven't seen it, go to http://cbloom.com/rants.html and search for the title.

I'd never heard of cbloom or his rants. That was an excellent read, thanks for sharing!

[deleted]

Re: How Unreal Renders a Frame

#118
post #86

Earlier quoted context omitted.

I didn't realize cbloom was a Rad person too. His "Library Writing Realizations" rant is both a) awesome and b) really hard to link to. If you haven't seen it, go to http://cbloom.com/rants.html and search for the title.

I'd never heard of cbloom or his rants. That was an excellent read, thanks for sharing!

If you haven't read ryg's blog, you should. https://fgiesen.wordpress.com/

Re: How Unreal Renders a Frame

#119

Earlier quoted context omitted.

I'm completely fascinated that games can perform massive amounts of math and render 120 frames per second, while some business applications fail to do completely basic data manipulation in an reasonable time frame.

Data flow, data flow, data flow. It's all about structuring your data such that don't don't cache miss on your fetches and you don't stall your pipelines by doing operations that flush/occupy the same pipe. You can easily see 10-50x performance boosts on the same dataset with the right approach. Look up Data Oriented Design, Mike Acton talks about it a ton.

To expand slightly, a single read from memory that's not cached and actually has to go to RAM can take 100 cycles. That's 100 cycles during which your CPU does nothing but wait for electrical signals to travel to and from RAM. Well written data processing programs (game engines, physics simulations &c) strive to structure their data so they have as few of those as possible. If you just read "Design Patterns" and wrote a beautiful 10-level deep class hierarchy in Java, where every object access can be behind something like 3 levels of indirection via pointers.

This is not a critique against either Design Patterns or Java, both of them are important and useful. And really, quite often you don't care about waiting 100 cycles, you have ten million times 100 cycles in every second. It's when you start crunching numbers in large quantities that it can get problematic. Modern CPUs are very fast, but only if you feed them data in the right order. Otherwise you're basically running on a machine from 20 years ago, just with 32GB of RAM. Best program design right now is to yes, do write your deep class hierarchies and whatnot, but also know how to identify the parts of your program doing heavy computation and how to restructure those so you can unleash the full power of a modern processor.

Re: How Unreal Renders a Frame

#120
post #97

Earlier quoted context omitted.

> Do game engines make heavy use of threads though? Boy do they, yes.

Can you go into more detail? (Or point me at some up-to-date books or blog posts!) I'm specifically curious about CPU-intensive stuff that is sharded out to multiple threads. That's your classic multithreaded programming, the sort of thing you'd do in scientific computing, but I always got the impression games people were skeptical about it, due to unpredictable performance and the high risk of bugs.

Motivation: The Xbox360 pretty much forced gamedevs into heavy threading if they wanted to get anything done. It had 3 PowerPC cores with 2 hardware threads each. The cores had huge memory latency and no out-of-order execution. IBM's attitude about OOE was "Statically compile for a fixed target" and "Run 2 threads per core and that that'll cut the effective stall cycles per thread in half". The PS3 had only 1 of those PC cores, but it also had 6 unique cores that were practically high-power DSPs. If you manually pipelined data movement and vectorized execution, you could get amazing results. If you ignored those cores, the PS3 was crippled. The XBone and PS4 have friendlier cores, but they are still surprisingly low-power and there are 8 of them. So, you still need to thread and vectorize or you'll be dragging. Even on the PC, Sutter's "The Free Lunch is Over" is over 12 years old. Outside of games, the browsers force single-threading and cloud servers profit by selling multicore machines pretending to be many single-core machines. But, in games have to run on non-virtual hardware.

Execution: You can google around for "game engine job system", but unfortunately, game engine blogs have really fallen off a while back as most of that crew has moved to twitter. So, the best material out there is in the form of GDC presentations such as "Parallelizing the Naughty Dog engine using fibers", " Destiny's Multithreaded Rendering Architecture", "Multithreading the Entire Destiny Engine", "Killzone Shadow Fall: Threading the Entity Update on PS4". Slides and videos are available around the web.

Post reply on HN