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

41–50 of 154 posts

Re: DreamWorks releases OpenMoonRay source code

#41

Post by polishdude20 »

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…

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?

Re: DreamWorks releases OpenMoonRay source code

#42

Post by virtualritz »

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?

It's an offline 3D rendering software that turns a scene description into a photorealistic image. Usually such a description is for a single frame of animation.

Offline being the opposite of realtime. I.e. a frame taking possibly hours to render whereas in a realtime renderer it must take fractions of a second.

Maybe think of it like a physical camera in a movie. And a very professional one for that. But then a camera doesn't get you very far if you consider the list of people you see when credits roll by. :]

Similarly, at the very least, you need something to feed the renderer a 3D scene, frame by frame. Usually this is a DCC app like Maya, Houdini etc. or something created in-house. That's where you do your animation. After you created the stuff you want to animate and the sets where that lives ... etc., etc.

Moonray has a Hydra USD delegate. That is an API to send such 3D scenes to a renderer. There is one for Blender too[1]. That would be one way to get data in there, I'd reckon.

Hope that makes sense.

[1] https://github.com/GPUOpen-LibrariesAndSDKs/BlenderUSDHydraA...

Re: DreamWorks releases OpenMoonRay source code

#43

Post by sosodev »

jsheard wrote: post #28
ralusek wrote: post #25

Earlier quoted context omitted.

I don't think there is a monopoly renderer.

There isn't even a monopoly within Disney, they acquired Pixar 17 years ago but Disney Animation Studios still develop their own Hyperion renderer completely independently of Pixar/Renderman.

Just because it's hard to migrate existing workflows or is there something that makes Hyperion superior?

Re: DreamWorks releases OpenMoonRay source code

#44

Post by hirako2000 »

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 of specialists and sub specialists (lighting?) working to a degree together.

The best achieving software, especially given its affordability is likely Blender. Other tools lile cinema4d, Maya and of course 3d smax are also pretty good all in one products that cover the whole pileline, although pricey.

Start with modeling, then texturing, then animation. Etc. Then dive into the slice that attracts you the most. Realistically you aren't going to ship a professional grade film so you may as well just learn what you love, and who knows perhaps one day become a professional and appear in the long credit name list at the end of a Disney/Pixar, Dreamworks hit.

Re: DreamWorks releases OpenMoonRay source code

#45

Post by chungy »

fuzzybear3965 wrote: post #13
ronsor wrote: post #11

Earlier quoted context omitted.

The other large studios that compete with them (e.g. Pixar) already have their own just-as-good renderers.

Even still, what's the incentive to open-source? So the community can bootstrap a better solution than Pixar?

Why not?

The tool may be good, but the output visuals are only as good as the artists that use said tools. They can open source the tools all they want and try to hire all the talent that can use it. :)

Re: DreamWorks releases OpenMoonRay source code

#46

Post by ar9av »

Quality 3d animation software is available to anyone with Blender. If someone gets this renderer working as an addon (which will obviously happen) artist will get a side by side comparison of what their work looks like with both cycles and a professional studio product, for free.

This is win, win, win for Blender, OSS and the community.

Re: DreamWorks releases OpenMoonRay source code

#47

Post by Vt71fcAqt7 »

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.

I'm not really sure if they are competing with Unreal. Large studios will probably never use real time rendering for the final render unless it achieves the same quality. Dreamworks have built a renderer specifically for render farms (little use of GPUs, for example) which means they are not targeting small studios at all, rather something like Illumination Entertainment or Sony (think Angry Birds movie).

Re: DreamWorks releases OpenMoonRay source code

#48

Post by op00to »

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

Major animated movies take years to develop, and they don’t like to change the build process during. I used to cover a major animation studio for a major Linux vendor and they did in fact use very old shit.

Re: DreamWorks releases OpenMoonRay source code

#49

Post by jsheard »

sosodev wrote: post #43
jsheard wrote: post #28

Earlier quoted context omitted.

There isn't even a monopoly within Disney, they acquired Pixar 17 years ago but Disney Animation Studios still develop their own Hyperion renderer completely independently of Pixar/Renderman.

Just because it's hard to migrate existing workflows or is there something that makes Hyperion superior?

Hyperion has the advantage of being exclusive to WDAS, so they can tailor it to their exact workflow and requirements, while Renderman is a commercial product with many users outside of Pixar all with their own wants and needs.

Re: DreamWorks releases OpenMoonRay source code

#50

Post by xeromal »

berkut wrote: post #32
pengaru wrote: post #26

Earlier quoted context omitted.

> 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 homogen…

[flagged]
Post reply on HN