Live data from Hacker News

How Unreal Renders a Frame

interplayoflight.wordpress.com

141–150 of 167 posts

Re: How Unreal Renders a Frame

#141

Earlier quoted context omitted.

I dont have an account so I can only see 1 review for each company. But it is a bit strange to say that only some reviews count and not the others. Of course most people care if you're being overworked for a small amount of compensation. Your statement is a bit ridicolous.

I'm not going to argue as I see you're trolling, but it takes 2 seconds to sign in and read the reviews. Most good reviews from Projekt Red for example are from full time employees who say they love working there, but then list cons such as: 'Economically things can get tough due to lower salaries' and 'I would not recommend this company for those who are not ready to push themselves and those who just want a 9 to 17…

I'm not trolling but you cant take 1 company and have their reviews as "this is how it is in the entire industry".

I don't want to sign in though, since that service offers nothing for me as a non american.

Re: How Unreal Renders a Frame

#142

Earlier quoted context omitted.

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…

It's difficult to measure game engine usage for AAA games since they can afford to

a) build their own internal engine

b) pay licensing fees to not disclose what engine they're using.

For overall game usage, however, I'd definitely say Unity is most used, with UE4 coming in second

Re: How Unreal Renders a Frame

#143
post #119

Earlier quoted context omitted.

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 wrot…

To clarify: "That's 100 cycles during which your CPU does nothing but wait..." is true only in the absolute worst case. In the likely case, your superscalar, out-of-order processor is working on the next several instructions, possibly including some speculative instructions after branches, and simultaneous-multithreading is letting another thread use the now-idle resources. Furthermore, since it's superscalar there are tons of compute resources (integer ALUs, FP ALUs, vector ALUs, to mention a few) which the CPU scheduler will try to keep busy as close to 100% of the time as possible.

That said, in any performance critical application, you pay close attention to your memory hierarchy and you design and compile your application in a way to respect that as well as take advantage of the underlying hardware architecture and resources to the fullest.

Re: How Unreal Renders a Frame

#144
post #96
post #6

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

(I havent read the whole article, but havent seen other replies mention this) Unreal uses an architecture called deferred rendering[1]. It's more complex, but allows for a lot more tricks and the main benefit is that lighting performance is closer to constant, instead of increasing or decreasing with how many lights you have. Forward rendering is the simpler alternative[2]. For Unreal, they had a forward renderer for…

"Forward+" is the typical term for the newer style of forward rendering which includes a special pass for optimizing large numbers of lights(the most appealing part of deferred).

Re: How Unreal Renders a Frame

#145
post #62
post #57

Earlier quoted context omitted.

Its kind of amazing how Unity forced change on Epic though. In the X360-PS3 era they absolutely _dominated_ the market, the list of games built on UE during that time is insane. However, after that, Unity started to come up as it had much nicer licensing and as a response to that Epic made UE almost free to use for small studios and more palatable for big ones.

I don't think Unity forced change on Epic, Unity targeted the nascent indie market very well and was a great replacement for the deprecated XNA. I can't think of a AAA Unity title aside from Microsoft's Recore - which launched with problems at $40. Epic's AAA market ended up with bigger budgets and a demand for more control, so many of them simply created their own engines. So most UE games seem to be big budget indi…

> I can't think of a AAA Unity title aside from Microsoft's Recore

Cities Skylines?

Re: How Unreal Renders a Frame

#146
post #119

Earlier quoted context omitted.

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 wrot…

To clarify: "That's 100 cycles during which your CPU does nothing but wait..." is true only in the absolute worst case. In the likely case, your superscalar, out-of-order processor is working on the next several instructions, possibly including some speculative instructions after branches, and simultaneous-multithreading is letting another thread use the now-idle resources. Furthermore, since it's superscalar there a…

> and simultaneous-multithreading is letting another thread use the now-idle resources.

This can actually be worse due to context switch overhead and caches you were using getting evicted by the now running thread hitting the same issue.

If you want to do this right you should be organizing your data so that the prefetcher and take advantage of it. All of those speculative things still have a cost.

Re: How Unreal Renders a Frame

#147

Earlier quoted context omitted.

Also the people who buy business apps are often not the people who actually have to use them every day. So UI/UX ends up being a much lower priority than say cost.

And, if the program processes data too quicky, users think it isn't working. (Managers, perhaps, think it isn't working hard enough.)

If that were the problem, we would solve it by adding sleep() calls...

Re: How Unreal Renders a Frame

#148

Earlier quoted context omitted.

Modern game engines parcel out work via a job system, where functional tasks are dispatched to the cores in a system. This is opposed to the idea of 'one core/thread will own a task for the lifetime of the application, while checking in with a master core/thread'. Actually, most games have a hybrid model. Usually one thread/core is dedicated to rendering, another thread/core is dedicated to high priority tasks/jobs,…

That threading style potentially fits OK with the JS "Web Worker" / "isolate" model, as long as you can pass messages around between threads/isolates very efficiently (probably not the case in current JS implementations).

There are Transferable objects (https://developer.mozilla.org/en-US/docs/Web/API/Transferabl...) so you at least don't have to serialize the data between workers.

Re: How Unreal Renders a Frame

#149
post #112

Earlier quoted context omitted.

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…

At some point the perception of the human eye means you cannot increase latency further. Especially if the game is something where reaction time is important, like a twitchy first person shooter. I wonder what the cutoff is where someone starts to notice, but I imagine it's not much greater than 50-100ms

Pretty sure it would be smaller than that.

I have a gaming display that has a 1ms response time, if I play something fast and twitchy on my PS4 (Titanfall 2 for example) on my display and then on my tv I can 100% notice the difference between the two, even when you adjust the tv to compensate (gaming mode on tv): you really do notice the extra time taken for events to occur. Titanfall 2 is actually a pretty good example because of the insane gameplay speed. Here's some examples: https://gfycat.com/FrayedTameDamselfly https://gfycat.com/BreakableWealthyBlowfish https://www.youtube.com/watch?v=o7ARc-lxc2s https://gfycat.com/FrailSaltyDanishswedishfarmdog https://gfycat.com/JubilantNeighboringAmericancrocodile

Post reply on HN