My adventures getting Disney’s Moana island scene to render well with Pbrt | Hacker News Reader

My adventures getting Disney’s Moana island scene to render well with Pbrt

pharr.org

463 pointsdsr1245 comments

I love these stories of engineering and science from the trenches. Prefacing the story with "the early Pixar renderer was stupidly slow for silly archaic (and at the time sensible reason) X" followed by "luckily no-one is that silly anymore - except me, as an expert, did Y, which geez looks a lot like X" is a perfect start :) Not only is it an adventure you can join an expert in their field on but when told honestly it's a lovely reminder that everyone stumbles and drops the proverbial hammer on their foot occasionally.

It's also a loving testament to our era of content generation that a frequent task in creating a children's film is solving complex scientific or engineering problems. They recreate so many of the strange nuances and hidden beauty of our world (anisotropic rendering, Navier–Stokes equations, subsurface scattering, caustics, flocking, dendritic growth of snowflakes, global illumination, ...) just so they can render the purest representation of it for us.

I genuinely am so glad for the time I spent in art[1] and computer graphics, though neither have much relevance to my career now, simply as it changed the way I look at the world. When you want to try to recreate a real life scene from scratch you realize just how much happens in the real world without you ever appreciating it[1].

[1]: Even after the physics and science above: Do people frequently travel down this path? Might it become a holloway[2]? Does the roof guttering drain out here? There'll likely be moss or wearing paint. Old stone steps of an ancient tavern? The stone will likely be worn away at the center or on either side of the door. The background scenery in a modern computer graphics film has dozens or hundreds of hours in them and will be filled with nuance and/or in-jokes. If you need to create a background world in any appreciable detail, why not use it as a canvas to keep telling a story?

[2]: https://en.wikipedia.org/wiki/Sunken_lane

> I love these stories of engineering and science from the trenches.

I wish there was a website collecting all these stories and articles. They could also ask the authors for permission and offer epub/pdf downloads of these stories. That would be a nice read while traveling

"all these stories and articles"? There are millions of people working in software, the number of interesting war stories just within computer science is (conservatively) in the thousands. A distributed system of blogs is the only efficient way to publish that breadth of material, bearing in mind that each reader's interests are different, you can't curate a feed to suit everyone.

With all due respect, one convenient website aggregating all that material is not a practical idea. It's like asking for one huge magazine to exist which contains everything worth reading about a huge field like CS.

Edit: I mean, it would be convenient, but there's no royal road to finding stuff that's worth reading. https://queue.acm.org is pretty good, for example

It sounds like you're arguing that Netflix is not only impossible, but that it would be more impossible if it served text.

Netflix for text would be impossible. Netflix for movies is only possible because the overwhelming majority of decent movies are produced with the involvement of a relatively small number of production companies, and that in turn is the case because making a good movie is a much bigger exercise than making a good piece of text. It's highly unusual for one person to make a high-quality movie on their own and publish it directly on the internet, whereas this is entirely normal and common for text.

Your public library and services like Overdrive are "NetFlix for text".

NetFlix for text != zero curation, NetFlix curates their selection.

> Your public library and services like Overdrive are "NetFlix for text".

They're NetFlix for books and formal periodical publications, both of which are more movie-like: there are a relatively small number of publishers and publishing a full-length book is a substantial, multi-person project, as is publishing a magazine or newspaper. There's a huge wealth of text out there that has no chance of ever hitting any library or central seller/distributor of etexts.

> NetFlix curates their selection

Judging by the stuff that comes up when you browse categories, or when NetFlix wants to suggest something to you, the only "curation" involved is whether they were able to get rights to display the content. There's no quality standard, and there's no logical standard (like "if we offer the second film in this series, maybe we should offer the first one too") either.

You've clearly never been to my local public library - this is often how things are there - second and fourth book in a four book series there, first and third nowhere to be found.

In the case of a library, I would tend to suspect one of these scenarios:

- The first and third book are currently checked out.

- The library acquired all four books, but the first and third have been destroyed / lost / stolen by customers.

