[HN Gopher] DreamWorks Animation to release MoonRay as open source
___________________________________________________________________
DreamWorks Animation to release MoonRay as open source
Author : mroche
Score : 328 points
Date : 2022-08-05 15:24 UTC (7 hours ago)
(HTM) web link (www.awn.com)
(TXT) w3m dump (www.awn.com)
| pitaj wrote:
| I'm not very well acquainted with this kind of thing. Is this
| something that could be used with other open-source projects like
| Blender?
| knolan wrote:
| Yes, you can use other renderers with Blender. RenderMan for
| example.
| dry_soup wrote:
| It will require the development of an add-on for Blender. It
| might even already exist.
| miohtama wrote:
| Would be interesting to know what business considerations lead to
| the decision to open source MoonRay.
| munificent wrote:
| There is a lot of staffing churn in the film world and many
| films are built by farming out work to dozens of separate VFX
| studios.
|
| I speculate that having this open source increases its
| popularity, which makes more likely that any given potential
| hire or VFX company will have experience with it, which makes
| it easier for DreamWorks to ramp up new hires or contract out
| to third party companies.
|
| When I was at EA, we switched from a proprietary UI tool (which
| was quite well suited for consoles) to Flash (which wasn't)
| entirely because it eased staffing problems even though the
| technology itself was a worse fit. The best tool is often the
| one that people you can hire already know.
| egypturnash wrote:
| god, Flash wasn't suited for _anything_ and yet somehow it
| got used for _everything_ until Apple managed to kill it by
| keeping it the hell off the iPhone. It was kind of okay for
| so many things and actually great at none of them.
|
| It might even _still_ be in use at Cartoon Network, it 's
| been a while since I last heard from my former co-worker in
| the dialup-delivered Flash cartoon mines who ended up as the
| animation director for Foster's and Titans but he sure was
| still using an old version of Flash/Animate long after the
| browser plugin was retired.
|
| There's probably a lot of lessons in Flash's status as a tool
| that did a ton of different things half-assedly.
| munificent wrote:
| It was like the JavaScript of UX and 2D games for a while.
| It was trash as a technology, but it was a technology that
| _millions_ of UI designers and indie game developers cut
| their teeth on and already knew deeply, so it stuck around
| much longer than it should have. Like grown-ups trying to
| ride tricycles to work.
|
| I remember someone at EA talked to Adobe about getting
| access to the Flash (.fla) file format so that our UI tools
| could read it directly to export into the in game format
| instead of reading the already compiled and compressed .swf
| format. And they were like, "Uh... you really don't want to
| do that. It's like a memory dump of the entire application
| state. It's a giant mess. We're really sorry."
|
| By all accounts, it seemed like the Flash codebase was a
| dumpster fire. But so many amazing little games and UIs
| were built using it.
| egypturnash wrote:
| hahahha, "It's a memory dump of the entire app state"
| explains SO MUCH.
| game-of-throws wrote:
| To be fair that's how a lot of software worked in that
| era. MS Office worked that way too (doc files, not docx
| files).
| desindol wrote:
| Students get used to your pipeline before you hire them. The
| technology is nothing groundbreaking but the best that is
| available for free. Most students will take that opportunity.
| berkut wrote:
| This won't be their entire pipeline though. People will have
| to use the open source version in vanilla DCCs without all of
| Dreamworks' integrations, so will only be exposed to a bit of
| it in terms of configuring the renderer's options.
| ziddoap wrote:
| Which is still more familiarity than before.
| Someone wrote:
| Can students realistically run this kind of software on the
| hardware they have? I would guess DreamWorks only runs it on
| fairly expensive networks, and would not have prioritized
| keeping it usable on single-machine setups.
| mkaic wrote:
| I disagree -- a large part of the lookdev process at
| animation studios involves single artists working on single
| workstations with single GPUs while they work on their part
| of the pipeline. I'd wager that Dreamworks almost certainly
| does big distributed renders for the final frames of the
| movie, but a large number of the in-between steps and
| still-frame test renders probably happen in individual
| employee's machines -- not to mention that having an engine
| that can preview the render in near-realtime is a staple of
| modern 3D pipelines now that we have such beefy graphics
| cards.
| bombcar wrote:
| This is _huge_ and people underestimate how valuable it can
| be for a company. DreamWorks Animation 's product is _not_
| MoonRay, it is _movies_ and they 're commodizing their
| complement.
|
| If _every_ animation studio started using MoonRay because of
| this, they 'd _have won_.
| pwdisswordfish9 wrote:
| Good point in your second sentence, but hard see where
| you're coming from in the last one.
|
| Surely the win for DreamWorks is the competitive advantage
| of having aspiring creators be familiar with their
| pipeline. If _all_ animation studios use MoonRay, then that
| advantage gets erased, and the ultimate impact is null.
| (The only way this isn 't true is if you subscribe to the
| belief that _more MoonRay use_ - _more MoonRay experts_ -
| _more DreamWorks movies_ - _more profit_. That 's probably
| not sound. This probably won't impact how many movies they
| put out, just how good they look (after benefiting from
| open source work) and how easy it is to hire for the movies
| that they put out.)
| XorNot wrote:
| The estimate would be that their tooling investment is no
| longer a major competitive advantage, compared to other
| studios. But, if other studios or new studios switch to
| their tooling or start using it, then functionally
| they're subsidizing skilling up animators who they can
| later hire as contractors or full-time onto their
| projects.
|
| They're in the movie business after all - speed of
| production saves a lot of money.
| kanzure wrote:
| > If all animation studios use MoonRay, then that
| advantage gets erased, and the ultimate impact is null.
|
| Other studios could also contribute improvements, which
| the original studio could benefit from. That's one of my
| motivations for open-source: I'm selfish and I enjoy the
| benefits from the efforts of others making my software
| better, should they find it useful.
| bombcar wrote:
| And it would mean that they're all on a level playing
| field - everyone would be using MoonRay so there wouldn't
| be an obvious technological advantage.
|
| (Note that this _could_ mean that if you thought your
| software was putting you at an advantage, you might not
| want to open-source it, but you could also believe that
| even if it is better, your competitors won 't / can't
| switch to it).
| com2kid wrote:
| > And it would mean that they're all on a level playing
| field - everyone would be using MoonRay so there wouldn't
| be an obvious technological advantage.
|
| But if the improvements to MoonRay drive down production
| costs for movies, the entire industry wins.
| thebeardisred wrote:
| DreamWorks Animation (aka DWA) is a huge advocate of open
| source.
|
| Over the years they've bankrolled a lot of development around
| Linux on the desktop and have one of the most astonishing NFS
| infrastructures I've ever directly layed hands on.
|
| They've talked about their love of open source over the years,
| especially at Red Hat summit.
|
| (I spent quite a bit of time working with them and their former
| CTO is currently a teammate of mine).
| albatross13 wrote:
| Can you expound a bit on the NFS infrastructure? I'm curious.
|
| If you can't, legally, nbd.
| newman314 wrote:
| I was curious, did a quick search and found this OLD deck.
| Would be interesting to see how it has evolved since.
|
| https://www.usenix.org/legacy/event/lisa10/tech/slides/kama
| t...
| erichocean wrote:
| Even small companies can create competitive high-end renderers
| today so it's not much of a differentiator. Filmmaking is about
| human talent mostly, not technology. (Same thing happened in
| live-action filmmaking, anyone can afford the equipment today.)
|
| But there's a huge advantage to being the _first_ high-end
| renderer to go open source, so lots of small studios will adopt
| it if it 's as solid as it looks.
|
| It'll become available in Blender.
|
| Maintenance will then get extended to the community, including
| (most likely) support for alternate shading schemes
| (MaterialX/Lama has decent momentum right now, converging with
| Sony's OpenShadingLanguage).
|
| Apache 2.0 is an ideal license for this kind of project.
| berkut wrote:
| Yeah. They've open sourced OpenVDB and other smaller things
| before, and have contributed things to Embree and OpenSubDiv,
| but those were libraries/storage formats, not entire
| production-capable renderers.
|
| At the same time however, does their renderer give them that
| many advantages? As someone who works on a (sort of) competing
| proprietary renderer, it's a lot of work and effort to do it
| and support it, and maybe they want to build a community around
| that from smaller studios and compete with Renderman a bit for
| mindshare?
| wlesieutre wrote:
| If they can get students or freelance animators to learn it,
| that's a potential hiring pool with a lot less onboarding
| dimatura wrote:
| OpenVDB is a really cool tool and a nice C++ codebase. During
| my PhD I adapted it to manage volumetric data extracted from
| LiDAR measurements and found it to be much more efficient
| than more popular alternatives in the robotics world, such as
| Octomap (which is also a great tool in its own right!).
| KittyCatCuddler wrote:
| It kinda seems like they might be in cahoots with Microsoft to
| compete with AWS Nimble.
|
| https://aws.amazon.com/nimble-studio/
| berkut wrote:
| Interesting, seeing as at least on Trolls they were using AWS
| for some of their compute for rendering. Some Dreamworks
| employees on the tech side left for AWS as well.
| khazhoux wrote:
| Just FYI, Nimble was former Dreamworks animators and
| engineers.
| bogwog wrote:
| This is released under Apache 2.0 though, so Amazon could
| just do what they always do and repackage/sell it under a
| different name as an AWS product.
| mchusma wrote:
| This is not really like Nimble, it's more like Picard
| renderman
| ArtWomb wrote:
| If we're speculating, Pixar is also announcing it's Renderman
| 25 XPU cloud native render tech. If gpu cluster &
| virtualization continues to explode and transform the effects
| industry. I imagine all the major studios would seek ancillary
| revenue, farming out their cloud investments during idle hours,
| to third parties in gov research and academics to use for large
| scale data viz ;)
| a_e_k wrote:
| My experience from when I was in the industry was the
| opposite. Studios would generally maintain a solid baseline
| renderfarm and then send overflow to the major cloud
| providers.
|
| They also weren't really set up for the kind of strict
| isolation and security that offering resources to external
| parties would require.
| erichocean wrote:
| > _during idle hours_
|
| Studios don't really have idle hours on their render farms.
| samstave wrote:
| This was 2004. The concepts were still being figured out
| WRT to making a huge campus for one of the most creative
| companies...
|
| EDIT: I thought you were replying to my comment about the
| Lucas Presidio Campus
| samstave wrote:
| An interesting tidbit of history:
|
| When I was on the design team for the Lucas Presidio Campus,
| we were collapsing all the various divisions to the new
| campus, aside from Skywalker...
|
| I was the LV/Datacenter/network designer for the project.
|
| One of the early design requirements was to 1) have fiber to
| the desktop and 2) have every machine on an interconnect
| matrix which brought the edge desktop connections as close to
| the core as possible such that every workstation would become
| a part of the ender cluster when idle/at night/on-demand
| etc...
|
| This didnt happen but it was a goal back in ~2004
|
| --
|
| I recall them telling us when Jobs came to visit and they had
| the "Death Star" <-- render cluster they were working on...
| Lucas apparently saw no future and sold it to Jobs for
| ~$10mm?? and thats where Pixar got it start.
|
| That was an amazing fun project to work on.
|
| ---
|
| Oh - and during the design sessions, Cisco borked the design
| review for their (joke of a response) to the RFP, the then
| CIO for LucasArts in this design meeting with ILM, Lucas,
| Cisco others -- he says to the entire team in dead
| seriousness
|
| "When can I have power-over-fiber to the desktop" with a look
| like "Ha! GotchA!
|
| And everyone just blinked..
| colechristensen wrote:
| >We expect to see the code base grow stronger with community
| involvement as DreamWorks continues to demonstrate our
| commitment to open source
|
| Translation: we think making this open source will bring in
| significant outside contribution so we can get a better
| renderer with less investment ourselves while not having to pay
| external providers
|
| Open source is a good strategy for the runners up trying to
| compete, you get the good will from giving something away in
| exchange for other people improving your product for free.
| erichocean wrote:
| > _runners up trying to compete_
|
| MoonRay likely has the best volume rendering in the world,
| certainly that's open source.
|
| Only Weta's internal renderer is in the same league.
| berkut wrote:
| Not necessarily: it would depend on what Dreamworks'
| requirements have been up to now as to the current state:
| obviously, they use volumetrics, but almost all their stuff
| is CG and not necessarily photo real, being more artistic-
| driven.
|
| That fact might have allowed them to take short-cuts.
|
| How do you know what Manuka's capable of? :)
| mkaic wrote:
| I'd guess that the volume rendering in MoonRay is pretty
| top notch considering Dreamworks was also responsible for
| creating OpenVDB. Furthermore, while their characters and
| environments are often stylized, watch a few minutes of
| How To Train Your Dragon 3 and you'll see their
| volumetric rendering is _stunningly_ believable.
| ziddoap wrote:
| Why are you framing this in such a negative light?
|
| They open something up, let people use it, and hope that some
| people might contribute back. Cool, sounds great to me. They
| aren't forcing me to contribute back to the project. Seems
| pretty win-win.
| tpmx wrote:
| That's not how it works. What they're after is mindshare,
| establishing their codebase as a standard etc.
|
| You're not going to get a free work force just by open
| sourcing your very context-specific code. Most
| companies/people learned this ~22 years ago.
| ramesh31 wrote:
| Is this akin to RenderMan? And is this something useful for
| hobbyists, or is it just something that would run in a render
| farm?
| VikingCoder wrote:
| Yes, roughly akin to RenderMan. Yes, some hobbyists will use
| this.
| bogwog wrote:
| A hobbyist film maker probably won't use this directly, but it
| will likely find its way into software that they do use at some
| point.
| pwdisswordfish9 wrote:
| berkut wrote:
| Where's the acronym in the title?
| pwdisswordfish9 wrote:
| berkut wrote:
| Fair enough.
|
| But I suspect if you got your wish there would be a lot
| less posts...
| SV_BubbleTime wrote:
| Just a note, but anytime someone writes "there aught to be a
| law..." there almost always definitely should not.
| erulabs wrote:
| I suppose they could have said "Monte Carlo Raytracer" but
| would that have really helped anyone?
| Keyframe wrote:
| We'd know it's not a quasi-Monte Carlo renderer at least.
| pwdisswordfish9 wrote:
| Is that even a serious question? Because the answer is (a
| fairly obvious) "Yes."
| lynndotpy wrote:
| This is unreasonably snarky and rude, but I'll bite because
| I'm curious: Why is this knowledge so useful it should be
| explained in the title?
| nixcraft wrote:
| From download page https://openmoonray.org/download :
|
| "We are currently preparing the packages for public release, and
| MoonRay will be available for download from Github soon."
| mkaic wrote:
| 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
|
| [1]https://jo.dreggn.org/path-tracing-in-
| production/2017/Moonra...
|
| [2]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/
|
| And this paper recommended by erichocean in their reply below:
| http://www.tabellion.org/et/paper17/MoonRay.pdf
| yieldcrv wrote:
| Why 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 wrote:
| I'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 wrote:
| I 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 wrote:
| LLVM 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.
| GeekyBear wrote:
| LLVM used GCC C as a front end. Clang was an Apple
| project, since GCC wasn't designed to integrate into an
| IDE like Xcode.
|
| >One of Clang's main goals is to provide a library-based
| architecture, so that the compiler could interoperate
| with other tools that interact with source code, such as
| integrated development environments (IDE). In contrast,
| GCC works in a compile-link-debug workflow; integrating
| it with other tools is not always easy. For instance, GCC
| uses a step called fold that is key to the overall
| compile process, which has the side effect of translating
| the code tree into a form that looks unlike the original
| source code. If an error is found during or after the
| fold step, it can be difficult to translate that back
| into one location in the original source.
|
| https://en.wikipedia.org/wiki/Clang#Background
| echelon wrote:
| > 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.)
| threeseed wrote:
| > and giving it a permissive license is stupid
|
| We haven't seen the license yet so might be prudent to hold
| off on the panic until then.
| ykl wrote:
| The license is Apache 2.0 [1]
|
| [1] https://openmoonray.org/license
| mkaic wrote:
| I 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 wrote:
| Yes, 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 wrote:
| I'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!
| echelon wrote:
| In the coming years, all sorts of people will be making
| films, and they'll be empowered by a new generation of
| editing, compositing, and rendering tools. They won't
| need large sums of capital or large teams to accomplish
| what the Pixar of yesteryear did.
|
| There are so many people that want to direct, yet the
| current Hollywood regime only has so much room at the top
| to grow into. That's going to change.
|
| And if you doubt that people want to be creative, just
| look at TikTok. Really, YouTube should have been our
| first evidence of this.
| echelon wrote:
| > Dreamworks doesn't make their money because of their
| rendering engine, they make it because of their movies.
|
| For now.
|
| It's their job to know where the market is heading, and the
| world of 3D animation is about to be blown wide open for
| smaller teams to accomplish what the big incumbents have
| done for decades.
|
| Tooling will be one of the areas where money is made, and
| they just gave it away for free.
|
| > Dreamworks is going to maintain their branding and
| reputation for a long time regardless of whether their tech
| is open source or not.
|
| This is where we fundamentally disagree. Films currently
| require institutional capital and large teams to make, and
| that's about to change in a big way. The film industry is
| about to undergo something vaguely resembling what the news
| and journalism industry underwent as access to the tools of
| creation and distribution become more widespread and
| accessible.
|
| The studio system exists because making movies is hard. It
| only needs to exist while that remains the case.
| a_e_k wrote:
| I 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+Va...
|
| [1]
| http://fundza.com/tishela/PDF/TransitionToRayTracingAtSony.p...
|
| [2] https://rmanwiki.pixar.com/display/REN23/Diagnostics
| mkaic wrote:
| Oh 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/pass.
| ..
| erichocean wrote:
| http://www.tabellion.org/et/paper17/MoonRay.pdf is also a good
| read.
| mkaic wrote:
| Thanks, 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...
| manchoz wrote:
| The name actually reminds me of the awesome RenderMan-compliant
| BMRT https://en.wikipedia.org/wiki/Blue_Moon_Rendering_Tools
| codetrotter wrote:
| For me the name reminded me of Mental Ray. Dunno if there is
| any connection.
|
| https://en.wikipedia.org/wiki/Mental_Ray
| boulos wrote:
| Eh, it traces rays and the moon (and "Moon Boy") are
| DreamWorks.
| johnmertic wrote:
| We added MoonRay today to the ASWF Landscape, which is a great
| tool for seeing all the open source in the visual and special
| effects industry. Check it out at https://l.aswf.io
| erichocean wrote:
| That's a very helpful page, thank you for maintaining it!
| robalni wrote:
| It's good to see companies freeing important software like this.
| That shows other companies and everyone else that you can do that
| without too much risk and that it might even give you benefits. I
| think many companies are afraid of doing it and I think this is
| how we can show them that there is no problem with doing it (and
| if there is a problem, we will learn that; we learn something
| either way).
|
| Since free software is so important to many people and one of the
| biggest questions about how the digital society should work, it's
| crucial that we explore the possibilities of releasing free
| software. I'm tired of the current situation where on one side we
| have a ton of software and on the other side people who can't use
| that software because of how unethical or impractical it is. We
| need to find something that works for everyone and this is a step
| in that direction.
| echelon wrote:
| Amazon is going to take this and make it SaaS. Then the
| ecosystem moves to Amazon instead of DreamWorks.
| zucker42 wrote:
| Do people pay to use DreamWorks renderer? I would think they
| pay DreamWorks to animate stuff. That hasn't changed.
| echelon wrote:
| Individual creators are now building scenes in Blender and
| Unreal Engine. The floodgates are about to open for
| individual creators doing animation. An easy to use render
| farm is a good startup idea.
| punnerud wrote:
| What can be the real reason for Open Sourcing? That they have a
| hard time competing with the new machine learning based
| rendering?
| anaganisk wrote:
| We are in a world, where left pad was opensource, question must
| always be why is it closed source. I mean not to say closed is
| bad, but a question is good.
| erichocean wrote:
| Every studio has been open sourcing high end VFX/CG software
| libraries for over a decade.
|
| This is just a continuation of that.
| [deleted]
___________________________________________________________________
(page generated 2022-08-05 23:01 UTC)