The 5-Minute Rule: How We Keep Every 3D Scene Consistent, Fast, and Safe

Every few months someone posts that their studio has gone fully automated, or that some tool cut their delivery time by an impossible number. The replies fill up with fire emojis. I read those posts the way I read horoscopes. Occasionally close, mostly written for the feed.

The least glamorous thing we do here is also the one that saves us the most time, and nobody posts about it. It is how we organise a project. Not the rendering, not the plugins. The folders, the layers, the names, and the machines underneath them. We wrote all of it down years ago, and every project we touch now opens the same way for every artist.

The five-minute rule

The standard is blunt. Any artist here should be able to open any project built by anyone else and understand the whole thing in five minutes. No phone call, no guessing which of four files is the real one. If a project fails that test, the system is wrong, not the person who opened it.

Everything below is just how we keep that promise.

One project, one folder tree

Every job lives inside a year. The top of our file server is filed by financial year, and because we are in India that year runs April to March, so a job opened in mid 2026 sits under 2026\PROJECT_NAME. Filing by year keeps the active tree small and turns archiving into a once-a-year decision instead of a constant chore.

Inside the project, every job starts from the same empty skeleton. The top-level folders are numbered, so they sort the same way on every machine, no matter who set the project up.

A few things the structure settles for good. 01_BRIEF holds the brief together with the CAD and references it arrived with, so the starting point of a job is always in one place. 02_3D has one folder per area, living room, dining room, and so on, each holding its own .max file, which keeps files light and lets two artists work different rooms at once. 03_TEXTURES is for custom maps only; most of our textures live in a shared library on the server, so this folder stays empty unless a job needs something made specially for it.

04_RENDER is organised by stage, grey views, first cut, second cut, then final, and each stage holds the same area folders, so the render history reads at a glance. 05_POST turns that around, a folder per area, each with its own draft, first cut, second cut and final. 06_DELIVERY is what the client receives, and 07_ARCHIVE is where the finished job is packed away.

We keep a finished project on the main server for about two years, because that is roughly how long a client might come back for another view or a small change. After two years it moves to the archive NAS, which frees fast server space without ever losing anything.

If this is useful to you, the empty folder structure is a free download. Drop it under a year folder and start filling it in. ↓ Download the project folder template (.zip)

A predictable scene, predictable names

The same habit carries inside the file. Layers sit in a fixed order from top to bottom, so every scene reads the same way. Cameras and lights first, then the shell of the building, then the furniture, then the dressing, then the helpers nobody should be touching.

The layer stack is identical in every scene, so rather than build it by hand we run a short script on a new file that creates all fifteen layers in the right order. It is a free download too, and it works in any copy of 3ds Max. ↓ Download the 3ds Max layer script (.zip)

Objects and materials are named so you know what they are without opening them. Objects lead with the type, like SOFA_MAIN or DINING_CHAIR_A. Materials lead with the category and finish, like WOOD_OAK or GLASS_CLEAR. It looks fussy written out. In a scene you have never seen, it means you can grab the right object or swap the right material without hunting, and because the material categories match the texture folders, a material and its maps are always in the same place.

The backbone: storage, network, and power

A naming system is worthless if the file it points to is slow to open, or gone. So the structure sits on hardware we thought about just as hard, and on a network and power setup built so the studio almost never stops.

Everything lives on one file server. Every workstation has a 10-gigabit network card and connects to a single 10-gigabit switch over Cat 7 cable, so opening a heavy scene off the server feels local. The server reaches that switch through a dual-port Intel network card bonded with link aggregation, so its link to the floor is both faster and able to ride out a single port or cable failing. One copy, one source of truth, with nothing drifting around on people's local drives. Every device on the network, the servers, the NAS units, the workstations and the DVR, sits on a fixed internal IP, so nothing moves around and any machine is found the same way every time. The server's operating system runs on a mirrored pair of M.2 drives, so a dead boot disk does not stop the studio. The project data sits on a separate RAID 10 array, striped for speed and mirrored for safety, split into two volumes, one for scenes and one for textures and models. Keeping them apart stops the scene files, which save constantly, from fighting the texture library, which gets read constantly.

Protection then runs in layers.

• An on-site backup server runs every hour, copying only the files artists have created or changed since the last run rather than the whole server. It finishes fast, and the most work anyone can lose is the last sixty minutes.
• A second NAS, kept off-site and powered down between syncs, holds a mirrored disaster-recovery copy. It is the one that matters after a fire, a theft, or ransomware.
• An in-house archive NAS holds projects older than two years on mirrored disks, so the live vault stays lean and nothing is ever thrown away.

Internet and power are built the same way, with a backup behind everything. Two lines come into a dual-WAN router: a 200 Mbps fibre connection as primary, and a 100 Mbps Airtel connection as backup that the router fails over to automatically the moment the fibre drops, so a dead line is something we notice in a log rather than in the middle of an upload. A 5G WiFi router hangs off the same 10-gigabit LAN for laptops and phones.

Power is split across two UPS units on purpose. A 10 kVA UPS backs the servers and NAS. A separate 5 kVA UPS backs everything that keeps us connected: the dual-WAN router, the network switch, the 5G WiFi, the internet equipment, and the office DVR and CCTV. The split is the clever part. When the power trips, the servers stay up on the 10 kVA and the network and internet stay up on the 5 kVA, which means we can reach the file server remotely, even from a phone, and shut it down cleanly if the outage is going to outlast the batteries. Nothing is ever lost to a power cut.

None of it is exotic. It is the smallest setup we could find that lets us tell a client their project is fast to work on, safe on a bad day, and still here in three years.

Spares on the shelf

Hardware fails on its own schedule, which is usually a deadline. So the parts that would otherwise stop us are already in the office, configured and waiting.

We keep a spare switch and a spare router, both already configured, so if one fails it is swapped in within minutes instead of ordered and waited on. For the workstations we hold the parts that tend to go, network cards, SSDs and M.2 drives, along with spare mice, keyboards and a monitor or two, enough to keep an artist working until a proper replacement arrives. There is also one fully configured spare workstation. When an artist needs it, it is ready; the rest of the time it earns its keep as a render farm machine.

The operating systems are handled the same way. Every server, the backup server, and every workstation runs its OS from an M.2 drive, and each of those drives is imaged in its fully configured state, with everything installed and set up for that machine and that artist. If an OS drive dies, we restore the image to a fresh M.2 and the machine comes back as it was. The artist makes a few small adjustments and is running again, rather than losing a day to a clean reinstall.

Why this matters if you hire us

If you commission renders from us, none of this shows up in the final image, which is exactly the point. It is why a revision does not stall because one artist is away. It is why we can reopen a project from eighteen months ago and match it without guesswork. It is why a request like "can you send the working file" takes five minutes instead of an afternoon, and why a power cut or a dead internet line is a footnote rather than a lost day.

A good brief removes problems before they start, which we wrote about in an earlier note. A good file structure does the same job, quietly, for years. Nobody has ever complimented our folder structure. They have only ever relied on it, usually without noticing. That is what it is for.

One last thing worth saying. None of this is off-the-shelf or branded enterprise kit with a service contract attached. We built it ourselves, part by part, and thought carefully about every piece, because that is what keeps us in control of it. There is no outside agency we have to phone and wait on when something needs attention. We maintain it, we understand it, and we can fix it the same day. That is why it has run for years now with only the odd minor hiccup and nothing that has ever stopped the studio. Boring, self-built, and completely ours is exactly what we want holding up the work.