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

111–120 of 154 posts

Re: DreamWorks releases OpenMoonRay source code

#111

Post by satvikpendem »

nineteen999 wrote: post #94
satvikpendem wrote: post #83

Earlier quoted context omitted.

Did you watch in IMAX 3D? I watched in both 3D and 2D and the 2D simply cannot compare to the 3D. The way most 3D movies work is the 3D effects are done after the fact in post-production. 3D in Avatar movies are done entirely in the shooting phase, through 3D cameras. Hence, the 3D in Avatar films is much more immersive to me than in something like Dr Strange 2, which simply could not compare.

I haven't seen the second Avatar film at all; my observations are merely from seeing the first one in 3D and the trailers for the second. I'm aware that it's shot entirely 3D as well. While I was wowed at the 3D effect when I saw the first one, the thrill of that entirely wore off within a week or two and is not a big enough draw for me to see the second. I don't think I'm in the minority here, 3D was huge in cinemas…

I'm talking about 3D in the Avatar series specifically, not 3D (including real 3D) as a whole. Avatar has made billions of dollars so far so it's doing something right. But yes, I agree that generally speaking, people like better stories with worse CGI than vice versa, it's just that James Cameron's movies are an exception to that rule.

Re: DreamWorks releases OpenMoonRay source code

#112

Post by polishdude20 »

kranke155 wrote: post #96
polishdude20 wrote: post #41

Earlier quoted context omitted.

So the idea is one CPU can have hundreds of gigabytes of ram at a time and the speed of the cpu is no problem because you can scale the process over as many CPUs as you want?

Fundamentally yes. Big Studios are CPU Farms. Small Studios and Indie Artists like myself a Lot of us have moved to GPU.

Is that because work is usually divided by frame? And usually a frame for these big movies uses more than typical GPU VRAM?

Re: DreamWorks releases OpenMoonRay source code

#114

Post by CyberDildonics »

naikrovek wrote: post #76
aprdm wrote: post #73

Earlier quoted context omitted.

Except no one uses unreal for movies..

yes, unreal is used in movies and TV shows, both. usually not entire movies or shows, but lots of individual scenes.

Why are you saying 'yes' then saying the exact opposite of what they said?

Unreal is not used for final shots in film.

Re: DreamWorks releases OpenMoonRay source code

#115

Post by bobsomers »

ur-whale wrote: post #103

So, I've finally managed to compile Moonray and play with it. TBH, this was really not as straightforward as it ought to have been: - some Optix-using code failed to compile against latest Optix SDK, code had to be patched. - the build instructions at [4] aren't completely foolproof either (don't quit the container before you manage to snapshot it, or else) When I finally got a clean compile, I tried to render a USD…

I wrote the RDL2 library for Moonray when I worked at DWA about 8-9 years ago. At the time, USD was still very nascent, and we already had RDL (v1) as an internal reference point, so that’s ultimately why Moonray uses something “non-standard” by modern conventions.

RDL has two on-disk formats, RDLA (for “Ascii”) and RDLB (for “Binary”). The text format is literally just a Lua script which uses various function calls to instantiate scene objects and set their parameters. It’s great for spinning up test scenes and doing development work on shaders or the renderer itself.

The binary format (which at the time used Protobuf to serialize scene objects, not sure if that’s still true) is more suited to production workflows where you don’t want to deal with things like floating point to text precision issues and a more space efficient representation is preferred.

I found some documentation and examples of the RDL format here: https://docs.openmoonray.org/getting-started/about/rdl-scene...

And it looks like the user documentation has some examples of how to do things, including instantiating various types of scene objects: https://docs.openmoonray.org/user-reference/

Re: DreamWorks releases OpenMoonRay source code

#116

Post by bobsomers »

mindcrime wrote: post #86

Is anybody else intrigued by the mention of multi-machine and cloud rendering via the Arras distributed computation framework. ? Is this something new? The code seems to be included as sub-modules of OMR itself, and all the repos[1][2][3] show recent "Initial Commit" messages, so I'm operating on the assumption that it is. If so, I wonder if this is something that might prove useful in other contexts... [1]: https://…

I can maybe add a bit of context to this. I worked on Moonray/Arras at DWA about 8-9 years ago.

Arras was designed to let multiple machines work on a single frame in parallel. Film renderers still very much leverage the CPU for a lot of reasons, and letting a render run to completion on a single workstation could take hours. Normally this isn’t a problem for batch rendering, which typically happens overnight, for shots that will get reviewed the next day.

But sometimes it’s really nice to have a very immediate, interactive workflow at your desk. Typically you need to use a different renderer designed with a more real-time architecture in mind, and many times that means using shaders that don’t match, so it’s not an ideal workflow.

Arras was designed to be able to give you the best of both worlds. Moonray is perfectly happy to render frames in batch mode, but it can also use Arras to connect dozens of workstations together and have them all work on the same frame in parallel. This basically gives you a film-quality interactive lighting session at your desk, where the final render will match what you see pixel for pixel because ultimately you’re using the same renderer and the same shaders.

Re: DreamWorks releases OpenMoonRay source code

#117

Post by isatty »

aseipp wrote: post #84
bhouston wrote: post #56

Earlier quoted context omitted.

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

GPUs need RAM that can handle a lot of bandwidth, so that all of the execution units can remain constantly fed. For bandwidth, there is both a width and a rate of transfer (often bounded by the clock speed) which combined yield the overall bandwidth, i.e. a 384-bit bus at XXXX million transfers/second. It will never matter how much compute or RAM they have if these don't align and you can't feed the cores. Modern des…

Amazing post - thank you so much for typing that out.

Re: DreamWorks releases OpenMoonRay source code

#118

Post by sweetrobot2k »

bobsomers wrote: post #116
mindcrime wrote: post #86

Is anybody else intrigued by the mention of multi-machine and cloud rendering via the Arras distributed computation framework. ? Is this something new? The code seems to be included as sub-modules of OMR itself, and all the repos[1][2][3] show recent "Initial Commit" messages, so I'm operating on the assumption that it is. If so, I wonder if this is something that might prove useful in other contexts... [1]: https://…

I can maybe add a bit of context to this. I worked on Moonray/Arras at DWA about 8-9 years ago. Arras was designed to let multiple machines work on a single frame in parallel. Film renderers still very much leverage the CPU for a lot of reasons, and letting a render run to completion on a single workstation could take hours. Normally this isn’t a problem for batch rendering, which typically happens overnight, for sho…

Sick!

Re: DreamWorks releases OpenMoonRay source code

#119

Post by brucethemoose2 »

bri3d wrote: post #12
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!

This paper is the first place I've found a production use of Knights' Landing / Xeon Phi, the Intel massively-multicore Atom-with-AVX512 accelerator system, outside of HPC / science use cases. And for this use case, it makes perfect sense!

They should consider moving to ARM, maybe whatever SiPearl or Fujitsu are currently cooking up.

They probably have a mountain of intrinsics written, but it doesn't seem like AMD or Intel are going to replicate the Xeon Phi again.

Re: DreamWorks releases OpenMoonRay source code

#120

Post by RantyDave »

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?

Open sourcing the trailing edge stuff is a great way to keep people behind you.
Post reply on HN