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

91–100 of 154 posts

Re: DreamWorks releases OpenMoonRay source code

#91

Post by gabereiser »

greenknight wrote: post #75
ar9av wrote: post #46

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.

Not just that, I am assuming that there are parts of that code, that will be analysed by the Cycles developers, to enhance Cycles to improve it.

This. Pixar’s Renderman has been an “option” for a while. It was out of band though. The cycles team will look at the theory behind what’s going on in renderers like this and will make the tech work inside cycles. Maybe someone will port this as another render option but really the sauce is their lighting models and parallel vectorization which could improve cycles already abysmally slow render times.

Renderman for Blender:

https://rmanwiki.pixar.com/pages/viewpage.action?mobileBypas...

Re: DreamWorks releases OpenMoonRay source code

#92

Post by reactivenz »

m1nz1 wrote: post #66
virtualritz wrote: post #52

Earlier quoted context omitted.

> 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, anima…

Are there books that teach people about the sorts of systems used to make animated movies? I’ve seen game engine books and the like. Physically based rendering is on my list, but I wonder if there are other interesting reads I’m missing.

Yes, classic book where from 90's like "The Renderman Companion" or "Advanced RenderMan", and then there is toolings books, for each tool. I used to own many Maya books and 3DS Max books.

Re: DreamWorks releases OpenMoonRay source code

#93

Post by aprdm »

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.

Not for final shots that make to the cinema.. for tv yes

Re: DreamWorks releases OpenMoonRay source code

#94

Post by nineteen999 »

satvikpendem wrote: post #83
nineteen999 wrote: post #79

Earlier quoted context omitted.

The rendering in the Avatar movies is at the cutting edge. But quite apart from the very uninteresting storytellying there's something there that just doesn't work for me visually - I don't know if it's the uncanny valley effect of the giant skinny blue people with giant eyes or what, but I'd definitely rather watching something creative and painterly like the Puss in Boots movie, or even something like the Last of U…

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 for a year or so after the first Avatar film and then interest from the general public waned as well, probably in part due to subsequent 3D films using the post-production method and I agree the effect is not as good.

3D (including "real 3D") just doesn't seem to be the drawcard though that the geek community seems to think it is - I think the public in general would prefer better story, CG that serves the film and the story etc. And that is why I probably won't see the second - the story is not strong or interesting enough for me, and even the "wow" full 3D effect is not strong enough to pull me back, given the uncanny valley effect of the characters and the lacklustre story.

Re: DreamWorks releases OpenMoonRay source code

#95

Post by boppo1 »

aprdm wrote: post #73
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.

Except no one uses unreal for movies..

Not yet.

Re: DreamWorks releases OpenMoonRay source code

#96

Post by kranke155 »

polishdude20 wrote: post #41
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…

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.

Re: DreamWorks releases OpenMoonRay source code

#97

Post by kranke155 »

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

Redshift is cool and i use It and i know many Studios that use It.

It Just feels "Young". As a 3D artist when i see the absurd level of shader detail and Edge case solutions you see in something like Vray, you know that level of software detail only comes from the years its been in the field, taking in and solving customer feedback.

Re: DreamWorks releases OpenMoonRay source code

#98

Post by boppo1 »

ur-whale wrote: post #54

Man, I can't wait for this to be properly (luxrender-level) integrated to Blender. Especially the shaders (materials), which I feel is currently the weakest part of all the open source renders Blender supports natively (eevee, cycles, lux)

Can you elaborate on what's not good about eevee/cycles shaders? By proper integration do you imagine it will use Blender's node shader system or a different system?

I'm not being combative, I'm in the process of learning enough of Blender's code to be able to contribute.

Re: DreamWorks releases OpenMoonRay source code

#99

Post by mhh__ »

ace2358 wrote: post #65
bri3d wrote: post #12

Earlier quoted context omitted.

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!

Is that sort of code able to ‘just run’ on their arc series of GPUs? It feels like intel kinda hates AVX512 on the cpu side (or wants to upsell you for it) so I’m wondering if they turned those cards into their GPUs

Probably not. Even if the code was entirely reliant on the compiler performing vectorization (i.e. GPU & CPU instruction sets are at very the least nominally very different), GPU programming is quite different even to "lots of little CPUs"-style.

Re: DreamWorks releases OpenMoonRay source code

#100

Post by boywitharupee »

Can someone please explain the differences between real-time renderers and offline renderers? Do real-time renderers optimize frame by frame and focus on retaining some quality while prioritizing performance, using techniques like LOD and occlusion? Do offline renderers focus solely on quality? Are scene descriptions for both types of renderers different? What are the standard description files in games versus movies?
Post reply on HN