Introduction
In the previous articles, we built a form (modeling) and clothed its surface in material (texturing and rendering). But completing an actual work takes a much longer journey than this. A model unwraps its UVs, dons textures, gains a skeleton, learns movement, and finally becomes a single picture or a moving image under light. We call this sequence of steps a **pipeline**.
What is interesting is that the same model takes a quite different pipeline shape depending on whether it heads for a game or a film. A game must draw the screen dozens of times per second, so speed is absolute. A film, on the other hand, can spend hours computing a single frame, so image quality comes first. This fundamental difference influences the entire way assets are made.
In this article we first survey the overall flow of the 3D asset pipeline, then look at how the real-time environment of games and the offline environment of film diverge, and finally cover the formats and collaboration practices for exchanging assets between them.
The Overall Flow of the Asset Pipeline
First let us look at the standard steps a single 3D asset passes through. Whether game or film, the main trunk is similar.
The standard flow of the 3D asset pipeline
[Modeling] build the form
│
▼
[UV Unwrap] flatten the surface into 2D
│
▼
[Texturing] apply material and color (PBR maps)
│
▼
[Rigging] embed a skeleton so it can move
│
▼
[Animation] move the skeleton to create motion
│
▼
[Render] shine light and output the final result
Let us briefly touch on each step.
- **Modeling**: Build the form as a mesh.
- **UV Unwrapping**: Flatten the surface into a plane to apply textures.
- **Texturing**: Define material with PBR maps such as base color, roughness, and normal.
- **Rigging**: Embed a skeleton and control rig into characters or moving objects. It is like putting joints inside a doll.
- **Skinning/Weighting**: Decide how much each bone moves which part of the mesh, by weight.
- **Animation**: Move the skeleton over time to create motion.
- **Render**: Set up the camera and lighting, and output the final image or video.
Here a fork appears. Depending on whether the last steps, especially the render, are real-time or offline, the way the earlier steps are done is affected, reaching back up the chain.
The Real-Time Pipeline: The World of Game Engines
A game must respond instantly to player input and draw a new screen at every moment. It usually has to produce 30, 60, or more frames per second without stutter, so the time allowed to draw one frame is only a few milliseconds. This harsh constraint governs every decision in the real-time pipeline.
The real-time render loop (simplified)
┌─────────────────────────────────────────┐
│ every frame (e.g. complete within 16.6ms)│
│ │
│ handle input ──▶ game logic ──▶ culling │
│ │ │
│ ▼ │
│ submit GPU draw calls ──▶ shade │
│ │ │
│ ▼ │
│ output to screen │
└─────────────────────────────────────────┘
repeat the above dozens of times per second
Representative game engines include **Unity** and **Unreal Engine**. Both integrate real-time rendering, physics, sound, and input handling, taking assets and turning them into interactive experiences that actually move.
When making assets for a real-time environment, the following concepts are key.
Poly Budget
There is a limit to how many polygons can be drawn at once on screen. So the number of polygons available to each asset is decided in advance, called the **poly budget**. The budget differs for characters, props, and environments, and making something look as good as possible within it is a core competency of the real-time artist.
LOD (Level of Detail)
Distant objects do not need to be drawn in detail. So the same object is prepared at several levels of precision, swapped in and out depending on distance from the camera. This is called **LOD**.
LOD level switching
Distance Model used Polygon count (example)
──────── ──────────── ──────────────
near LOD0 (high) 20,000
medium LOD1 8,000
far LOD2 2,000
very far LOD3 (low) 500
* Swap to lighter models with distance to secure performance
Draw Call
A single command in which the CPU tells the GPU "draw this" is a **draw call**. When draw calls grow numerous, the CPU becomes a bottleneck and performance drops. So an optimization that bundles many objects into one (batching) to reduce the number of draw calls is important.
Draw call optimization concept
Before After (batching)
obj A ──draw call 1──▶ obj A ┐
obj B ──draw call 2──▶ GPU obj B ├─draw call 1──▶ GPU
obj C ──draw call 3──▶ obj C ┘
3 draw calls 1 draw call (less CPU load)
Beyond these, various optimizations are mobilized, such as combining textures into an atlas, replacing detail with normal maps, and grouping by identical material. The essence of real-time work is "as plausible as possible with limited resources."
The Offline Pipeline: The Render Farm of Film
A frame of film or high-quality video is computed once and done. In return, there is no compromise on image quality. It is fine for one frame to take tens of minutes to hours. A 90-minute animated film needs over a hundred thousand such frames, far beyond what a single computer can handle. This is where the **render farm** enters.
How a render farm works
[submit job]
split shots/frames into work units
│
▼
[scheduler / queue] distribute jobs to nodes
│
┌────┼────┬────┐
▼ ▼ ▼ ▼
node1 node2 node3 ... nodeN (tens to thousands)
│ │ │ │
└────┴────┴────┘
│
▼
[collect results] gather finished frames into video
A render farm is a distributed system in which many computers (nodes) split frames and compute them simultaneously. Work that would take 1000 days on one computer for a film can be finished in a day if split across 1000 machines. Offline rendering mainly uses ray-tracing and path-tracing families, faithfully computing reflections, refraction, indirect light, and subsurface scattering (translucent surfaces like skin) in a physically accurate way.
In the offline environment, the constraints on polygon count and texture resolution are far looser. You can create real contours with displacement, mobilize hundreds of millions of polygons, and stack several 8K textures. Because image quality is the top priority.
Real-Time vs. Offline: The Core Comparison
Here is the difference between the two pipelines at a glance.
Real-time vs. offline comparison
Item Real-time (game) Offline (film)
───────────── ────────────────── ──────────────────
frame time a few milliseconds minutes to hours
render method mainly rasterization mainly ray/path tracing
polygon limit strict (poly budget) loose
texture res limited very high
optimization very heavy (LOD/calls) relatively light
interaction yes (player input) no (fixed camera)
goal smooth performance the best image quality
typical tools Unity, Unreal Cycles, Arnold, etc.
That said, this boundary is also blurring. As the image quality of real-time engines rapidly improves, techniques like virtual production are growing — displaying film and drama backgrounds in real time on huge LED walls and filming in front of them. Games too have begun adopting partial ray tracing, so the two worlds grow to resemble each other. The supported range of these features may differ depending on hardware and engine version.
Optimization: The Tech That Upholds Real Time
In the real-time pipeline especially, optimization is not a choice but a matter of survival. Besides the LOD and draw calls seen above, here are frequently used techniques.
- **Culling**: Things off-screen or hidden behind other objects are skipped and not drawn at all. It prevents the waste of drawing what cannot be seen.
- **Texture atlas/compression**: Combine multiple textures into one and compress them into GPU-friendly formats to save memory and bandwidth.
- **Instancing**: When drawing thousands of the same object (trees, grass, crowds), send the data once and repeat it with only the positions changed.
- **Mipmap**: Prepare textures at multiple sizes in advance, using small textures for distant surfaces to reduce flickering and raise performance.
- **Baked Lighting**: Pre-compute the shadows and indirect light of static environments and bake them into textures (lightmaps). It is light because it does not recompute every frame in real time.
The distribution of the frame budget (concept)
Within one frame of 16.6ms
████████ render (shading/lighting)
████ physics/collision
███ game logic/AI
██ animation
█ everything else
* If any one part exceeds its budget, the frame drops (stutter)
Offline is not entirely without optimization either. To reduce render time, sample counts are adjusted, denoisers remove noise, and unnecessary ray computation is cut. But the degree of urgency is incomparable to real time.
Exchange Formats: glTF and USD
For many tools and people to exchange assets, a common language — a standard file format — is needed. Let us look at the two most notable today.
The character of major 3D exchange formats
Format Main use Trait
────── ────────────────── ─────────────────────────
glTF real-time, web, game optimized for light fast
delivery transfer, PBR standard built in
USD large film production strong at layering and
collaboration composing huge scenes
FBX general asset exchange long-standing industry standard
OBJ simple shape exchange simple, classic, weak animation
- **glTF (GL Transmission Format)**: An open format created by the Khronos Group. Called "the JPEG of 3D," it is light and optimized for transfer, and holds PBR materials as a standard. Widely used in web and real-time environments.
- **USD (Universal Scene Description)**: A format developed and released by Pixar. It is powerful for many people splitting huge film scenes into layers, working simultaneously, and composing them. It is establishing itself as the standard for large-scale production collaboration.
- **FBX**: A format long used as the de facto standard for asset exchange, with broad compatibility.
Each format has different strengths, so you pick the right one depending on where the asset is headed. For a web viewer or game, glTF; for film collaboration, USD is the natural choice.
Collaboration: A Pipeline Is Ultimately a Flow of People
In large projects, it is rare for one person to do every step. Modelers, texture artists, riggers, animators, and lighting/render staff each take a step and pass the asset along. So a pipeline is both a technology and an agreement between people.
The flow of a collaborative pipeline
modeler ──▶ texture ──▶ rigger ──▶ animator ──▶ lighting/render
│ │ │ │ │
└─────────┴──────────┴─────────┴──────────────┘
version control · asset library · naming rules
* each step's result becomes the next step's input
* without consistent rules, assets misalign and work stalls
Smooth collaboration requires a few agreements: consistent **naming rules** (unify file and object names), **version control** (track who changed what and when), a shared **asset library** (manage reused assets in one place), and a **review process** between steps. Without such agreements, no matter how skilled the artists gathered, assets will misalign and work will stop.
If the technical pipeline is a flow of data, the collaborative pipeline is a flow of people and responsibility. Good studios design both well.
Rigging and Animation: Breathing Life into Assets
In the middle of the pipeline lies the step that makes a static model move — rigging and animation. Let us look a little more closely at how this step works.
The basic structure of rigging
[mesh] ── the visible form
│
│ embed a skeleton inside
▼
[skeleton] ── a hierarchy of bones with joints
│
│ decide which part of the mesh each bone moves
▼
[skinning/weights] ── the binding strength of bone and mesh
│
▼
[control rig] ── controls easy for the animator to handle
**Rigging** is the work of embedding a digital skeleton into a model. Just as a person moves with a skeleton, a 3D character moves along its bones. Then, with **skinning** (or weight painting), you decide how much of the surface each bone drags along. For the skin to fold naturally when the elbow bends, these weights must be set well.
Finally, you build a **control rig**. Because it is tedious for an animator to rotate each bone directly, you make intuitive controls like a hand or a foot. A well-made rig is like a sophisticated puppet, letting the animator create motion quickly and naturally.
Real-time and offline diverge here too. Game characters have constraints on bone count and range of influence, often limiting how many bones can affect a single vertex. Film, by contrast, has loose constraints and can mobilize very sophisticated facial rigs and even muscle simulation.
One Asset's Journey: From a Sword to an In-Game Weapon
Abstract steps alone are hard to grasp, so let us follow a hypothetical asset through the pipeline. Take a sword destined for a game.
A sword asset's pipeline journey (real-time)
1. High-poly creation
sculpt the blade's nicks and the handle's leather grain in detail
2. Low-poly creation (retopology)
a light mesh fitted to the poly budget for the game
3. UV unwrapping
efficiently lay out the blade, handle, and guard
4. Baking
bake high-poly detail → low-poly normal map and AO
5. Texturing
metal blade, leather handle, rust and grime in PBR
6. Export
export to glTF/FBX and import into the game engine
7. Engine setup
create LOD levels, assign collision mesh, link materials
The key to this journey is the **division of labor between high-poly and low-poly**. Sophisticated detail is made on the high-poly, but what actually goes into the game is the light low-poly. The bridge between them is the baked normal map. Thanks to this structure, a sophisticated sword can appear on screen with few polygons.
The same sword takes a different journey if it heads for film. With a loose poly budget, you might skip the low-poly step and use the high-poly directly, and you need no real-time-only steps like LOD or collision mesh. Instead, you push detail to the limit with 8K textures and displacement. That the destination determines the shape of the work is well shown by this single sword.
Common Pipeline Pitfalls
There are problems frequently encountered when designing and running a pipeline. Knowing them in advance can spare you costly rework.
- **Scale mismatch**: Each tool has different default units (centimeters, meters, etc.), so it is common for size to differ 100-fold when moving assets. Decide a unit standard early in the project.
- **Late optimization**: Chasing image quality only to exceed the poly budget at the end and rework everything. Build with the target budget in mind from the start.
- **Lack of naming rules**: If file names are inconsistent, automation tools cannot find assets and collaboration tangles. Document the rules.
- **Ignoring baking errors**: Ignoring flaws from normal map baking (cage problems, face intersections) makes strange shadows or streaks appear in the final image. Review right after baking.
- **Blind faith in formats**: Do not assume one format transfers all information perfectly. Animation, blend shapes, and materials can be dropped, so always verify after transfer.
- **Version confusion**: Without tracking who uses which version, accidents of working on old assets occur. Make version control a habit.
What these pitfalls share is "a lack of early agreement." A pipeline carries the rules set at the start all the way through. If you clearly fix agreements on units, naming, budget, and format at the project's outset, you can prevent most of the problems that arise downstream.
How the Modern Pipeline Is Changing: The Convergence of Two Worlds
We drew a clear distinction between real-time and offline earlier, but in recent years that boundary has blurred rapidly. As the two worlds borrow each other's technology, new ways of working are emerging.
The convergence of real-time and offline
past present
────────── ──────────
real-time ── clear wall ── offline
(speed) (quality)
▼ boundary blurs ▼
real-time ─ virtual prod ─ offline
game RT adopted
film-grade engine render
common format (USD)
A representative change is **virtual production**. A real-time engine displays the background on a huge LED wall, and actors perform in front of it while the camera films. As the camera moves, the viewpoint of the background inside the LED follows in real time, yielding on the spot a shot that feels as if you were in the actual place. Real-time technology from game engines has entered deep into work that used to be the domain of film.
Another current is **collaboration through common formats**. USD in particular helps different fields — film, games, visualization — share the same way of describing assets. As one asset can be exchanged consistently across many tools and fields, the walls between pipelines lower.
How USD aids collaboration (concept)
layer A (modeler) ┐
layer B (texture) ├── composition ──▶ final scene
layer C (animation) │ each layer can be
layer D (lighting) ┘ edited/swapped independently
That said, these features and workflows are a rapidly evolving area, so the specific supported range and best practices may differ depending on the version of the tool or engine. The big trend is clear. Real-time and offline, while keeping their own strengths, are growing to resemble each other by sharing assets and borrowing technology. So today's 3D worker is better off understanding the mindset of both sides rather than being confined to just one.
Asset Management: Versions and Caches
The larger the scale, the more "how you store and track assets" governs work speed. Let us look at two concepts commonly handled in the later pipeline.
The flow of asset version control
sword_v001 ──▶ sword_v002 ──▶ sword_v003 (current)
(draft) (revision) (approved)
│
can branch here
▼
sword_v003_variant
* You must preserve old versions, not delete them, to roll back.
- **Version control**: Preserves the change history of an asset so that when a problem occurs you can roll back to a previous state or track who changed what. It is the same principle as code version control, but with the peculiarity of handling large binary files.
- **Cache**: Pre-computing heavy results like simulations (cloth, hair, crowds, fluids) and storing them as files. Rather than recomputing each time, you load the stored cache to speed up work. Formats like Alembic are often used for such cache exchange.
Using a simulation cache
heavy simulation computation (once)
│
▼
[save as cache file] ── freeze the result
│
┌─────┴─────┐
▼ ▼
render work reuse in another scene
(quickly) (no recomputation needed)
In this way, a large pipeline does not stop at merely making assets; it runs on a system that systematically stores, tracks, and reuses them. Good asset management is not very visible, but its value becomes clear as a project grows.
Closing
The 3D pipeline is like a long river that begins at modeling and ends at rendering. That river splits into two branches depending on its destination. The real-time world of games, which must redraw at every moment, accepts constraints and optimizations like poly budgets, LOD, and draw calls for the sake of speed. The offline world of film, which can spend time on a single frame, mobilizes render farms and pushes image quality to the limit.
The two worlds pursue different values, but the fundamentals of the asset at the starting point are the same. Clean topology, a well-laid UV, and faithful PBR textures form the foundation of good results whichever way you go. And formats like glTF and USD, along with clear collaboration agreements, let those assets flow smoothly between people and tools.
Whichever path you take, those who can picture the whole pipeline in their mind make their work knowing where it is going. That big picture is, in the end, the firmest foundation for good assets and good collaboration.
References
- [Khronos glTF Official Site](https://www.khronos.org/gltf/)
- [OpenUSD Official Site](https://openusd.org/release/index.html)
- [Unreal Engine Official Documentation](https://docs.unrealengine.com/)
- [Unity Official Manual](https://docs.unity3d.com/Manual/index.html)
- [Blender LOD and Optimization Guide](https://docs.blender.org/manual/en/latest/)
- [NVIDIA Ray Tracing Technology Overview](https://developer.nvidia.com/rtx/ray-tracing)
- [Pixar USD Introduction](https://graphics.pixar.com/usd/release/index.html)
- [Autodesk FBX Overview](https://www.autodesk.com/products/fbx/overview)
현재 단락 (1/229)
In the previous articles, we built a form (modeling) and clothed its surface in material (texturing ...