Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Unreal Renders a Frame

interplayoflight.wordpress.com

Post reply on HN
Print view View original

81–90 of 167 posts

Re: How Unreal Renders a Frame

#81

Post by Impossible »

pandaman wrote: post #78
hyperpallium wrote: post #44

Earlier quoted context omitted.

I wonder what the turn-over is for engine programmers? I'd guess very low. I wonder how many commercial engine programmers there actually are, anyway? I'd guess very few.

Most AAA studios have "engine" programmers (they are called graphics programmers in the industry). Even if such a studio uses UE or some other licensed engine there are still programmers who are modifying it.

Graphics programming is not engine programming, although it can be viewed as a subset of it. Most large game studios have engine programmers that do very little graphics programming, if any. The majority of code in a game engine is not related to the renderer. I've worked in the industry on AAA and indie games and have worked in both roles, which are often different engineering teams.

Re: How Unreal Renders a Frame

#83

Post by hesdeadjim »

zfedoran wrote: post #66
pault wrote: 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.

I'm not sure about unreal engine, but for a general overview the "Game Engine Architecture" book is a great starting point.

That book is great, but it’s discussion of graphical techniques is shallow (by design, it’s an overview book). Real-time Rendering was the book given to me back when I was first learning game development:

http://www.realtimerendering.com/book.html

Re: How Unreal Renders a Frame

#84

Post by pandaman »

Impossible wrote: post #81
pandaman wrote: post #78

Earlier quoted context omitted.

Most AAA studios have "engine" programmers (they are called graphics programmers in the industry). Even if such a studio uses UE or some other licensed engine there are still programmers who are modifying it.

Graphics programming is not engine programming, although it can be viewed as a subset of it. Most large game studios have engine programmers that do very little graphics programming, if any. The majority of code in a game engine is not related to the renderer. I've worked in the industry on AAA and indie games and have worked in both roles, which are often different engineering teams.

I work in the industry now and had been since 90s. "Engine" roles, if exist, are for stuff like streaming, save/load etc. The thing described in TFA is graphics programming.

Re: How Unreal Renders a Frame

#85

Post by iainmerrick »

bflesch wrote: post #38
maccard wrote: post #8

Earlier quoted context omitted.

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…

I'm curious how you would relate in-browser WebGL performance vs. performance of native software such as Unreal. Is running it in a browser 10x worse? or 100x?

In principle WebGL should be competitive with OpenGL. Once it hits the GPU, it's the same.

Some of the bottlenecks in WebGL are:

- Javascript. Modern JS engines are great, so the overall speed can be good, but you're still missing things like 64-bit ints, SIMD and threads. (Do game engines make heavy use of threads though? I don't know, but many influential games programmers seem to be wary of them!)

- The WebGL -> OpenGL translation layer takes some time. In Chrome it sanity checks your input (which you definitely want in a browser! GPU drivers are very insecure) and executes it in a separate process. Not as expensive as you might think, especially if you minimize your draw calls, which is good practice anyway.

- WebGL is basically OpenGL ES 2.0 (and WebGL 2 is ES 3.0), which is missing some useful features of full OpenGL, and doesn't offer the low-level, low-overhead access of Vulkan or Metal.

Depending on what you're doing, I'd guess WebGL might be no more than 2x slower (assuming plenty of optimization work). Some fiddly things might be 10x slower, or just not possible at all within the WebGL API.

WebGL 2 has a lot of very important new features, but support for that still seems to be patchy, and it's only just catching up with mainstream mobile graphics. It's a generation behind Vulkan.

Apart from that, an AAA game will have massive amounts of graphical and audio assets. Delivering that over the network is a pain and HTML5 caching is a pain. Doable, but hardly comparable to just loading it from local storage.

Oh, and one more thing! A big game wants sound as well as graphics, and WebAudio is a mess. And audio mixing is typically done in a background thread, so that's one area where the lack of threads in JS is a real problem.

Overall WebGL is very nice, it was a great choice to follow OpenGL ES closely (security problems aside).

Re: How Unreal Renders a Frame

#86

Post by mrec »

royjacobs wrote: post #61
hyperpallium wrote: post #59

Earlier quoted context omitted.

We might also include engine component suppliers, such as Speed Tree, Physix, and (whoever makes) Bink Video.

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.

Re: How Unreal Renders a Frame

#87

Post by tzahola »

mrweasel wrote: post #13
2sk21 wrote: post #6

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

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.

The learning curve of game development is much steeper, especially if you want to create your own engine.

When programming with APIs like OpenGL or DirectX, you either know what you're doing and get everything right, or you get a completely black framebuffer and maybe some error codes. There's practically no in-between. For business applications you can get pretty convincing results just by throwing together some buttons and textboxes in NetBeans or Visual Studio.

Re: How Unreal Renders a Frame

#88

Post by iainmerrick »

peoplewindow wrote: post #53
bflesch wrote: post #38

Earlier quoted context omitted.

I'm curious how you would relate in-browser WebGL performance vs. performance of native software such as Unreal. Is running it in a browser 10x worse? or 100x?

WebGL isn't trying to be competitive with full blown game engines, is it? For one, game engines normally don't use OpenGL unless they have to. The GL drivers on PC tend to be very weak. High end games target Direct3D on Windows/Xbox and these days are moving to Vulkan/Metal, even on mobile. On Windows the GL driver situation is so bad that Chrome translates GL to Direct3D. This obviously will impose some overhead and…

WebGL isn't trying to be competitive with full blown game engines, is it?

Sure it is! Not right now maybe, but the web standards people working on it would love to be a viable platform for AAA games. Every so often they tout a new WebGL port of a well-known game as the harbinger of things to come.

Re: How Unreal Renders a Frame

#89

Post by smcl »

mschaef wrote: post #49
lordnacho wrote: post #14

This is why I don't get why the game industry has such a bad rep for overworking people. It's genuinely hard to do this kind of code so you'd think they take care not to scare away the few people who can do it. I recall at one point Goldmans was bragging to my team about how they'd hired a game dev to do their click-to-trade currency UI. Seemed like the guy found an easier job for more pay.

> Goldmans ... hired a game dev to do their click-to-trade currency UI. Seemed like the guy found an easier job for more pay. Not necessarily easier... but definitely a different set of difficulties.

I interpreted "easier" as in "I don't have to work 16+ hour days regularly"

Re: How Unreal Renders a Frame

#90

Post by fulafel »

lmm wrote: post #63
bflesch wrote: post #38

Earlier quoted context omitted.

I'm curious how you would relate in-browser WebGL performance vs. performance of native software such as Unreal. Is running it in a browser 10x worse? or 100x?

It's not going to be a simple constant factor. The ideal case will be the same - ultimately the CPU is doing the same work (so provided the JIT picks it up correctly it'll be executing the same instructions) and the GPU is running literally the same shaders, so performance should be identical. It's more a question of how much work you have to do to hit that happy path, and what edge cases pull you off it.

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.
Post reply on HN