Rendering: what it means, in video, 3D, and web

"Rendering" is one of those words that every team uses with a different meaning and no one clarifies. The video editor says "I'm rendering" and means exporting the timeline to an .mp4 file. The motion designer says "the render took all night" and means a 3D sequence processed on their computer. The frontend developer says "we're rendering on the server" and means something completely different. All three use the same verb, and all three are right.

This article walks through the three meanings—video, 3D, and web—explains what the machine technically does when it "renders" in each case, and why understanding those differences matters when managing creative production.

A definition that covers all three cases

In its broadest sense, rendering is transforming a representation of something into a visible image. That representation can be:

• A video timeline with cuts, layers, effects, and transitions (video).
• A 3D scene with geometry, materials, lights, and a camera (3D).
• A tree of components with data and styles (web).

In all three cases, the computer takes instructions—"this is how this should look"—and produces a result—"this is what you see." The difference is in how it does it and into what it converts it.

Video rendering: from the timeline to the file

When a video editor "renders," the software (Premiere, Final Cut, DaVinci Resolve, After Effects, CapCut) goes through the timeline, applies all the effects, transitions, and color corrections, mixes the layers, syncs with the audio, and produces a linear video file—typically MP4, MOV, or MXF.

The process has two technical phases:

Decoding. Each clip is originally in a compressed format (H.264, ProRes, R3D if it's RAW from RED). The render engine decompresses it frame by frame so it can be processed.

Encoding. Once the frames are processed with all the effects applied, they are recompressed to the output codec (H.264 for web, ProRes for archive, AV1 for modern streaming). This phase usually takes the most time and depends heavily on the chosen codec.

Times vary enormously depending on complexity. The same project can render at a 0.5x ratio (half the time the video runs) if there are only cuts and a little color, or take several hours if there are layers of motion graphics, particle simulations, and heavy plugins like Sapphire, Magic Bullet, or Trapcode.

Three factors change the timing more than any other:

• Resolution and frame rate: 4K60 can take four times longer than 1080p30 in the same project.
• Output codec: H.265 compresses better than H.264 but encodes more slowly on CPU; with hardware acceleration (NVIDIA's NVENC, Intel's Quick Sync, Apple VideoToolbox), the difference shrinks considerably.
• Effects not accelerated by GPU: certain plugins only process on CPU. A single layer of an old plugin can multiply the total render time.

For serious production, intermediate and review renders are done on proxies (low-resolution versions of the original material), and only the final render is done at delivery quality.

3D rendering: from the scene to the image

3D rendering is the technically most interesting case and where the word originates. When a 3D artist finishes a scene, what they have is a mathematical description: vertices that form polygons, materials with their properties (color, reflectivity, roughness), light sources, a camera with a point of view. To produce an image, that description has to be converted into pixels, and that requires enormous calculations.

There are two families of algorithms:

Rasterization, where for each polygon it calculates which pixels it covers and colors them according to the materials and lights. It's fast, it's what any real-time video game uses, but it produces an image that's more "correct" than "photorealistic." Shadows, reflections, and indirect lighting are approximated with additional techniques.

Ray tracing (ray tracing and path tracing), where the path of light is simulated: for each pixel, virtual rays are cast that bounce around the scene, calculating reflection, refraction, soft shadows, and global illumination. It produces far more realistic images but demands enormously more computation.

The modern concept of ray tracing comes from a paper by Turner Whitted in 1980, "An Improved Illumination Model for Shaded Display," which described how to simulate reflections and refractions recursively. Six years later, James Kajiya formulated "The Rendering Equation" at SIGGRAPH 1986, the mathematical equation that describes how light is transported in a scene. Today's practice—path tracing in engines like Arnold, V-Ray, Cycles, Octane, Redshift—is a computationally achievable version of that equation.

RenderMan, developed at Pixar and released in 1989, was the first commercial render engine designed for film production. Toy Story (1995), the first computer-animated film, was rendered with RenderMan on a farm of 117 SUN workstations, taking around four hours per frame. To get a sense of the scale: each minute of film is 1,440 frames at 24 fps, and the film runs 81 minutes.

The most widely used 3D render engines today:

• V-Ray (Chaos Group, since 1997): standard in architecture and advertising.
• Arnold (Solid Angle, 2009; acquired by Autodesk in 2016): standard in film VFX.
• Octane (OTOY, 2010): a pioneer in pure GPU rendering.
• Redshift (2014, now Maxon): very popular in motion graphics.
• Cycles (Blender Foundation, 2011): integrated into Blender, free and very capable.
• Eevee (Blender, 2019) and Unreal Engine (Epic Games, especially UE5 since 2022 with Lumen and Nanite): real-time, redefining what can be done outside an offline engine.

The CPU vs GPU distinction is important. Until roughly 2010, almost all 3D rendering was done on CPU. With the maturity of CUDA (NVIDIA, 2007), engines like Octane and later Redshift demonstrated that GPUs could accelerate rendering by 10x to 50x for certain types of scenes, transforming professional workflows. Today it's common for engines to offer both modes and for scenes to be rendered on mixed farms.

Render farms are sets of machines (dozens, hundreds, thousands) that process frames in parallel. They exist as in-house infrastructure at large studios and as a cloud service (RebusFarm, GarageFarm, Coreweave). For a sequence of 1,000 frames that would take 30 hours on a single machine, a farm of 100 machines finishes it in under an hour.

Web rendering: SSR, CSR, SSG, ISR

The third meaning of "rendering" appears in web development and is completely different in mechanics, although conceptually it shares the same idea: converting a representation (components and data) into a visible image (the page the user sees).

There are four main strategies:

CSR (Client-Side Rendering). The browser downloads JavaScript, runs it, and builds the page on the user's device. It's what the first pure React, Angular, and Vue applications did. Advantage: rich interactivity, navigation without reloads. Disadvantage: the page takes longer to show content and is worse for SEO.

SSR (Server-Side Rendering). The server runs the code and sends already-rendered HTML to the browser. Frameworks like Next.js, Nuxt, SvelteKit, and Remix popularized this approach from around 2016-2020. Advantage: content visible immediately, better SEO. Disadvantage: each request requires server work.

SSG (Static Site Generation). The site is built once—at build time—and served as static HTML. It's what Hugo, Jekyll, Astro, and the static modes of Next.js use. Advantage: fast, cheap, easy to cache globally. Disadvantage: the content is static until the next build.

ISR (Incremental Static Regeneration). A hybrid between SSG and SSR, popularized by Next.js: static pages that regenerate automatically when the data changes, without a full rebuild. It combines static speed with dynamic freshness.

The choice among these strategies directly affects perceived performance (Core Web Vitals: LCP, CLS, INP), infrastructure cost, and SEO. Polimake.com uses Next.js 16 with a mostly static mix, which explains why pages like this one load fast and are indexable.

Why it matters in creative operations

Although the mechanics are different, the three types of rendering share a common operational problem: they are unpredictable bottlenecks that can block publishing.

• A video render that fails at 3 AM stops the client delivery.
• A 3D render that takes longer than expected delays the entire post-production.
• A web build that breaks in production leaves an unstable site.

The difference between a team that suffers these blockers and one that anticipates them is management discipline, not technical talent.

Mistakes that repeat render after render

Exporting an old version of the project. After a minor change, the editor forgets to save and renders the previous version. Only the client finds out. Solution: explicit version naming and, better yet, a quick review pass of the first minute before uploading.

Wrong codec for the destination. Rendering to ProRes 4444 to upload to Instagram wastes 95% of the upload time. Rendering a master headed for the archive to H.264 8 Mbps destroys quality forever. The codec choice is decided by destination, not by habit.

Out-of-sync audio. Common when the project's frame rate doesn't match that of the original material. The apparent sync in the timeline falls apart in the render. Solution: make sure each clip is interpreted at the correct frame rate before starting.

Excessive file size. A 4 GB MP4 for a landing page where you see 30 seconds. Solution: bitrate appropriate to the destination, not the maximum possible.

Render with black frames. A typical symptom of a corrupted cache or a plugin that didn't finish processing. Solution: clear the cache, pre-render problem layers, export again.

Loss of burned-in subtitles. The render is done without the subtitle track, or with the wrong track. Solution: name the track explicitly and check before exporting.

Low-priority render. A single machine rendering while someone keeps editing on it usually ends badly: usage spike, failure, you have to start over. Solution: a dedicated machine for rendering, or render after hours, or use a render farm.

3D render without a test pass. Starting a 200-frame render at high quality without first doing a five-frame test at low resolution is a recipe for frustration. If the test comes out fine, the final one probably will too. If the test fails, you've lost five minutes instead of twelve hours.

How to fit rendering into the workflow

What distinguishes a team that delivers well from one that improvises is how much of the rendering is systematized.

• Export presets that already have the correct codec, bitrate, resolution, and naming for each destination.
• Render queue—Adobe Media Encoder, Deadline, Tractor in film, internal systems—that processes deliveries in batches, after hours, without tying up the main machine.
• Render farm server or cloud service when volumes justify it.
• Test passes required before any long render.
• Versioning of the project so that rendering the wrong version is rare and detectable.
• Automatic archiving of the final render, its clean version, and the editable project, in a predictable path.

Creative operations is the system that ensures this doesn't depend on "someone remembering." At Polimake, Studio defines the export criteria—which codec, which bitrate, which naming, which versions per channel—; Media runs the render and archives the result; Studio coordinates the timing dependencies so a long render doesn't run over an urgent delivery.

This logic connects to the decision on bitrate per channel, the choice of delivery format, and the planning of audiovisual production in general.

To wrap up

Rendering seems like a technical step at the end of the process. In practice, it's one of the points where the most projects fail at delivery: a poorly chosen codec invalidates a job, a slow render blocks a campaign, an outdated version reaches the client. The three meanings—video, 3D, web—share that fragility.

What changes things isn't having better hardware, although it helps. It's having well-documented default decisions, a dedicated render queue, mandatory test passes, and an archiving system that remembers what was rendered and why. With that discipline, "rendering" stops being a source of drama and becomes what it should be: the last predictable step before publishing.

Quick reference

• Video rendering: timeline → file. Codec by destination, not by habit.
• 3D rendering: scene → image via rasterization (fast) or ray/path tracing (realistic).
• Web rendering: components → HTML, via CSR / SSR / SSG / ISR as needed.
• GPU accelerates certain 3D renders by 10-50x; CPU still rules in some cases.
• Always a test pass before a long 3D render.
• Export presets by destination, not manual decisions every time.
• Dedicated queue or render farm for volume.
• Versioning and naming that let you know what's being rendered.
• Automatic archiving of the result and the editable project.