# Difference between rendering in OpenGL and 3D animation software

With OpenGL and such I can render some pretty amazing looking things in "real time" 60 FPS. However, if I try to make a video of that same scene in let's say Maya, or 3ds Max it would take MUCH MUCH longer for it to render even though it is the same resolution and FPS.

Why do these two types of rendering take different periods of time for the same result?

Note: Yes I do realize that 3D animation software can produce highly superior images to what could be done real time. But for this question I am referring to a scene of equal complexity.

• The short answer is that OpenGL takes shortcuts. Dec 21, 2015 at 18:59

The main difference would be that with OpenGL in let's say a video game, you will have a process called rasterization which basically takes care of determining what part of the scene you see.

It needs to be fast so we can experience it as realtime.

Therefore the algorithm does a few simple steps.

• Check if a certain part of the scene is in my view frustum

• Check if something is in front of it which may needs to be rendered later using a depth buffer

• Order the objects we found to draw

• Draw them by projecting them on the screen

• Shade them based on textures / shaders / lights / ...

On the other hand a rendering software (Blender/Max/Maya/...) most likely uses some kind of raytracing

This involves a lot more math to achieve a higher degree of realism.

It basically works in the same way:

• Create a camera and an image plane in front of it
• Shoot one ray (or multiple sample rays) through each pixel
• Check if the ray hits anything in the scene
• Closest hit is the one to be drawn in the pixel finally (like depth buffer)
• Calculate the light for the given point

....

I'll stopped listing here since this is the point where raytracing takes off.

Instead of only checking if a point is hit, most raytracer now begins to calculate:

• the amount of light a surface penetrates
• how much light gets reflected
• cast new rays from the hitpoint into the scene until it may hit a light source

There are a ton of techniques with different degrees of realism which can be used to calculate the light of a certain point in the scene.

TL;DR The gist would be that a raytracer mostly tries to be physically accurate when it comes the lighting and therefore has a lot of more calculations to do per pixel (sometimes shoot thousands of rays) and on the other hand games get their speed by drawing bigger chunks of the screen with simpler light calculations and a lot of shader tricks which let it look realistic.

### You're comparing apples to oranges

The game is like the view port in your modelling app. You can use the viewport for render and you will get same 60fps speeds.

