Materials render pink, grey or flat white. The render finished without a single error. Here is what happened, and why the fix takes ten seconds once you know it.
In Blender: File → External Data → Pack Resources, then
save. That copies the images into the .blend instead of
pointing at them.
If that fixed it, you can stop reading. The rest explains why it happened, so it doesn't happen again on the job that matters.
When you load a texture, Blender does not put the image inside your
file. It writes down where the image lives — something like
/Users/you/textures/wood.png — and reads it from there
every time the scene opens.
That is a sensible default. One texture shared by thirty files stays one texture, and your .blend stays small. It only becomes a problem the moment the file travels without the folder it was reading from: to a render farm, to a colleague, to your own laptop, into a zip you email yourself.
On the other machine that path does not exist. Blender cannot find the image, so it draws the material with nothing in it — which is why you get magenta, the colour Blender uses to say "this texture is missing". Grey or white usually means the same thing one step further along: the node is there, the image slot is empty.
The reason this costs people money is that nothing errors. Blender renders the scene it can see. You find out when you look at the frames — often after the hours are already spent.
Before fixing anything, find out what is actually gone. Guessing leads to repacking a scene that was never broken.
// is relative to the .blend, and those usually survive
a move — as long as the neighbouring folders came too.| What to use | When | What it costs you |
|---|---|---|
| Pack Resources | The file is about to travel — to a farm, a client, another machine. This is the right answer almost every time. | The .blend grows by roughly the size of your textures. A 40 MB file can become 900 MB. That is the trade. |
| Find Missing Files | The images are still on this machine, just moved. Point Blender at the folder and it re-links what it can match by name. | Only works where the images actually are. It repairs the paths; it does not make the file portable. |
| Relative paths + send the folder |
A project with gigabytes of shared textures, where packing would produce an absurd file. | Discipline. Every texture must sit inside the project folder, and the whole folder has to travel, zipped, every time. |
One thing to know about packing: it is reversible.
File → External Data → Unpack Resources writes the images
back out to disk. Packing is not a one-way door, so there is little
reason to avoid it when a file is about to leave your computer.
Two other things travel badly, and they fail just as silently.
Cloth, smoke and fluid live in a folder next to the project, not inside the .blend. Without them another machine recalculates the simulation — and gets a different one. Bake before sending.
If a material or modifier comes from an add-on, the other machine needs that add-on too. Geometry that depends on it will simply not be there.
We open your .blend with real Blender on our own machine — a machine that has never seen your texture folder — and list what it cannot find. That is the only honest test of whether a file will render somewhere else, because it is exactly what happens when it gets there.
Free, no account, nothing to install. Works whatever engine you use: a missing texture is a missing texture in EEVEE and Cycles alike.
Check a .blend →