Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DreamWorks releases OpenMoonRay source code

github.com

Post reply on HN
Print view View original

31–40 of 154 posts

Re: DreamWorks releases OpenMoonRay source code

#31

Post by Vt71fcAqt7 »

pipo234 wrote: post #22
mdorazio wrote: post #14

Earlier quoted context omitted.

By showing they care about open source, there's a chance they'll attract developers and animators who care about that.

Seems targeted at CentOS7, support for which is sunset in little over a year. Smells a bit like abandonware, hoping for adoption by unpaid volunteers. Still, dumping it into FOSS community is not the worst graveyard for commercial software...

They just released a feature film with this renderer, grossing $462 million and widely praised for its animation.

Large studios don't update so regularly vs e.g. a startup. They have very specific setups, which is in fact a large part of why it took them so long to release moonray vs when they said they would last year. And they are moving to Rocky Linux soon IIRC.

>dumping it into FOSS community

They are not "dumping" anything. Would it have hurt to look into the facts before commenting?

Re: DreamWorks releases OpenMoonRay source code

#32

Post by berkut »

pengaru wrote: post #26
ykl wrote: post #4

For anyone that is curious, this is the paper that describes the core vectorized path tracing architecture in Moonray: http://www.tabellion.org/et/paper17/MoonRay.pdf Extracting sufficient coherency from path tracing in order to be able to get good SIMD utilization is a surprisingly difficult problem that much research effort has been poured into, and Moonray has a really interesting solution!

> Extracting sufficient coherency from path tracing in order to be able to get good SIMD utilization is a surprisingly difficult problem Huh, I'd have assumed SIMD would just be exploited to improve quality without a perf hit, by turning individual paths into ever so slightly dispersed path-packets likely to still intersect the same objects. More samples per path traced...

If you only ever-so-slightly perturb paths, you generally don't get anywhere near as much of a benefit from monte carlo integration, especially for things like light transport at a global non-local scale (might plausibly be useful for splitting for scattering bounces or something in some cases).

So it's often worth paying the penalty of having to sort rays/hitpoints into batches to intersect/process them more homogeneously, at least in terms of noise variance reduction per progression.

But very much depends on overall architecture and what you're trying to achieve (i.e. interactive rendering, or batch rendering might also lead to different solutions, like time to first useful pixel or time to final pixel).

Re: DreamWorks releases OpenMoonRay source code

#34

Post by Someone1234 »

dimator wrote: post #10

i'm curious: what is the incentive for dreamworks to open-source this? surely having exclusive access to a parallel renderer of this quality is a competitive advantage to other studios?

Unreal is eating everyone's lunch. If they cannot get anyone else to contribute to their renderer, it will wind up getting shelved for Unreal with a lot of smaller animation studios already using Unreal instead of more traditional 3D Rendering solutions like Maya.

Re: DreamWorks releases OpenMoonRay source code

#35

Post by pixelpoet »

jsheard wrote: post #20
bhouston wrote: post #18

Earlier quoted context omitted.

Is there any comparisons to GPU-accelerated rendering? It seems most people are going that direction rather than trying to optimize for CPUs these days, especially via AVX instructions.

CPUs are still king at the scale Dreamworks/Pixar/etc operate at, GPUs are faster up to a point but they hit a wall in extremely large and complex scenes. They just don't have enough VRAM, or the work is too divergent and batches too small to keep all the threads busy. In recent years the high-end renderers (including MoonRay) have started supporting GPU rendering alongside their traditional CPU modes, but the GPU mo…

What's your opinion on renderers such as Redshift which explicitly target production rendering and support out of core rendering on GPUs? See e.g. https://www.maxon.net/en/redshift/features?categories=631816 (Disclosure: I work on this.)

Re: DreamWorks releases OpenMoonRay source code

#36

Post by berkut »

pixelpoet wrote: post #35
jsheard wrote: post #20

Earlier quoted context omitted.

CPUs are still king at the scale Dreamworks/Pixar/etc operate at, GPUs are faster up to a point but they hit a wall in extremely large and complex scenes. They just don't have enough VRAM, or the work is too divergent and batches too small to keep all the threads busy. In recent years the high-end renderers (including MoonRay) have started supporting GPU rendering alongside their traditional CPU modes, but the GPU mo…

What's your opinion on renderers such as Redshift which explicitly target production rendering and support out of core rendering on GPUs? See e.g. https://www.maxon.net/en/redshift/features?categories=631816 (Disclosure: I work on this.)

Those are generally being used on much smaller productions, or at least "simpler" fidelity things (i.e. non-photo CG animation like Blizzards's Overwatch).

So for Pixar/Dreamworks style things (look great, but not photo-real) they're useable and provide a definite benefit in terms of iteration time for lookdev artists and lighters, but it's not there yet in terms of high-end rendering at scale.

Re: DreamWorks releases OpenMoonRay source code

#39

Post by not2b »

pipo234 wrote: post #22
mdorazio wrote: post #14

Earlier quoted context omitted.

By showing they care about open source, there's a chance they'll attract developers and animators who care about that.

Seems targeted at CentOS7, support for which is sunset in little over a year. Smells a bit like abandonware, hoping for adoption by unpaid volunteers. Still, dumping it into FOSS community is not the worst graveyard for commercial software...

It's not a big deal to take something built for CentOS7 and port to a later Red Hat (or clone) distro. It appears that they released a setup for what they use, which is CentOS7.
Post reply on HN