- The library didn't acquire any of the books, but the second and fourth were donated and the library chose to absorb them rather than selling or destroying them.

None of those are even conceptually applicable to NetFlix. I definitely would not expect

- The library has a limited budget, and considered that it would be better spent buying the second book than the first book.

Note that NetFlix's inventory of physical discs doesn't suffer from the same problems that its streaming inventory does. That is (most likely) because it's trivial to obtain the legal right to distribute the physical discs -- you just buy them on the open market, the same way a library does with its books. NetFlix's streaming inventory isn't "curated", it's not under NetFlix's control at all.

Maybe it's time someone brought back the concept of WebRings[1].

[1] https://en.wikipedia.org/wiki/Webring

There is a company, forgot the name, but I’ve seen the owner chime here on HN.

Yes, it's hard. And hard things shouldn't be done, or even tried.

Not the same thing, but your comment made me think of AOSA [0]

[0] http://aosabook.org/en/index.html

Based on your comment, I'm guessing you have, but on the off-chance you've not read Robert McFarlane's Landmarks, you should. https://www.goodreads.com/book/show/23597544-landmarks?from_...

This made me chuckle.

"However, some earlier phase of the production pipeline used a fixed-size buffer for storing object names and would shorten any longer names, keeping only the end and helpfully adding a few periods to show that something had been lost: “…year/LeftArm/Hand/IndexFinger/Knuckle2”.

Thence, all of the object names the renderer saw were of that form, the hash function hashed all of them to the bucket for ‘.’, and the hash table was actually a big linked list. Good times. "

If you'd like to learn more about pbrt (the renderer), I can recommend his comprehensive book Physically Based Rendering. It's used as a textbook in a lot of courses and doesn't assume CG knowledge above an introductory level.

