Live data from Hacker News

DreamWorks releases OpenMoonRay source code

github.com

81–90 of 154 posts

Re: DreamWorks releases OpenMoonRay source code

#81

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?

Re: DreamWorks releases OpenMoonRay source code

#82
post #78

Earlier quoted context omitted.

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.

DNeg did one sequence in the latest Matrix film. But it looked very obviously “real-time”. But yeah otherwise I agree with your points. The person you’re replying to is vastly over estimating unreal use for final CG. Definitely isn’t being primarily used for hero character work.

Yup. The state of the art for real-time rendering just isn't there yet for hero work. Even ILM's custom Helios renderer is only used for environments and environment-based lighting, as far as I've read. Assets, fx shots, and characters are still rendered offline.

Even with real-time rendering for environments, I'm sure there's plenty of post-processing "Nuke magic" to make it camera-ready. It's not like they're shooting UE straight to "film".

I have seen reports of Unreal Engine being used quite successfully for pre-viz, shot planning, animatics, etc., though.

Re: DreamWorks releases OpenMoonRay source code

#83

Earlier quoted context omitted.

The competitive advantage is in storytelling, not necessarily visual fidelity. People will watch a somewhat worse looking movie with a better story than a better looking movie with a worse story. And honestly, can anyone really tell slightly worse graphical quality these days when so many animated movies already look good? The exception, of course, is James Cameron and his Avatar series. People will absolutely watch…

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.

Re: DreamWorks releases OpenMoonRay source code

#84

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

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 desktop DDR has bandwidth that is too low for this, in general, on desktop platforms, given the compute characteristics of a modern GPU, which has shitloads of compute. Despite all that, signal integrity on parallel RAM interfaces has very tight tolerances. DDR sockets are very carefully placed with this in mind on motherboards, for instance. GDDR, which most desktop class graphics cards use instead of normal DDR, has much higher bandwidth (e.g. GDDR6x offers 21gbps/pin while DDR5 is only around 4.8gbp/s total) but even tighter interface characteristics than that. That's one reason why you can't socket GDDR: the physical tolerances required for the interface are extremely tight and the signal integrity required means a socket is out of the question.

Here is an example, go compare the RAM interfaces between an Nvidia A100 with HBM versus an Nvidia 3080, and see how this impacts performance. On compute-bound workloads, an Nvidia A100 will absolutely destroy a 3080 in terms of overall efficiency. One reason for this is because the A100 will have a memory interface that is 3-4x wider which is absolutely vital for lots of workloads. That means 3-4x the amount of data can be fed into execution units in the same clock cycle. That means you can clock the overall system lower, and that means you're using less power, while achieving similar (or better) performance. The only way a 3080 with a 256-bit bus can compare to a A100 with a 1024-bit bus is by pushing the clocks higher (thus increasing the rate of transfers/second), but that causes more heat and power usage, and it scales very poorly in practice e.g. a 10% clock speed increase might result in a measly 1-2% improvement.

So now, a bunch of things fall out of these observations. You can't have extremely high-bandwidth RAM, today, without very tight interface characteristics. For desktops and server-class systems, CPUs don't need bandwidth like GPUs, so they can get away with sockets. That has some knock on benefits; CPU memory can benefit from economies-of-scale on selling RAM sticks, for example. Lots of people need RAM sticks so you're in a good spot to buy more. And because sockets exist "in three dimensions", there's a huge increase in "density per square-inch" on the motherboard. If you want a many-core GPU to remain fed, you need soldered RAM which necessitates a fixed SKU for deployment, or you need to cut down on the compute so lower-bandwidth memory can feed things appropriately, negating the reason you went to GPUs in the first place (more parallel compute). Soldered RAM also means that the compute/memory ratios are now fixed forever. One nice thing about a CPU with sockets is that you can more flexibly arbitrage resources over time; if you find a way to speed something up with more RAM, you can just add it assuming you aren't maxed out.

Note that Apple Silicon is designed for lower power profiles; it has good perf/watt, not necessarily overall best performance in every profile. It uses 256 or 512-bit LPDDR5X, and even goes as high as 1024-bit(!!!) on the Max series apparently. But they can't just ignore the laws of physics; at extremely high bandwidth and bus widths you're going to be very subject to signal interface requirements. You have physical limitations that prevent the bountiful RAM sticks that each have multiple, juicy Samsung DDR5 memory chips on them. The density suffers. So Apple is only limited to so much RAM; there's very little way around this unless they start stacking in 3-dimensions or something. That's one of the other reasons they likely have moved to soldered memory for so long now; it simply makes extremely high performance interfaces like this possible.

All in all the economies of scale for RAM sticks combined with their density means that GPUs will probably continue to be worse for workloads that benefit from lots of memory. You just can't meet the combined physical interface and bandwidth requirements at the same density levels.

Re: DreamWorks releases OpenMoonRay source code

#85
post #80

o boi, shrek engine

Memes aside, this has actually never been used for a shrek film. The first film it was used for was How to Train Your Dragon 3.

If it was used in any of the Puss in Boots movies, then it was at least used in a Shrek spinoff...

Re: DreamWorks releases OpenMoonRay source code

#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://github.com/dreamworksanimation/arras4_core

[2]: https://github.com/dreamworksanimation/arras4_node

[3]: https://github.com/dreamworksanimation/arras_render

Re: DreamWorks releases OpenMoonRay source code

#87
post #65
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

I don't think Arc and Xeon Phi have much commonality at all

Re: DreamWorks releases OpenMoonRay source code

#88

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

Re: DreamWorks releases OpenMoonRay source code

#89
post #85
post #80

Earlier quoted context omitted.

Memes aside, this has actually never been used for a shrek film. The first film it was used for was How to Train Your Dragon 3.

If it was used in any of the Puss in Boots movies, then it was at least used in a Shrek spinoff...

Puss in Boots: The Last Wish was rendered with this

Re: DreamWorks releases OpenMoonRay source code

#90

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?

In the most casual sense, a renderer is what "takes a picture" of the scene.

A scene is made of objects, light sources, and a camera. The renderer calculates the reflection of light on the objects' surfaces from the perspective of the camera, so that it can decide what color each pixel is in the resulting image.

Objects are made up of a few different data structures: one for physical shape (usually a "mesh" of triangles); one for "texture" (color mapped across the surface); and one for "material" (alters the interaction of light, like adding reflections or transparency).

People don't write the scene data by hand: they use tools to construct each object, often multiple tools for each data structure. Some tools focus on one feature: like ZBrush for "sculpting" a mesh object shape. Other tools can handle every step in the pipeline. For example, Blender can do modeling, rigging, animation, texturing and material definition, rendering, post-processing, and even video editing; and that's leaving out probably 95% of its entire feature set.

If you are interested at all in exploring 3D animation, I recommend downloading Blender. It's free software licensed under GPLv3, and runs well on every major platform. It's incredibly full-featured, and the UI is excellent. Blender is competitive with nearly every 3D digital art tool in existence; particularly for animation and rendering.

Post reply on HN