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

251–260 of 323 posts

Re: Pixar's Render Farm

#251

Post by ganafagol »

nikolay wrote: post #206
npunt wrote: post #123

Earlier quoted context omitted.

As a reading medium seeing a bunch of tweets strung together is not fantastic as implemented today. As an authoring medium though, the character constraints force you to write succinct points that keep the reader engaged. You can focus your writing just on one point at a time, committing to them when you tweet, and you can stop anytime. If you're struggling with writing longer form pieces a tweet thread is a great on…

Really? I don't like that Twitter makes me to reword and abbreviate words, just because I'm 2 characters over! Any medium (pun intended) has the concept of paragraphs, but does not typically limit you how long the paragraph is. It could guide you not to go overboard, but to force you to a certain made-up character limit - it's not really acceptable in 2021.

You need to realize that the character limit was the defining feature of Twitter. There are many platforms where grumpy uncle could dump a wall of text with his views, but nobody was attracted to another one of those. In today's attention economy, limiting expressions of thought was exactly the right thing.

Re: Pixar's Render Farm

#252

Post by greggman3 »

saagarjha wrote: post #221
nikolay wrote: post #96

Earlier quoted context omitted.

Yeah, I've never seen any value in Twitter. They should've called it "Public IM" or limited IIRC and make it function well like IM. Even the poor implementation of threads in Slack is way better than the perverted version of Twitter.

> I've never seen any value in Twitter. Except for the information that doesn't show up on other platforms, which is why it is a frequently linked site here?

That value is in the content, not twitter itself

Re: Pixar's Render Farm

#253

Post by greggman3 »

corysama wrote: post #118
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?

Not an ILMer, but I was at LucasArts over a decade ago. Back then, us silly gamedevs would argue with ILM that they needed to transition from CPU to GPU based rendering. They always pushed back that their bottleneck was I/O for the massive texture sets their scenes through around. At the time RenderMan was still mostly rasterization based. Transitioning that multi-decade code and hardware tradition over to GPU would…

AFAIU the issue with GPU rendering is generally you have to design the assets to be GPU friendly. So while you can get a huge speed up at rendering time you get a huge slowdown creating the assets in the first place because you have new issues. Using normal maps and displacement maps instead of millions of polygons. Keeping textures to the minimal size that will get the job done, etc...

Is any of that true?

Re: Pixar's Render Farm

#254

Post by forelle2 »

CyberDildonics wrote: post #121
aprdm wrote: post #85

Earlier quoted context omitted.

Can be either. You usually have digital artists creating them. https://en.wikipedia.org/wiki/Texture_artist

Texture artists aren't painting 1 terabyte textures dude.

The largest texture sets are heading towards 1TB in size, or at least they were when I was last involved in production support. I saw Mari projects north of 650gb and that was 5 years ago. Disclaimer : I wrote Mari, the vfx industry standard painting system.

Note though these are not single 1TB textures, they’re multiple sets of textures, plus all of the layers that constitute them. Some large robots In particular had 65k 4K textures if you count the layers.

Re: Pixar's Render Farm

#255

Post by adamjb »

nikolay wrote: post #47
hadrien01 wrote: post #10

For those that can't stand Twitter's UI: https://threadreaderapp.com/thread/1345146328058269696.html

It's very painful to follow a conversation on Twitter. I'm not sure why they think the way they've done things makes sense.

I used to feel the same way until I decided to actually use my twitter account on a regular basis, which probably means it's on some level objectively terrible. But now I've learnt the logic of how to navigate twitter I find it very intuitive.

Twitter have tried to have their cake and eat it too by allowing a reddit or hn style tree (which is good for discussions) while having their ui present it as a linear feed (which is good for engagement). This has lead to their current solution where the branches are presented in a choose your own adventure way. Now because the linked tweet has three replies, it has to show all three of them and leave it to you to select which branch you want to go down by clicking on it or the show replies prompt (though it does give primacy to pixprin's replies to self).

Re: Pixar's Render Farm

#257

Post by malthejorgensen »

tinco wrote: post #138
aprdm wrote: post #75

Earlier quoted context omitted.

Not Pixar specifically but Modern VFX and Animation studios usually have a bare metal render farm, they usually are pretty beefy -- think at least 24 cores / 128 GB of RAM per node. Usually in crunch time if there's not enough nodes in the render farm they might rent nodes connecting them to their network for a period of time, or they might use the cloud, or they might get budget to increase their render farms. From…

Can confirm cloud GPU is way overpriced if you're doing 24/7 rendering. We run a bare metal cluster (not VFX but photogrammetry) and I pitched our board on the possibilities. I really did not want to run a bare metal cluster, but it just does not make sense for a low margin startup to use cloud processing. Running 24/7 for three months, it's cheaper to buy consumer grade hardware with similar (probably better) perfor…

How do you manage the bare metal cluster? (E.g. apt/yum updates but also networking and such)

Re: Pixar's Render Farm

#258

Post by capableweb »

klodolph wrote: post #188
capableweb wrote: post #145

Earlier quoted context omitted.

> It's not like you can just slice the frame into rectangles and farm them out. Funny thing, you sure can! Distributed rendering of single frames been a thing for a long time already.

What about GI? You can't just slice GI into pieces.

How I've seen it work in the past, it'll totally work with GI (and more generally, raytracing). If the frame to be rendered is CPU bound rather than I/O (because of heavy scenes), the whole project would be farmed out to the works, so they have a full copy of what's to be rendered, then resize which part of the frame to be rendered by them. Normally this would happen locally, and if you have 8 CPU cores, each one of them get responsible for a small size of the frame. Now if you're doing distributed rendering, replace CPU core with a full machine, and you have the same principle.

Obviously doesn't work for every frame/scene/project, only if the main time is spent on actual rendering with CPU/GPU. Most of the times when doing distributed rendering, CPU isn't actually the bottleneck, but rather transferring the necessary stuff for the rendering (project/scene data structures that each worker needs).

Re: Pixar's Render Farm

#260

Post by fluffy87 »

berkut wrote: post #125
dahart wrote: post #117

Earlier quoted context omitted.

> Because the expense is not really worth it I disagree with this takeaway. But full disclosure I’m biased: I work on OptiX. There is a reason Pixar and Arnold and Vray and most other major industry renderers are moving to the GPU, because the trends are clear and because it has recently become ‘worth it’. Many renderers are reporting factors of 2-10 for production scale scene rendering. (Here’s a good example: https…

I write a production renderer for a living :) So I'm well aware of the trade offs. As I mentioned, for lookdev and small scenes, GPUs do make sense currently (if you're willing the pay the penalty of getting code to work on both CPU and GPU, and GPU dev is not exactly trivial in terms of debugging / building compared to CPU dev). But until GPUs exist with > 64 GB RAM, for rendering large scale scenes, it's just not w…

There are already GPUs with >90GB RAM? DGX-A100 has a version with 16 A100 GPUs, having each 90 Gb.. that’s 1.4TB of GPU memory on a single node.
Post reply on HN