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

161–167 of 167 posts

Re: How Unreal Renders a Frame

#161

Post by MattRix »

ilaksh wrote: post #130

I personally believe much of this will become passe within five years or so. I have seen a few demos of real-time path tracing software running on GPUs. I know GPUs are fast, but I wonder if there is a way to do the same math on an ASICs or FPGA that could be even faster? The main issue with existing things seems to be being able to do enough iterations to get a clear picture. Anyway I believe a lot of the tricks rel…

Ehh, I'm kind of doubtful. I'm sure that stuff will get more popular, but it's not going to replace triangle-based rendering for MOST games for a very long time... especially since we're moving into the realm of VR where games need to render tons of pixels at very fast refresh rates.

Re: How Unreal Renders a Frame

#162

Post by iainmerrick »

vectorEQ wrote: post #156
iainmerrick wrote: post #93

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?

Hehe, this is only the rendering part per frame, imagine the AI computations and all other game logic also going , hopefuly within this magically 16ms time =] Game engines in my opinion are some of the most savage pieces of software, pushing performance and really testing programming concepts thoroughly. There's a lot of great knowledge comming from these guys regarding programming in other areas too because they are…

As a software person, I'm most impressed by CPU hardware -- all the crazy speculative out-of-order dynamic translation stuff that goes on at GHz timescales. It's astonishing that it works at all, let alone that it's almost 100% reliable.

Re: How Unreal Renders a Frame

#163

Post by robbies »

iainmerrick wrote: post #138
robbies wrote: post #135

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).

Oh interesting. TBH, I have zero knowledge on how to do any of this on the web side. All my experience is from working with traditional game engines on the native side.

Re: How Unreal Renders a Frame

#164

Post by mhink »

robbies wrote: post #163
iainmerrick wrote: post #138

Earlier quoted context omitted.

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).

Oh interesting. TBH, I have zero knowledge on how to do any of this on the web side. All my experience is from working with traditional game engines on the native side.

The worker pooling system you describe is eminently possible in the browser these days. Web Workers [1] are really just threads with a JS execution context and a facility for messaging back to the thread which created them. (Or, if you set them up with a MessageChannel [2], they can do full-duplex messaging with any thread that gets the other end of the pipe)

Of course, you're still dealing with the event loop in most cases, which is probably a stumbling block when it comes to really low-level stuff. That said, there are even facilities for shared memory and atomics operations [3] these days, which helps. I've messed around with it a little bit on a side project- as a JS developer, it's really weird and fun to say "screw the event loop!" and just enter an endless synchronous loop. :D

[1] https://developer.mozilla.org/en-US/docs/Web/API/Worker [2] https://developer.mozilla.org/en-US/docs/Web/API/MessageChan... [3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: How Unreal Renders a Frame

#165

Post by peoplewindow »

iainmerrick wrote: post #160
peoplewindow wrote: post #153

Earlier quoted context omitted.

Then why are they implementing an API that's been unpopular for years and is now being phased out entirely (for AAA games)? I think they're more concerned with the politics of it than the technical requirements of that userset. Games are heavy users of driver and card specific extensions for instance. But that'd be at odds with the web's portability commitments.

(I'm mostly playing devil's advocate here, I don't actually think HTML will be suitable for high-end games in the near future. But I think there are decent arguments to be made...) Then why are they implementing an API that's been unpopular for years and is now being phased out entirely (for AAA games)? Mobile. They picked OpenGL ES 2.0 for WebGL because it had comprehensively won on mobile. Apple went with ES 2.0 an…

I think your argument shows why the web is such a poor platform in many areas.

Second, there's no reason WebGL 3 couldn't be based on Vulkan

Vulkan is a very low level API designed for ultra-high performance use in engines written by professional engine teams, like Unreal. It requires the developer to write large quantities of code to even render a single triangle because you have to take manual control over the GPUs low level details. To a large extent it's preferred to GL because of better interaction with multi-threading.

It'd make no technical sense to try and expose a low level hardware-oriented API designed for multi-threading to a slow single-threaded language like JavaScript.

Do you pick the 3D standard used on Windows, or do you pick the lower-end one used by iOS and Android (and can be made to work on Windows)?

Somehow C++ does not have this problem. So how about: don't pick, expose all of them and let the developer use whichever is more appropriate?

You say you don't see any alternative to how WebGL handles driver extensions. Of course there are alternatives: just expose them all. Let there be vendor specific and proprietary stuff in web apps. Just because this is considered politically unacceptable by the ideologues who control the web platform does not mean it's actually unthinkable.

But that'd be against how the web is "designed" (browser makers cabalistically picking winners).

So in fact, I will continue to bet against the web and against mobile. People have been predicting total domination of iPhone/iPad since the day they were launched. I'll still be playing AAA games on consoles or high end Windows PCs 10 years from now, I'm sure of it.

Re: How Unreal Renders a Frame

#166

Post by dang »

staticelf wrote: post #34
hacker_9 wrote: post #18

Earlier quoted context omitted.

This is just capitalism at work; in the game industry there is no guaranteed reward at the end of the development cycle, so you have to keep up the pressure in order to beat out your competitors, and increase your chances of winning. This leads to crunching, 60 hour weeks and mass layoffs when you lose - lookup any of the top AAA game companies on Glassdoor and you will find they are awful places to work (Projekt Red…

Looked up several of the companies you mention and most of them have a pretty high ratings. EA is voted worst company by consumers, not by employees which is pretty misleading. Please stop lying.

> Please stop lying.

This breaks the HN guidelines. Please post civilly and substantively, or not at all.

Re: How Unreal Renders a Frame

#167

Post by iainmerrick »

peoplewindow wrote: post #165
iainmerrick wrote: post #160

Earlier quoted context omitted.

(I'm mostly playing devil's advocate here, I don't actually think HTML will be suitable for high-end games in the near future. But I think there are decent arguments to be made...) Then why are they implementing an API that's been unpopular for years and is now being phased out entirely (for AAA games)? Mobile. They picked OpenGL ES 2.0 for WebGL because it had comprehensively won on mobile. Apple went with ES 2.0 an…

I think your argument shows why the web is such a poor platform in many areas. Second, there's no reason WebGL 3 couldn't be based on Vulkan Vulkan is a very low level API designed for ultra-high performance use in engines written by professional engine teams, like Unreal. It requires the developer to write large quantities of code to even render a single triangle because you have to take manual control over the GPUs…

On a couple of specific points--

It'd make no technical sense to try and expose a low level hardware-oriented API designed for multi-threading to a slow single-threaded language like JavaScript.

Web Assembly will be mature soon, and on the timescales we’re speculating about it could well have some form of threading.

Let there be vendor specific and proprietary stuff in web apps.

Unfortunately that would be a security nightmare. The Flash and Java plugins are good examples.

Post reply on HN