How close are the renders to movie-accurate (that is, what's missing?)? Looking at e.g. [0], it seems to be missing a lot vs what is seen in the film. Are features missing compared to the original, were things missing from the scene description, or something else? The shorelines from screen stills in particular seem much more sophisticated [1].

[0] http://pharr.org/matt/blog/images/pbrt-moana-beach.jpg [1] https://vignette.wikia.nocookie.net/moana/images/e/e3/How_Fa...

The shorelines were likely rendered by in-house fluid dynamics simulation, and, likewise, the surface structures of the stones, sand and barks likely use in-house shaders which are far more advanced than what's implemented in non-commercial, non-in-house renderers. The Pbrt render also lacks aerial perspective:

https://en.wikipedia.org/wiki/Aerial_perspective

The documentation Disney posted about the data set has an explanation: https://www.disneyanimation.com/technology/datasets

Basically they have a few different techniques that couldn't be directly translated into PBRT, like lights that only hit certain objects, so the lighting is not as good in the PBRT renders, along with a few other things. Nothing super advanced, just some things that were added to their renderer for artistic control reasons that PBRT doesn't have.

I’ve looked at the data, and one of the main things missing is texture & orientation of the curves in the data set. The documentation mentions this is due to the curve data being expression based. That’s why the PBRT images have constant-color palms, for example, and might be the thing you couldn’t put your finger on that seems less accurate than Disney’s renders.

Wow, this actually makes me want to go watch Moana. Great to see collaboration between big animation studios and the open-source software community. Also, Matt's analysis of his own code is unabashed and honest. In the end he managed to make some solid performance wins for pbrt!

you _should_ watch Moana, its a great movie with fun music.

then watch it a second time for the animation and rendering....

Then watch it with the Director's commentary, which has fun nuggets like Maui spends a lot of time in the film with his hair tied up, because his unencumbered hair proved very expensive to render.

They also originally made Maui bald (for that same reason: cost), but their cultural consultants said it may be offensive to native Polynesians, as Maui was known for his long hair.

> It was a huge amount of work on Disney’s side to extract the scene from their internal scene representation and convert it to a format that’s generally accessible

Is this something that Pixar's USD [1] format would help with?

[1] https://github.com/PixarAnimationStudios/USD

From their readme, USD was considered but OBJ was chosen "for expediency."

For those that don't know, pbrt is worth checking out. One of the go to examples for Literate Programming and something I hope to someday read. http://www.pbrt.org/ :)

If folks around here have experience with it, I'd love to see a discussion on that.

We used it (as primarily intended) for teaching in class, extending it etc. Didn't actually read the book but worked along the slides from the lecture, the structure of pbrt makes it really easy to dive in and get your hands dirty.

Each triangle is an object with two v-tables? That's gross indeed.

OO is not the approach I'd use for fast and memory efficient manipulations of lots of geometric primitives, indeed. Although I don't know the specifics.

Pbrt was made to teach how to write a physically-based ray tracer. As such it is not focused on raw speed, and the ability to extend it easily is important.

Implementing better mesh handling is an excellent exercise for the reader.

As an aside, the book "Physically Based Rendering", which is the source of pbrt, is _by far_ the best programming book I've ever read.

So many books spend a lot of time on trivial stuff, while others dive into the difficult theory and math but doesn't show how to translate it into code.

PBR goes through the difficult theory and math in detail while also showing how to implement it in code, explaining potential pitfalls and tricks along the way. And it does so in an elegant and easy to understand way.

And if you got some questions, the authors answers questions in a Google Group.

Turns out Matt Pharr, the author of this article, is also the author of this book.

Yes, thanks for pointing that out. I so easily forget to mention things that seem obvious to me :(

Ahah, not good for a programmer :D

I'm joking, thanks for suggesting that book, I don't know much about this stuff but i might actually read it!

Tell me about it :P

Since a physically-based ray tracer involves a lot of different theory and math, it can be quite interesting even if your not in it for the actual ray tracing. For example there's sampling low-discrepancy sequences, kd-trees and other bounding volumes, color representation and conversion etc.

I haven't criticized the code or the merits of programmers, but it looks like a case of "if all you have is a hammer, everything looks like a nail". Sorry if I'm wrong. I've met many programmers who just can't think outside OOP model.

FWIW, in the Physically Based Rendering book, we also discuss data-oriented design (https://en.wikipedia.org/wiki/Data-oriented_design) as a potential alternative implementation approach, which would be the most natural non-OOP way to go about this.

As noted in other comments, this was a case where the pedagogical goals of the system outweighed maximizing performance.

I've been playing around with a slightly different non-OO approach. The use of sum and product types taken more from functional programming. You can see some of the results here: <https://github.com/KayEss/AnimRay/tree/feature/animation/ani... (needs to be that branch for anything interesting right now).

It's really incomplete, and I have had hardly any time to work on it over the many years that it's been around, but the general idea is to type construction to determine the aspects that a scene actually uses and let the compiler sort out what to do about it.

For example, the depth count attached to a ray doesn't appear until it hits a reflective surface so there is no overhead if the scene doesn't need it. As you can probably imagine the template errors can be obscene :)

The next thing would be to constexpr everything so that the scene could be built up in the compiler, I guess ideally in parts and then combined by the linker. I think it'll be really fun to try that with this Moana scene, but don't expect the compilers or linkers will survive let alone the tracer

EDIT to say, I really love your book. I feel hugely inspired every time I look at it, which unfortunately means I can't look too often as I don't have the time to play with these things as much as I'd like.

Even one would be gross.

> Looking at the profile, roughly 60% of rendering time is spent in ray–object intersections (most of it in BVH traversal), and 25% is spent in ptex texture lookups.

Did Disney release these stats for their Hyperion renderer? I would be curious where they spend all their time.

Ok, Part 4 confirmed that I'm not insane and most of these std::shared_ptr should go.

Has anyone tried that scene with Blender Cycles?

I have yet to attempt it in Cycles or Non-Commercial RenderMan for Blender yet. It's on my to do list. If I do it or find someone else that has.. I will make a new post.

I wonder whether someone converted that scene to PovRay…

Reply on news.ycombinator.com