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

51–60 of 154 posts

Re: DreamWorks releases OpenMoonRay source code

#51

Post by virtualritz »

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.)

As someone said above: GPUs are fine & faster as long as your scene stays simple. As soon as you hit a certain scene complexity ceiling, they become much slower that CPU renderers.

I would also argue that for this specific task, i.e. offline rendering such frames, the engineering overhead to make stuff work on GPUs is better spent making stuff faster and scale more efficiently on CPUs.[1]

I worked in blockbuster VFX for 15 years. It's been a while but I have network of people in that industry, many working on these renderers. The above is kinda the consensus whenever I talk to them.

[1] With the aforementioned caveat: if the stuff you work on is always under that complexity ceiling targeting GPUs can certainly make sense.

Re: DreamWorks releases OpenMoonRay source code

#52

Post by virtualritz »

hirako2000 wrote: post #44
abdellah123 wrote: post #40

I'm a software engineer with no animation xp. Can someone explain what this tool is (and is not) and how it fits in an animation project. e.g: can I make an animation movie using only moonray? what other tools are needed? and what knowledge do I (we) need to do that?

I have no experience with moonray, but it being a render, the answer would be.. No. The renderer is only one piece of the entire animated movie production pipeline. Modeling -> Texturing ~ rigging /Animation -> post processing effects -> rendering - > video editing That's a simplified view of the visual part of producing a short or long cgi film It is a lot of knowledge to aquire so a production team is likely made o…

> Modeling -> Texturing ~ rigging /Animation -> post processing effects -> rendering - > video editing

In animation (and VFX), editing comes at the beginning. Throwing away frames (and all the work done to create them) is simply too expensive. Handles (the extra frames at the beginning and start of a shot) are usually very small. I'd say Also modeling & texturing and animation usually happen in parallel. Later, animation and lighting & rendering usually happen in parallel as well.

Re: DreamWorks releases OpenMoonRay source code

#53

Post by dahart »

Someone1234 wrote: post #34
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.

> If they cannot get anyone else to contribute to their renderer, it will wind up getting shelved for Unreal

Why do you think this? Nobody in film or vfx is using Unreal for final rendering, Unreal is built for games not offline path tracing.

Re: DreamWorks releases OpenMoonRay source code

#55

Post by Someone1234 »

dahart wrote: post #53
Someone1234 wrote: post #34

Earlier quoted context omitted.

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.

> If they cannot get anyone else to contribute to their renderer, it will wind up getting shelved for Unreal Why do you think this? Nobody in film or vfx is using Unreal for final rendering, Unreal is built for games not offline path tracing.

Tons of studios are now using Unreal for final rendering, including Disney and several blockbuster movies.

The fantastic thing about Unreal is that you can do realtime rendering on-set (e.g. for directorial choices/actor feedback) and then post-production upscale it with the ceiling only being cost. Unreal in the TV/Movie industry is already huge and only getting bigger, year-on-year.

You've definitely seen a TV or Movie that used Unreal.

Re: DreamWorks releases OpenMoonRay source code

#56

Post by bhouston »

virtualritz wrote: post #51
pixelpoet wrote: post #35

Earlier quoted context omitted.

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.)

As someone said above: GPUs are fine & faster as long as your scene stays simple. As soon as you hit a certain scene complexity ceiling, they become much slower that CPU renderers. I would also argue that for this specific task, i.e. offline rendering such frames, the engineering overhead to make stuff work on GPUs is better spent making stuff faster and scale more efficiently on CPUs.[1] I worked in blockbuster VFX…

So we just need GPUs with 128GB of ram then? Or move towards the Apple M-series design where CPU+GPU both have insanely fast access to all ram...

Re: DreamWorks releases OpenMoonRay source code

#57

Post by ur-whale »

app4soft wrote: post #24

Anybody has a success with build & run it under Linux? (Debian 11.x/Ubuntu 22.04.x)

The docker-based build worked fine for me on Ubuntu 22.04.

I haven't yet tried to pull the resulting binaries out of the docker container to see if it still works natively on 22.04.

Re: DreamWorks releases OpenMoonRay source code

#58

Post by jsheard »

bhouston wrote: post #56
virtualritz wrote: post #51

Earlier quoted context omitted.

As someone said above: GPUs are fine & faster as long as your scene stays simple. As soon as you hit a certain scene complexity ceiling, they become much slower that CPU renderers. I would also argue that for this specific task, i.e. offline rendering such frames, the engineering overhead to make stuff work on GPUs is better spent making stuff faster and scale more efficiently on CPUs.[1] I worked in blockbuster VFX…

So we just need GPUs with 128GB of ram then? Or move towards the Apple M-series design where CPU+GPU both have insanely fast access to all ram...

It's easier said than done, there's consistently a huge gulf between CPU and GPU memory limits. Even run-of-the-mill consumer desktops can run 128GB of RAM, which exceeds even the highest end professional GPUs VRAM, and the sky is the limit with workstation and server platforms. AMD EPYC can support 2TB of memory!

Re: DreamWorks releases OpenMoonRay source code

#59

Post by packetslave »

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...

re: CentOS7, the VFX Reference Platform (https://vfxplatform.com/) is probably relevant here. Their latest Linux Platform Recommendations report from August last year already covers migrations off of CentOS 7 / RHEL7 before the end of maintenance in 2024

Studios don't want to upgrade fast (e.g. they're not interested in running Debian unstable or CentOS's streaming updates thing)... they're interested in stability for hundreds of artists' workstations.

Getting commercial Linux apps like Maya, Houdini, Nuke, etc. working well at scale is hard enough without the underlying OS changing all the time.

Re: DreamWorks releases OpenMoonRay source code

#60

Post by packetslave »

Someone1234 wrote: post #55
dahart wrote: post #53

Earlier quoted context omitted.

> If they cannot get anyone else to contribute to their renderer, it will wind up getting shelved for Unreal Why do you think this? Nobody in film or vfx is using Unreal for final rendering, Unreal is built for games not offline path tracing.

Tons of studios are now using Unreal for final rendering, including Disney and several blockbuster movies. The fantastic thing about Unreal is that you can do realtime rendering on-set (e.g. for directorial choices/actor feedback) and then post-production upscale it with the ceiling only being cost. Unreal in the TV/Movie industry is already huge and only getting bigger, year-on-year. You've definitely seen a TV or M…

You've definitely seen a TV or Movie that used Unreal.

Name a major-studio movie that rendered final camera-ready VFX in Unreal.

For TV, you can name The Mandalorian season one, sure, but even then, ILM switched The Volume to their own in-house real-time engine for season two.

Post reply on HN