7 ms·
This looks absolutely fantastic. If you're interested in the technical details currently available, check out the about page[0] on the official MoonRay site, or
by mkaic 4y ago
This looks absolutely fantastic. If you're interested in the technical details currently available, check out the about page[0] on the official MoonRay site, or this presentation from SIGGRAPH 2017[1]. I'm particularly excited for the HeatMap render pass, seems like a really practical way to identify what's bogging your scene down. Not to mention the gorgeous volumetric rendering this engine is capable of (see How To Train Your Dragon: The Hidden Realm[2]).
Really impressed that Dreamworks is making this move. They've made some of my favorite films of all time (the Dragons franchise genuinely changed my life and is a major part of why I love filmmaking, film scores, and 3D rendering) and I'm glad to see they're doing this. I can't wait to try MoonRay in Blender once a community integration exists!
[0]https://openmoonray.org/about https://openmoonray.org/about
[1]https://jo.dreggn.org/path-tracing-in-production/2017/MoonrayV3.pdf https://jo.dreggn.org/path-tracing-in-production/2017/Moonra...
[2]https://www.awn.com/animationworld/how-moonray-became-hidden-superpower-behind-how-train-your-dragon-hidden-world https://www.awn.com/animationworld/how-moonray-became-hidden...
EDIT: I've also come across this excellent blog post written by an engineer who worked on MoonRay for 4 years: http://rendering-memo.blogspot.com/2019/ http://rendering-memo.blogspot.com/2019/
And this paper recommended by erichocean in their reply below: http://www.tabellion.org/et/paper17/MoonRay.pdf http://www.tabellion.org/et/paper17/MoonRay.pdf
- erichocean 4y agohttp://www.tabellion.org/et/paper17/MoonRay.pdf http://www.tabellion.org/et/paper17/MoonRay.pdf is also a good read.
- mkaic 4y agoThanks, I'll have to check this out! And to think I thought I was going to be productive at work today before seeing this announcement...
- echelon 4y ago> Really impressed that Dreamworks is making this move. It's bone-headed. They could have partnered with a cloud vendor and maintained control and a large percent of the revenue. Instead, Amazon can now turn this into an AWS offering, drive mindshare to the AWS offering, and then bleed DreamWorks of whatever competitive advantage this offered them. AWS makes money, DreamWorks loses talent and leadership that moves over to work at AWS. Open sourcing big software with an enterprise market and giving it a permissive license is stupid, because you can't compete. Look at pretty much every permissively licensed database vendor. Elastic's recent fight comes to mind. In ten years, when this stuff becomes easy enough for small studios to run (something my startup is working on), the need for big studios like DreamWorks to pursue projects funded by institutional capital evaporates. Everyone will be making real time 3D animation. If you look carefully, you can see the genesis of that trend now. If I were in a leadership position at DreamWorks, I would be staffing up how to make these offerings broadly available. How to make tools that put more people in the director seat. That sounds like the mission of a company named "Dream Works". Let more people dream. I guess this does it, just not in a way that they'll be using your company to do so. Big disruptions are coming to the creative fields. This kind of move is like giving away the keys to Amazon for free. (I mean, they are buying Hollywood studios left and right. If you don't see it, you're asleep at the wheel.)
- mkaic 4y agoI disagree. Dreamworks doesn't make their money because of their rendering engine, they make it because of their movies. The engine is a necessary and integral tool for making those movies, but the engine alone is not the beating heart of Dreamworks. Open sourcing MoonRay is a smart move because it means they can start hiring people who already have prior experience with it, as well as benefit from the free optimizations and improvements the OSS community will surely make! Having a rendering engine that's really good is useless unless you have the talent to use it to make a movie, and Dreamworks is going to maintain their branding and reputation for a long time regardless of whether their tech is open source or not. They aren't "giving away the key" because the render engine is not the key. It's a complement, and they're simply commoditizing their complement. While I agree that high quality art is going to become completely commonplace over the next decade or two, I really don't think it's tied in any way to one company releasing their internal render engine to the public.
- deaddodo 4y agoYes, I have to second this. While there is some edge to technology in the render sphere, no one went to see Moana or Sea Beasts due to the amazing water effects. They went because of word of mouth or advertising and were subsequently awed by said effects. You can have the most advanced visual effects and still make a terrible movie. And you can make a great movie with slightly outdated effects and still wow people (Mitchels vs The Machines is a great example). Dreamwork, being in the business of movie-making and not technology as a service, only benefits from an open renderer atmosphere. Pretrained talent, open source collaboration and contributions to improving their software and PR wins.
- mkaic 4y agoI'm genuinely curious, what about The Mitchells vs. The Machines graphics felt slightly outdated? It felt like they pushed the boundaries of the medium to me, including doing a lot of custom rendering work to make their final frames match their concept art as closely as possible, right down the the stroke textures and light-responsive character outlines. Or were you just referring to them not making any significant advances in physically-based rendering, because in that case I see what you're saying. Side note, that movie was spectacular. I have poster for it on my apartment wall!
- yieldcrv 4y agoWhy would they do this? Is this a recruitment tool? A plan to get certain architecture used more? (The article mentions Azure and some Intel hardware) Pure inspiration? All the above? Nice touch on Apache license, really shows they're paying attention to open source community
- mkaic 4y agoI'm guessing it's a combination of genuine goodwill (Dreamworks has a history of open-sourcing stuff) and wanting to be able to hire people who already have experience with their renderer instead of having to train every new hire. Not to mention the improvements that will surely be made to it once anyone can contribute a pull request. Whatever their reasoning, I'm hyped because it seems like an unconditional win-win -- artists get a great new render engine, Dreamworks gets kudos + free development + market/mind share.
- hinkley 4y agoI know a guy who hacked on Apple's compiler fixing bugs. It turned into a job offer, but he didn't like the interplay of compensation and relocation. Now would have been a good time for him to check back on their relocation policy but in the interim it would be a large demotion instead of a small one. I used to joke that F5 owes me a job and 2 month's salary for all the free QA we did for them back when their session affinity code was just a checkbox on the PR material. If they were more open that might have played out a bit differently.
- deaddodo 4y agoLLVM and Clang (I’m assuming you’re referring to these based on timing) are not Apple’s. Both have been under the LLVM Developer Group from inception, and LLVM existed for many years before Apple hired one of the lead devs. While it’s true that Lattner worked for Apple while he created Clang and that his personal contributions were probably biased, it’s always been an outside of Apple project with independent contributors.
- 4y ago
- a_e_k 4y agoI suspect that every production renderer must eventually have something like a heat map. Back when I worked at Pixar on the RenderMan team, I was the one who implemented the cpuTime and sampleCount AOVs (i.e., passes) [0] in RenderMan RIS as well as some of the other diagnostic AOVs. And SPI's Arnold also acquired a pair of equivalent AOVs at some point [1]. The cpuTime AOV wasn't exactly novel then either, as I recall; I think there'd been something like it back in the old REYES days. I'd also contributed a bit to the render time heatmap and added the sample count heatmap in the XML stats files [2]. Those are more thumbnail resolution than the AOVs, but on the other hand they were always-on for all generated stats files. The also displayed with nice little histograms. One of the things that I learned in my years at Pixar was that rich diagnostics, statistics, or metrics are one of those key things that separates production renderers from other renderers. Pipeline folks, render wranglers, and TDs thrive on them. [0] https://rmanwiki.pixar.com/display/REN24/Arbitrary+Output+Variables https://rmanwiki.pixar.com/display/REN24/Arbitrary+Output+Va... [1] http://fundza.com/tishela/PDF/TransitionToRayTracingAtSony.pdf#page=16 http://fundza.com/tishela/PDF/TransitionToRayTracingAtSony.p... [2] https://rmanwiki.pixar.com/display/REN23/Diagnostics https://rmanwiki.pixar.com/display/REN23/Diagnostics
- mkaic 4y agoOh shoot, you're totally right -- doing a quick search reveals that Blender's Cycles engine has totally had this feature for a while and I was just completely unaware of it despite using it frequently! Although even without the heatmap pass being unique/new I'm still super excited for the rest of MoonRay, especially those delicious volumetrics! https://docs.blender.org/manual/en/latest/render/layers/passes.html https://docs.blender.org/manual/en/latest/render/layers/pass...
- a_e_k 4y agoOh yes, I'm not knocking the release of MoonRay as a whole. I was at HPG '17 when the paper that erichocean mentioned was present. I'm definitely excited to get a peek at it. I also wonder now how much work it was to disentangle it from their infrastructure? A lot of internal studio tools and libraries tend not to work outside of their studio's intranet -- not so much from direct copy protection, but more just because of heavy assumptions about filesystems and servers.