Moana Motunui Renderer on GPU

328 点作者 Impossible超过 4 年前

16 条评论

dahart超过 4 年前

This out of core pipeline is a super cool idea! I work on OptiX and this is the first time I’ve seen someone try this kind of thing. There are different kinds of out of core rendering, and not all of them would be guaranteed to finish without running out of memory. This one is, as long as all the individual meshes can fit in GPU memory.Chris are you on HN? I am curious whether some savings might be possible here by not snapshotting the IASes and GASes. Instead you can snapshot only the raw geometry, and then rebuild the GASes and IASes before every launch. It may be faster to rebuild the BVHs than to copy them from CPU ram!*Oh incidentally looking through the code I also noticed that the GASes could be compacted which will save a lot of memory and time/bandwidth on the snapshot copies during rendering. Since you do compact the IAS, I am assuming it's problematic to try and compact the GASes?In any case, nice work!

评论 #24834956 未加载

fxtentacle超过 4 年前

Most of the comments in here seem to be missing the most important aspect.This is open source: <a href="https://github.com/chellmuth/gpu-motunui/" rel="nofollow">https://github.com/chellmuth/gpu-motunui/</a>Let me explain. GPU rendering of cinema quality scenes by itself is not that new. V-Ray GPU was around in 2013 and already had an impressive showreel back then: <a href="https://www.youtube.com/watch?v=RYPFY5OUzdk" rel="nofollow">https://www.youtube.com/watch?v=RYPFY5OUzdk</a>I'd count Octane and Redshift as the next big contenders, who together with V-Ray switching from perpetual to subscription pricing, took over the market. Here's an example of a Redshift render from 2016: <a href="https://www.youtube.com/watch?v=to8yh83jlXg" rel="nofollow">https://www.youtube.com/watch?v=to8yh83jlXg</a>Lately, Pixar has been handing out Renderman GPU betas, which has already been used in the new jungle book movie: <a href="https://youtu.be/tiWr5aqDeck?t=171" rel="nofollow">https://youtu.be/tiWr5aqDeck?t=171</a>Along with this development, the price has gone down. From $1200 per V-Ray license, to $600 per Redshift license and now it seems like the previously prohibitively expensive Pixar renderer will soon be offered for $500.And recently, people have been using Houdini ($6000 per seat) to export their scenes as USD (free open file format) so that they can use Blender 2.81 for rendering (also free). But the conversion to get things into Blender is work. This renderer can use the Disney production data directly, which is very convenient if you want to drop it in at the last minute for cost saving.GPU rendering has gone from novelty in 2013 to established in 2016 to become the new default in 2018/2019. And this released as open source to me implies that the commercial renderer market will soon be dead. It looks "good enough" for advertisements and archviz, which is where the money is made.

评论 #24834937 未加载

andrew_超过 4 年前

I just have to say that this is really excellent work.Especially impressed as I've watched this movie at least 100 times over the last year. My 20 month old daughter is infatuated with it (not to worry, we usually limit viewing to a song-scene or two per sit down). The songs are involuntarily memorized and cries of "mana song" (sic) can be heard each time the toddler gets into the car. To the point that my wife, 3 month old daughter, the oldest, and myself are dressing up for Halloween as TeFiti, kakamora, Moana, and Maui, respectively.If the OP should see this - what prompted you to want to attempt it, was it just the availability of the dataset or were you drawn into the story by screaming children as well?

评论 #24835082 未加载

VikingCoder超过 4 年前

I've always wished Pixar would do what Id software did, releasing an Open Source version of some small portion of their movies for analysis, like this Moana scene.Because the question on my mind is, given the improvements in rendering, there's some year in which we can now render in real time, what took a long time for Pixar to render.So, what is it? I believe I read that creating the 3D version of Toy Story ran at 24 fps, averaged across the entire film. So, basically, we already crossed the threshold for Toy Story. (But maybe that was only if you have a rendering farm?)So, where are we at? Could we render a plausible Toy Story in real time now? Bug's Life? Monsters Inc?

评论 #24834472 未加载

评论 #24836235 未加载

TomVDB超过 4 年前

If I understand this correctly, he renders the whole scene in batches to reduce the memory requirements.Since this is path tracing, how does this work in terms of instances from one batch influencing the lighting of a different batch?

评论 #24834361 未加载

timClicks超过 4 年前

In case anyone was wondering, "Moana" means sea/lake and "Motunui" means "big island" in many languages of the Pacific.

评论 #24834752 未加载

packetslave超过 4 年前

A couple of other attempts at rendering the Moana scene with something other than Hyperion:- Matt Pharr (author of pbrt) -- 6 part series: <a href="https://pharr.org/matt/blog/2018/07/08/moana-island-pbrt-1.html" rel="nofollow">https://pharr.org/matt/blog/2018/07/08/moana-island-pbrt-1.h...</a>- Joe Schutte (WDAS): <a href="https://schuttejoe.github.io/post/disneybsdf/" rel="nofollow">https://schuttejoe.github.io/post/disneybsdf/</a>

评论 #24840381 未加载

moyix超过 4 年前

Matt Pharr recently released an early version of PBRTv4, which has been rewritten extensively to make heavy use of Optix and the GPU. Given that he previously wrote a series on rendering Moana using PBRTv3, I wonder if v4 could be used as a comparison?<a href="https://pharr.org/matt/blog/2020/08/19/pbrt-v4-released.html" rel="nofollow">https://pharr.org/matt/blog/2020/08/19/pbrt-v4-released.html</a>

