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

101–110 of 154 posts

Re: DreamWorks releases OpenMoonRay source code

#101

Post by daniel-thompson »

xmcqdpt2 wrote: post #81
daniel-thompson wrote: post #72

Surprised nobody has mentioned this, but it looks like it implements the render kernels in ISPC^, which is a tool that exposes a CUDA-like SPMD model that runs over the vector lanes in the CPU. ISPC is also used by Disney's Hyperion renderer, see https://www.researchgate.net/publication/326662420_The_Desig... Neat! ^ https://ispc.github.io/

Neat! Vectorization is the best part of writing Fortran. This looks like it makes it possible to write fortran-like code in C. I wonder how it compares to ifort / openMP?

OpenMP starts with a serial model, the programmer tags the loop they want to run in parallel with a directive, and the compiler tries to vectorize the loop. This can always fail, since it relies on a computer program reasoning about an arbitrary block of code. So you have to really dig into the SIMD directives and understand their limitations in order to write performant code that actually does get vectorized.

ISPC starts with an SPMD programming model, and exposes only operations that conform to the model. "Vectorization" is performed by the developer - it's up to them to figure out how to map their algorithm or problem to the vector lanes (just like in CUDA or OpenCL). So there's no unexpectedly falling off the vectorization path - you start on it, and you can only do stuff that stays on it, by design.

Re: DreamWorks releases OpenMoonRay source code

#102

Post by Arrath »

boywitharupee wrote: post #100

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…

While I'm not terribly familiar with the subject myself: Note that figure 2 in TFA calls out Astrid's character model as consisting of "1.67GB of geometry and 11.1GB of textures". That's stupidly massive compared to asset sizes for e.g. video game character models and texturing, and would probably choke a commercial real-time engine all on its own.

Re: DreamWorks releases OpenMoonRay source code

#103