There is no reason why you can not get realtime graphics that are very good out of modelling software like Maya or 3DS Max. Results that are on par with many games. They have viewport shaders just like games do. There is also a viewport rendering option that chunks frames to disk as fast as it allows (I've done full HD renders at 30 fps from Maya). All you have to do is stop using the provided software raytracers.

There are some differences, though. The primary difference is that you as a user do not optimize stuff as much as game developers do (optimization is using all the tricks in the book). Second your animation primitives work on the CPU because you need the flexibility. In games one can afford to do optimizations. All in all you pay for not having a programming team next to you.

Many of the things may in fact have been precomputed, so they aren't so much faster, just better organized. Baking your indirect illumination will beat non-baked results every day.

### Why are the raytracers slower?

They aren't*, one just tends to do more work on a ray tracer because it's easy. Feature by feature, they aren't much slower in computation cycles. For example, there's no need for a ray tracer to cast secondary rays (life reflections in that case the ray tracer will cull geometry away, or not even load it, in fact mental ray does just that). It's just usually done because it trivial to do so and that's the clear advantage of ray tracers. You can even configure them to run on the CPU in some cases. They are just optimized for different things:

1. Emitting data to disk, not just frames but all data. Something which would break most games speediness instantly.

2. Working on general hardware. The GPU is much faster for certain things once you optimize for the GPU. But it does not work for all loads, in fact an Intel CPU is faster at computing in general than the GPU. The GPU is just massively parallel which the CPU is not. The architecture wins if you can stay in the GPU and minimize transfer and optimize for the GPU architecture.

So you pay for flexibility and ease of use. But yes, I'll admit both Maya and Max suffer from extreme old age. So they could be faster.

TL;DR The difference is mostly in optimization (read lots of tricks) and available external resources.

PS: There is a misconception that this is because it is more physically correct. It certainly can be, but the ray tracer is not inherently more physically correct than your average game or any other computation. In fact, many games use really good models while quite many modelers do not.

• Sorry, but that's plain wrong. OpenGL and DirectX use approximations which are inherently faster than precise raytracing. The whole point of accelerated 3D graphics is having algorithms which balance between realism and speed, looking good enough for most practical uses: gaming, CAD, etc.
– IMil
Dec 21, 2015 at 15:16
• @IMil OpenGL can be used for raytracing. Its faster because it is optimized for the hardware in question. But Maya does NOT have to ray trace. Maya and Max can use openGL and directX just as much as your game. Mayas (and 3ds) viewport is opengl or directX (your choice). The fact that your processor is slower in certain parallel processing loads is another thing. So the answer stands. The standard settings of maya is no more realistic than a standard scanline. Dec 21, 2015 at 15:36

Real-Time Preview

Working in the VFX side of the industry, if you're talking about real-time viewport previews and not production rendering, then Maya and 3DS Max typically also use OpenGL (or possibly DirectX -- pretty much the same).

One of the main conceptual differences between VFX animation software and games is the level of assumptions they can make. For example, in VFX software, it's not uncommon for the artist to load a single, seamless character mesh that spans hundreds of thousands to millions of polygons. Games tend to optimize most for a large scene consisting of a boatload of simple, optimized meshes (thousands of triangles each).

Production Rendering and Path Tracing

VFX software also places the emphasis not on the real-time preview but on production rendering where light rays are actually simulated one at a time. The real-time preview often is just that, a "preview" of the higher-quality production result.

Games are doing a beautiful job of approximating a lot of those effects lately like real-time depth of field, soft shadows, diffuse reflections, etc., but they're in the heavy-duty approximation category (ex: blurry cube maps for diffuse reflections instead of actually simulating light rays).

Content

Coming back to this subject, the content assumptions between a VFX software and game wildly differ. A VFX software's main focus is to allow any possible kind of content to be created (at least that's the ideal, although in practically it's often nowhere close). Games focus on content with a lot more heavier assumptions (all models should be in the range of thousands of triangles, normal maps should be applied to fake details, we shouldn't actually have 13 billion particles, characters aren't actually animated by muscle rigs and tension maps, etc).

Due to those assumptions, game engines can often more easily apply acceleration techniques like frustum culling which enable them to maintain a high, interactive frame rate. They can make assumptions that some content is going to be static, baked down in advance. VFX software can't easily make those kinds of assumptions given the much higher degree of flexibility in content creation.

Games Do it Better

This might be kind of a controversial view, but the game industry is a much more lucrative industry than VFX software. Their budgets for a single game can span in the hundreds of millions of dollars, and they can afford to keep releasing next-generation engines every few years. Their R&D efforts are amazing, and there are hundreds upon hundreds of game titles being released all the time.

VFX and CAD software, on the other hand, is nowhere near as lucrative. R&D is often outsourced by researchers working in academic settings, with a lot of the industry often implementing techniques published many years before as though it's something new. So VFX software, even coming from companies as large as AutoDesk, often isn't quite as "state-of-the-art" as the latest AAA game engines.

They also tend to have a much longer legacy. Maya is a 17-year old product, for example. It's been refurbished a lot, but its core architecture is still the same. This might be analogous to trying to take Quake 2 and keep updating and updating it all the way up until 2015. The efforts can be great but probably won't match Unreal Engine 4.

TL;DR

So anyway, that's a little take on that side of the topic. I couldn't make out whether you were talking about real-time previews in viewports or production rendering, so I tried to cover a bit of both.

• Its also a question of time. Even if you could render at say 60 fps and get acceptable results it rarely pans out to optimize for it. Say it takes 3 minutes per frame and you have 200 frames to render. You might be able to get the 60 fps by hiring a shader writer and by optimizing but then that takes atleast a day or two of your time. But 200 frames at 3 mins only takes 10 hours so you save that cost. In practice its cheaper to buy more hardware and not worry too much about it. Games simply can not take this approach. Dec 23, 2015 at 5:02
• @joojaa It's also a little bit more complex though. Just doing really good real-time shaders for Maya might take a year or so at the very, very least, even from an experienced shader developer (with lesser gains), because the flexibility of the nodal system there is targeted towards production rendering. It would take a reverse engineering mindset and kind of new kind of GLSL/HLSL code generation technique (like a meta programming system) to translate these general-purpose shader nodes into a real-time shading system that captures the range of effects of UE 4, e.g. Dec 23, 2015 at 5:06
• @joojaa UE 4's shader engine is directly targeted towards an heavily-approximated PBR mindset (a very small subset of Disney's PBR shader). They designed even their material system for a fast, real-time purpose, instead of starting with something like Maya's material system which isn't at all (designed for raytracing). Even if the brightest of the UE 4 worked on VP 2.0, they'd have to work night and day for possibly years to achieve the same results against a design not intended to do this sort of stuff. Dec 23, 2015 at 5:08
• but thats a onetime cost even if youd have that pipeline in a VFX app each scene might need that extra optimization. Theres no reason why a maya user could't render in UDK for example for same shader dev platform. Dec 23, 2015 at 5:15
• Dec 23, 2015 at 5:20