skunkworker超过 4 年前

Frankly that is incredible that they were able to get the scene to render in only 5 hours per frame on just a single 2070 with 8gb VRam

评论 #24834044 未加载

mrb超过 4 年前

I was comparing the reference images with the rendered ones, and this tree is not at the same location: <a href="https://imgur.com/a/JIpgAb8" rel="nofollow">https://imgur.com/a/JIpgAb8</a> Some low vegetation (grass) under the palm tree on the left is also absent.Is this part of the limitations the author discloses?: «Other features of the scene are possible to render but out of my initial scope, notably subdivision surfaces and their displacement maps, and a full Disney BSDF implementation»

评论 #24836684 未加载

boulos超过 4 年前

Nice work!In addition to dahart’s suggestions, I’d be curious to see some of your profiling that you did. Like, what’s the breakdown of the timing now? Are you PCIe limited, or have you overlapped the I/O with enough compute that it’s only XX% overhead?How much memory do you need for all the geometry and BVHs? (Particularly post compression). I’m curious if this just barely fits on an A100 or similar.Again, nice work!

评论 #24838961 未加载

CamperBob2超过 4 年前

Interesting. The CPU-based texture lookups sound murderous, though. Why not convert the PTEX textures to a format the GPU can handle?

评论 #24834259 未加载

评论 #24834291 未加载

corysama超过 4 年前

The References at the bottom are all also excellent articles. The "Swallowing/Digesting the Elephant" pair are about simply getting the scene to load.

ahupp超过 4 年前

This is really cool work. What kind of speedup does the GPU give for this kind of workload, e.g how long does a CPU-only implementation take?

评论 #24837854 未加载

etaioinshrdlu超过 4 年前

Is this work sponsored by anyone, or for a competition, or is it just for fun?

评论 #24835107 未加载

virtualritz超过 4 年前

This looks mostly like an academic or 'for fun' exercise. People run Doom on their fridge for fun so why not squeeze the Moana asset through the bottleneck that sits between your CPU and your GPU? :)Is it practical/useful? Let's put the timing in perspective.A commercial CPU production renderer, 3Delight, has timing for the Moana asset rendered at 4k on their website.[1]Time: ~34 minutes.I asked them for details about the settings they used before posting this as the page only lists resolution.4k resolution, 64 (shading) samples per pixel (spp), ray depths: diffuse 2, specular 2, refraction 4 (or 3, 3, 5, depending how you count ray depth). Machine was a contemporary 24 core server at the end of 2018. Mind you, the image is fine with 64 spp. Spp are hard to compare between renderers because optimizing path tracers is a lot about sampling. One renderer will converge to something useable with 1k samples while another just needs 64.The 3Delight example is rendering all the geometry as subdivision surfaces with displacement (and their own Ptex implementation for texture lookups).Timing comparisons of a different scene with recent 24core desktop AMD CPUs suggest that this asset would render much faster in 2020.[2]The timing shows the issue with GPUs vs CPUs for this kind of assets. 5h for a 1k (!) resolution image with <= 5 bounces and 1024 spp (samples per pixel). That is terrible. Not using the real (subdivision) geometry and not using displacement.I would love to see a breakdown how much of these 5hs is owed to the fact that the data doesn't fit on the device.Using subdivision surfaces and displacement mapping make the amount of geometry grow exponentially. I.e. the out of core handling would predictably take an exponentially larger part of the render time.Looking at the numbers I regularly get to see when counseling VFX companies on their rendering pipelines I don't see GPU offline rendering going anywhere for complex scenes. And even for simpler scenes where GPUs have an advantage still – with the CPUs AMD is putting out recently the gap is becoming very tight and if you do the math you often pay dearly for having an image a few minutes earlier (not even double digit minutes or hours earlier). Regardless of what Nvidia's marketing and some vendors who IMHO wasted years optimizing their renderers for a moving hardware target may want you to believe.Regarding the latter: another point to consider is that you need to spend time working with/around the hardware limitations/bottlenecks of GPUs for this very the "scene doesn't fit on device" use case. Someone writing a CPU renderer can spend that time working on the actual renderer itself. This kind of software takes years to develop. Go figure.Finally, as I expect this to be downvoted because of what I just said: don't take my word for any of the above. Just try it yourself.The Moana Asset can be downloaded at [3]. A script to convert the entire asset and launch a 3Delight render can be had at [4]. The unlimited core version of the renderer can be downloaded for free, after registering with your email, at [5].It renders with any number of cores your box has but it adds a watermark if no license is available.Or you thy their cloud rendering. You get 1,000 free 24 core server minutes. Which is plenty to run this test.[1] <a href="https://www.3delight.com/documentation/display/3DLC/Cloud+Rendering+Speed" rel="nofollow">https://www.3delight.com/documentation/display/3DLC/Cloud+Re...</a>[2] <a href="https://www.3delight.com/page/features/2020-10-06-CPUbenchmark" rel="nofollow">https://www.3delight.com/page/features/2020-10-06-CPUbenchma...</a>[3] <a href="https://disneyanimation.com/resources/moana-island-scene/" rel="nofollow">https://disneyanimation.com/resources/moana-island-scene/</a>[4] <a href="https://gitlab.com/3Delight/moana-to-nsi" rel="nofollow">https://gitlab.com/3Delight/moana-to-nsi</a>[5] <a href="https://www.3delight.com/download" rel="nofollow">https://www.3delight.com/download</a>

评论 #24849446 未加载