Post by ur-whale »

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 scene [1] ... it turns out Moonray only reads its own proprietary format (RDL) and you need to convert like so (I haven't found this documented anywhere, [3] now fails to load for me)

    hd_usd2rdl -in Attic_NVIDIA.usd -out Attic_NVIDIA.rdla
To quote [2]:

Hydra Render Delegate

    MoonRay comes with a Hydra Render Delegate that is compatible with any DCC tool with   Hydra support, for interactive preview rendering. Upon finalization of the Hydra API specification, MoonRay will provide support for final frame batch rendering, and its Hydra Render Delegate will be the supported path to transform USD into MoonRay's internal RDL scene format.
The conversion is not without hiccups:

    Warning: in Tf_PyLoadScriptModule at line 122 of /build/USD-prefix/src/USD/pxr/base/tf/pyUtils.cpp -- Import failed for module 'pxr.Glf'!
    ModuleNotFoundError: No module named 'pxr'
The render is also problematic, is spits a long list of stuff like this (fails to load textures, basically):

    Invalid image file "/tmp/Attic_NVIDIA/Materials/PreviewSurfaceTextures/curtain_mat_inst_Roughness.png": OpenImageIO could not find a format reader for "/tmp/Attic_NVIDIA/Materials/PreviewSurfaceTextures/curtain_mat_inst_Roughness.png". Is it a file format that OpenImageIO doesn't know about?
Resulting render looks ugly (no textures)

In conclusion: fantastic that Dreamworks decided to release Moonray, but at this point, it's still got some very sharp edges.

[1] this one: https://developer.nvidia.com/attic-nvidia

[2] https://openmoonray.org/about

[3] https://docs.openmoonray.org/

[4] https://docs.openmoonray.org/getting-started/installation/bu...

Re: DreamWorks releases OpenMoonRay source code

#104

Post by ur-whale »

boywitharupee wrote: post #100

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…

Real time renderers focus on being real time as the most important constraint and therefore make lots of compromises and take a lot of shortcuts.

Offline renderers try to simulate light transport as exactly as possible within a time budget.

For example, one of the best algorithm to create high quality renders of scenes with very complicated light transport problems (something like this: [1]) uses ray-tracing monte-carlo integration techniques. Up until very recently, this was completely out of reach for a real time render.

[1] https://blenderartists.org/uploads/default/original/4X/9/f/c...

Re: DreamWorks releases OpenMoonRay source code

#105

Post by ykl »

daniel-thompson wrote: post #72

Surprised nobody has mentioned this, but it looks like it implements the render kernels in ISPC^, which is a tool that exposes a CUDA-like SPMD model that runs over the vector lanes in the CPU. ISPC is also used by Disney's Hyperion renderer, see https://www.researchgate.net/publication/326662420_The_Desig... Neat! ^ https://ispc.github.io/

Hyperion does not use ISPC. Source: I am one of the Hyperion developers.

Re: DreamWorks releases OpenMoonRay source code

#106

Post by ur-whale »

boppo1 wrote: post #98
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.

I could write a book about this, but to make it short, what most users of a 3D system like Blender want when they get to the shading/rendering part of their work is to simply:

   - pick an object in the scene

   - pick a pre-made rich and complicated shader (wood, glass, tar, etc...) from a huge library of shaders expressed in a standard form (as in: that will work with whichever render, be it cycles, luxrender, moonray, etc...)

   - drop it to the object without having to screw around for hours with texture scaling, rotation, uvs

   - rinse and repeat until all objects in the scene are shaded
Very few people have the skills/knowledge and patience to put their own shaders together themselves by assembling basic nodes into a large and complicated shader tree.

There has been some (feeble) attempts to build standard libraries of Shaders around Blender:

https://github.com/LuxCoreRender/LoL

https://www.youtube.com/watch?v=mCShkpW1c2w

These are:

   - hard to use

   - not always free

   - not standard and portable across renders
In practice, assigning materials to a large scene in Blender is still a giant, time-consuming PITA.

Re: DreamWorks releases OpenMoonRay source code

#107

Post by NateEag »

NateEag wrote: post #88
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 remember watching Avatar in 3D and being blown away (both by the dreadful screenwriting and by the amazing 3D effect). It taught me that the key you immersive 3D is to treat the screen as a window. Things have depth beyond it, but never protrude out of it. I noticed only two shots in the movie where anything protruded from the screen towards me, and they really caught my attention.

s/key you/key to/

I hate typing on screens.

Re: DreamWorks releases OpenMoonRay source code

#108

Post by daniel-thompson »

ykl wrote: post #105
daniel-thompson wrote: post #72

Surprised nobody has mentioned this, but it looks like it implements the render kernels in ISPC^, which is a tool that exposes a CUDA-like SPMD model that runs over the vector lanes in the CPU. ISPC is also used by Disney's Hyperion renderer, see https://www.researchgate.net/publication/326662420_The_Desig... Neat! ^ https://ispc.github.io/

Hyperion does not use ISPC. Source: I am one of the Hyperion developers.

I thought I saw somewhere it did; I must have misread. Thanks for the clarification!

Re: DreamWorks releases OpenMoonRay source code

#109

Post by DevOfNull »

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?

ChatGPT gives the following answer:

MoonRay is a renderer that creates photorealistic images of computer-generated 3D scenes, using a technique called Monte Carlo ray tracing. MoonRay can be used as part of an animation project, but it is not an animation tool itself. Instead, it is a rendering engine that produces the final images that make up the animation.

To create an animated movie using MoonRay, you would need to use other tools to create the 3D models, textures, and animations that make up the scenes in your movie. Some examples of these tools include Autodesk Maya, Blender, and Cinema 4D. These tools allow you to create and manipulate 3D models, animate them, and add textures and lighting to create the final look of your scenes.

In addition to these 3D modeling and animation tools, you would also need to have a basic understanding of computer graphics and animation principles. This includes concepts such as keyframe animation, camera movement, lighting, and composition.

Once you have created your 3D scenes, you can use MoonRay to render them into high-quality images that can be used in your final animated movie. MoonRay can render images on a single computer, or it can be used with cloud rendering services to speed up the rendering process.

In summary, MoonRay is a rendering engine that produces photorealistic images of 3D scenes created using other 3D modeling and animation tools. To create an animated movie using MoonRay, you would need to use additional tools to create the scenes and have a basic understanding of computer graphics and animation principles.

Re: DreamWorks releases OpenMoonRay source code

#110

Post by 2channelkrt »

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…

I created my account just to reply to this comment.

This is great read. Where can I read more of this stuff? I love the insight you have in there.

Post reply on HN