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

Pixar's Render Farm

twitter.com

Post reply on HN
Print view View original

61–70 of 323 posts

Re: Pixar's Render Farm

#61

Post by berkut »

ChuckNorris89 wrote: post #9
klodolph wrote: post #3

My understanding (I am not an authority) is that for a long time, it has taken Pixar roughly an equal amount of time to render one frame of film. Something on the order of 24 hours. I don’t know what the real units are though (core-hours? machine-hours? simple wall clock?) I am not surprised that they “make the film fit the box”, because managing compute expenditures is such a big deal! (Edit: When I say "simple wall…

Wait, what? 24 hours per frame?! At the standard 24fps it takes you 24 days per film second which works out to 473 years for the average 2 hour long film which can't be right.

In high-end VFX, 12-36 hours (wall clock) per frame is a roughly accurate time frame for a final 2k frame at final quality.

36 is at the high end of things, and the histogram is more skewed towards the lower end than > 30 hours, but it's relatively common.

Frames can be parallelised, so multiple frames in a shot/sequence are rendered at once, on different machines.

Re: Pixar's Render Farm

#62

Post by dagmx »

supernova87a wrote: post #53

I would love to know about some curious questions, for example: If there's a generally static scene with just characters walking through it, does the render take advantage of rendering the static parts for the whole scene once , and then overlay and recompute the small differences caused by the moving things in each individual sub frame? Or, alternatively what "class" of optimizations does something like that fall in…

If you're interested in production rendering for films, there's a great deep dive into all the major studio renderers https://dl.acm.org/toc/tog/2018/37/3

As for your questions:

> Is rendering of video games more similar to rendering for movies, or VFX?

This question is possibly based on an incorrect assumption that feature (animated) films are rendered differently than VFX. They're identical in terms of most tech stacks including rendering and the process is largely similar overall.

Games aren't really similar to either since they're raster based rather than pathtraced. The new RTX setups are bringing those worlds closer. However older rendering setups like REYES that Pixar used up until Finding Dory, are more similar to games raster pipelines. though that's trivializing the differences.

A good intro to rendering is reading Raytracing in a Weekend (https://raytracing.github.io/books/RayTracingInOneWeekend.ht...), and Matt Pharr's PBRT book (http://www.pbr-book.org/)

Re: Pixar's Render Farm

#63

Post by klodolph »

brundolf wrote: post #29
chrisseaton wrote: post #24

Earlier quoted context omitted.

Why can’t it be simple wall-clock time? Each frame takes 24 hours of real wall-clock time to render start to finish. But they render multiple frames at the same time. Doing so does not change the wall-clock time of each frame.

In my (hobbyist) experience, path-tracing and rendering in general are enormously parallelizable. So if you can render X frames in parallel such that they all finish in 24 hours, that's roughly equivalent to saying you can render one of those frames in 24h/X. Of course I'm sure things like I/O and art-team-workflow hugely complicate the story at this scale, but I still doubt there's a meaningful concept of "wall-cloc…

I suspect hobbyist experience isn't relevant here. My experience running workloads at large scale (similar to Pixar's scale) is that as you increase scale, thinking of it as "enormously parallelizable" starts to fall apart.

Re: Pixar's Render Farm

#64

Post by rconti »

naikrovek wrote: post #50
happytoexplain wrote: post #19

Earlier quoted context omitted.

Thank you. All I saw was a post with zero context, followed by a reply, followed by another reply using a different reply delineator (a horizontal break instead of a vertical line??), followed by nothing. It just ends. It's hard to believe this is real and intended.

It's amazing to me that people find twitter difficult to read... I mean it's not perfect but it's not an ovaltine decoder ring, either. Just ... Scroll ... Down ... Click where it says "read more" or "show more replies" You're human; THE most adaptable creature known. Adapt! I'm not saying that twitter UX is perfect, or even good. I AM saying that it is usable.

It's very unintuitive that when you open a Thread, the "back" arrow means "back to something else" and you have to scroll up above "line 0" to see the context of the thing being replied to. I forget this every single time I open a tweet thread and try to figure out the context.

Once you scroll up, it sort of makes sense -- each tweet with a line connecting user icons but then suddenly the expanded tweet thread has the main tweet in a larger font, then the "retweet/like" controls below it, THEN another line of smaller-font tweets that comprise the thread. Then you get some limited number and have to click "more" for more.

The monochrome of it all reminds me of when GMail got rid of the very helpful colors-for-threads and went to grey on grey on grey.

It's not visually apparent at all.

Re: Pixar's Render Farm

#65

Post by xtracto »

naikrovek wrote: post #50
happytoexplain wrote: post #19

Earlier quoted context omitted.

Thank you. All I saw was a post with zero context, followed by a reply, followed by another reply using a different reply delineator (a horizontal break instead of a vertical line??), followed by nothing. It just ends. It's hard to believe this is real and intended.

It's amazing to me that people find twitter difficult to read... I mean it's not perfect but it's not an ovaltine decoder ring, either. Just ... Scroll ... Down ... Click where it says "read more" or "show more replies" You're human; THE most adaptable creature known. Adapt! I'm not saying that twitter UX is perfect, or even good. I AM saying that it is usable.

Twitter was designed to have 280 characters max per message. This means that for this kind of long format text, the amount of Signal-to-Noise ratio of having a large number of "tweets" is pretty low.

The amount of stuff your brain has to filter in the form of user name, user tweet handle, additional tagged handlers, UI menus, UI buttons for replying, retweeting, liking, etc on every single code snippet makes your brain work way more than it should to read a page of text.

Just imagine if I had written this exact text in 3 separate HackerNews comments, and prepended each with a 1/ 2/ 3/ text, in addition to all the message UI, it would have been more difficult to read than a simple piece of text.

Re: Pixar's Render Farm

#66

Post by daxfohl »

nom wrote: post #34

Oh man, I wanted this to contain much more details :( Whats the hardware? How much electric energy goes into rendering a frame or a whole movie? How do they provision it (as they keep #cores fixed)? They only talk about cores, do they even use GPUs? What's running on the machines? What did they optimize lately? So many questions! Maybe someone from Pixar's systems department is reading this :)?

And when leasing cores, who do they lease from and why?

Re: Pixar's Render Farm

#67

Post by supernova87a »

dagmx wrote: post #62
supernova87a wrote: post #53

I would love to know about some curious questions, for example: If there's a generally static scene with just characters walking through it, does the render take advantage of rendering the static parts for the whole scene once , and then overlay and recompute the small differences caused by the moving things in each individual sub frame? Or, alternatively what "class" of optimizations does something like that fall in…

If you're interested in production rendering for films, there's a great deep dive into all the major studio renderers https://dl.acm.org/toc/tog/2018/37/3 As for your questions: > Is rendering of video games more similar to rendering for movies, or VFX? This question is possibly based on an incorrect assumption that feature (animated) films are rendered differently than VFX. They're identical in terms of most tech st…

Thanks!

(I was also reading the OP which says "...Our world works quite a bit differently than VFX in two ways..." hence my curiosity)

Re: Pixar's Render Farm

#68

Post by aprdm »

mmcconnell1618 wrote: post #40

Can anyone comment on why Pixar uses standard CPU for processing instead of custom hardware or GPU? I'm wondering why they haven't invested in FPGA or completely custom silicon that speeds up common operations by an order of magnitude. Is each show that different that no common operations are targets for hardware optimization?

FPGA is really expensive for the scale of a modern studio render farm, we're talking around 40~100k cores per datacenter. Because 40~100k cores isn't Google scale either it also doesn't seem to make sense to invest in custom silicon.

There's a huge I/O bottleneck as well as you're reading huge textures (I've seen textures as big as 1 TB) and writing constantly to disk the result of the renderer.

Other than that, most of the tooling that modern studios use is off the shelf, for example, Autodesk Maya for Modelling or Sidefx Houdini for Simulations. If you had a custom architecture then you would have to ensure that every piece of software you use is optimized / works with that.

There are studios using GPUs for some workflows but most of it is CPUs.

Re: Pixar's Render Farm

#69

Post by lattalayta »

mmcconnell1618 wrote: post #40

Can anyone comment on why Pixar uses standard CPU for processing instead of custom hardware or GPU? I'm wondering why they haven't invested in FPGA or completely custom silicon that speeds up common operations by an order of magnitude. Is each show that different that no common operations are targets for hardware optimization?

Pixar renders their movies with their commercially available software, Renderman. In the past they have partnered with Intel [1] and Nvidia [2] on optimizations

I'd imagine another reason is that Pixar uses off-the-shelf Digital Content Creation apps (DCCs) like Houdini and Maya in addition to their proprietary software, so while they could optimize some portions of their pipeline, it's probably better to develop for more general computing tasks. They also mention the ability to "ramp up" and "ramp down" as compute use changes over the course of a show

[1] https://devmesh.intel.com/projects/supercharging-pixar-s-ren...

[2] https://nvidianews.nvidia.com/news/pixar-animation-studios-l...

Re: Pixar's Render Farm

#70

Post by naikrovek »

xtracto wrote: post #65
naikrovek wrote: post #50

Earlier quoted context omitted.

It's amazing to me that people find twitter difficult to read... I mean it's not perfect but it's not an ovaltine decoder ring, either. Just ... Scroll ... Down ... Click where it says "read more" or "show more replies" You're human; THE most adaptable creature known. Adapt! I'm not saying that twitter UX is perfect, or even good. I AM saying that it is usable.

Twitter was designed to have 280 characters max per message. This means that for this kind of long format text, the amount of Signal-to-Noise ratio of having a large number of "tweets" is pretty low. The amount of stuff your brain has to filter in the form of user name, user tweet handle, additional tagged handlers, UI menus, UI buttons for replying, retweeting, liking, etc on every single code snippet makes your bra…

You all are perfect delicate flowers that need things to be just right in order to use them, then? Is that what you're saying?

Because that's what I'm getting from you.

Post reply on HN