- Which Save As behavior is most important for this result?
Answer: Enable relative-path remapping so paths are recalculated from the new save location to still target the same files.
When working with file paths in Blender, the core question is always: what does the path actually point to on disk? Relative paths are stored as strings like //textures/wood.png, where // means "relative to this file's location." When you move the .blend file, those strings don't automatically update — so Blender may start resolving them from a completely different folder, potentially breaking all your texture links.
This is exactly what relative-path remapping solves. When you use Save As with remapping enabled (option B), Blender recalculates every relative path string so that, from the new file's location, each path still resolves to the same absolute location on disk. Moving from /ClientA/scenes/ to /ClientB/delivery/ means the relative strings need to change — perhaps from //textures/wood.png to ../../ClientA/textures/wood.png — but the actual file being referenced stays identical. That's the behavior you need here.
A is the dangerous trap. Preserving the path strings exactly as written means Blender interprets //textures/wood.png relative to the new folder, pointing to /ClientB/delivery/textures/wood.png — a path that likely doesn't exist. Disabling remapping breaks your links rather than preserving them.
C describes packing, which embeds texture data inside the .blend. This changes the storage method entirely and isn't about maintaining external file references.
D would work in practice, but the question asks about Save As behavior, and converting to absolute paths is a separate workflow step — not what Save As remapping does.
Remember: "preserve the string" and "preserve the target" are two different things. Remapping preserves the target.
- What should the artist expect, and what is the appropriate correction?
Answer: The renamed image may remain missing; its image data-block should be browsed to the new file.
When dealing with missing files in Blender, it helps to understand exactly what Find Missing Files does — and what it doesn't. The tool searches a selected folder for files whose filenames match the names recorded in Blender's image data-blocks. It's a filename-based lookup, not a content-based scan or an AI inference system.
This is why C is correct. Because the recovered file was renamed from wall_diffuse.png to brick_wall_basecolor.png, Find Missing Files will simply skip it — the names don't match. The image data-block still shows the original name as missing. The artist must manually browse to the new file using the image data-block's file path field (the folder icon in the Image Editor or the node's texture properties), effectively relinking it by hand.
A is wrong because Blender performs no content or hash comparison during file recovery. It cannot "recognize" an image by its pixel data — only by name. B is wrong because Blender's node graph does not store enough semantic information to infer which external file belongs to a node; making paths relative is a separate utility that shortens already-valid paths, not one that resolves missing links. D is wrong because packing embeds file data inside the .blend file itself — it doesn't happen automatically during a file search, and unpacking only works if data was previously packed to begin with.
The key study tip here: Find Missing Files is strictly a name-matching tool. Any rename, even a minor one, breaks the automatic recovery. Manually relinking via the data-block browser is always your fallback when names have changed.
- Which workflow most reliably prepares the delivery?
Answer: Pack the available resources into the .blend, save it, unpack those resources to the project delivery folder, then save again with relative paths so the folder is self-contained and portable.
When preparing a portable Blender delivery, the core challenge is ensuring texture paths resolve correctly on any machine — not just yours. The key workflow concept here is the difference between packing, unpacking, and path notation, and how they work together.
The reliable solution is option C. Packing resources into the .blend first gathers all external textures into the file regardless of where they currently live across your two drives. Unpacking to the delivery folder then extracts those textures into that specific folder, physically placing them alongside the .blend. Finally, saving with relative paths means the .blend references textures like //textures/wood.png rather than C:/Users/... — so when the entire folder moves, the paths still resolve. The recipient gets a self-contained folder, textures remain external (not embedded), and portability is guaranteed.
Option A fails because making paths relative while leaving textures in their original drive locations means the delivery folder isn't self-contained. Relative paths pointing to locations that don't travel with the project break the moment the folder moves to another machine.
Option B is doubly flawed: absolute paths are machine-specific by definition, and Blender has no mechanism to recreate missing source directories on a recipient's machine. The textures simply won't load.
Option D describes a diagnostic step, not a delivery preparation. Reporting missing files and reloading data-blocks confirms path validity on your system but does nothing to consolidate or package files for someone else.
A useful pattern to remember: pack → unpack to destination → save relative is the standard Blender workflow whenever you need a portable, externally-linked project folder.
- Why can the colleague still receive a file with missing textures?
Answer: The packing change must be saved into the .blend file before that copy contains it.
Whenever you see a question about Blender's Pack Resources feature, think about the relationship between performing an operation and saving that operation's result. Packing embeds external image data directly into the .blend file — but like any change in Blender, it only exists in memory until you save.
In this scenario, the artist runs Pack Resources while the textures are accessible, which successfully embeds the image bytes into the current Blender session. However, the artist then sends the previously saved .blend file — the one that existed on disk before packing occurred. That older file was written before the packing happened, so it still contains only external file paths, not embedded image data. When the colleague opens it and those texture paths don't exist on their machine, the textures appear missing. C is correct: the packing change had to be written to disk via File > Save before that copy of the file would contain it.
A is wrong because Pack Resources works on any image loaded into Blender, including disk-based textures — it's not limited to procedurally generated images. B is wrong because packing does not require absolute paths as a prerequisite; Blender reads the image data directly from the loaded image datablock regardless of path type. D is wrong because packed images are stored inside the .blend file's internal data structure, not in a temporary system directory — there's no unpacking step needed on the sender's side.
The key study habit here: always distinguish between an in-memory operation and a saved state. In Blender, "did it" and "saved it" are never the same thing.
- Why should the texture remain resolvable on the second computer?
Answer: The leading // resolves the path relative to the saved .blend file's directory.
Whenever you see a question about file paths in Blender, the key concept to focus on is how Blender resolves relative paths — specifically what the // prefix actually means.
In Blender, // at the start of a path is shorthand for "the directory containing the current .blend file." So //../textures/wall.png means: start at the .blend file's location (/Project/scenes/), go up one level (.. → /Project/), then navigate into textures/wall.png. This gives you /Project/textures/wall.png. Because this path is expressed *relative to the .blend file*, it doesn't matter what computer you're on or where /Project lives on that machine — as long as the internal folder structure is preserved, Blender can always resolve the texture correctly. That's exactly why A is correct.
Choice B is wrong because // has nothing to do with recursive searching from the OS root — that would be a slow, unreliable process Blender doesn't perform. Choice C misidentifies what .. does: it's a standard directory traversal symbol meaning "go up one folder," not an embedding mechanism that copies data into the .blend file. Packing textures into the .blend is a separate feature entirely. Choice D is wrong because .. cannot "convert" anything into an absolute path on another machine — absolute paths are system-specific and would break portability, not fix it.
A useful rule of thumb: relative paths travel with the project, absolute paths stay on the machine. Any time you see // in a Blender path question, think "relative to the .blend file's location."
- What is the most direct corrective action in Blender?
Answer: Use Reload for the image so Blender rereads the existing file from its current path.
Whenever you see a question about external image files in Blender, focus on what actually changed and what Blender needs to do about it. Here, the file path is intact and the filename is unchanged — Blender simply hasn't re-read the file since it was modified externally. That distinction is everything.
Because the path is valid, Blender isn't reporting a missing file — it just holds a stale cached copy of the pixel data in memory. The fix is to force Blender to re-read that same file from disk, which is exactly what Reload does. You can access it in the Image Editor under Image → Reload, or through the outliner. Blender discards the cached pixels and replaces them with whatever is currently saved at the linked path. That makes B the correct and most direct action.
A is wrong because Find Missing Files is designed to locate files whose paths have broken — it searches your drive for a filename match. It does not address stale cache data when the path is already valid. C is wrong because Make Paths Absolute converts relative paths (like //textures/label.png) to full system paths — it has nothing to do with detecting file modification times or refreshing pixel data. D is wrong because Unpack Resources moves externally linked files into the .blend file itself; it doesn't synchronize external edits and would actually make future external editing harder to manage.
As a study tip, remember the three distinct problems — missing path, stale cache, and packed vs. linked — and match each to its tool: Find Missing Files, Reload, and Pack/Unpack respectively.
- Which unpacking strategy best meets the requirement?
Answer: Use the option that writes packed files only when no matching file exists, leaving any existing file untouched.
When working with packed resources in Blender, the key question is always: what happens when a file already exists at the destination? Blender's unpack dialog offers distinct strategies, and choosing the wrong one can silently overwrite work that's already been done.
The scenario here is specific — a local texture file already exists and contains newer, approved edits. That means you need an unpacking mode that skips files when a match is found, never touching what's already there. Option A describes exactly this behavior: it writes the packed data only when no existing file is present, leaving any pre-existing file completely untouched. This is the "Use Original Locations (skip existing)" style of unpacking, and it's the safe, non-destructive choice.
Option B is dangerous here — writing all packed files and overwriting matches would destroy the newer approved edits, replacing them with the older packed version. That's the opposite of what's needed. Option C writes files back to their originally recorded absolute paths (wherever the file was when it was packed), which may be on a different machine or path entirely, and it also overwrites anything found there — again risking data loss and almost certainly pointing to the wrong location. Option D doesn't extract anything at all; it only converts path strings between relative and absolute format while keeping data packed, so no files are written to disk whatsoever.
As a study tip, remember that Blender's unpack options follow a logic of write scope (all vs. missing-only) combined with destination (original path vs. current project folder). Knowing those two axes lets you reason through any unpacking scenario on the exam.
- Which action best satisfies the artist's goal?
Answer: Run Report Missing Files and review the missing-path messages.
When working with external files in Blender, it helps to distinguish between tools that diagnose problems versus tools that fix or modify them. The artist's goal here is purely diagnostic — find out what's missing without touching anything.
Report Missing Files (A) is exactly the right tool for this. It scans all external file links in the project and outputs a report listing every path Blender cannot resolve, leaving every link completely untouched. The magenta materials are your clue that textures are already broken, and this tool tells you precisely which files are the culprit — nothing more, nothing less.
Find Missing Files (B) sounds appealing, but it's a repair tool, not a diagnostic one. It actively searches a directory you specify and relinks any files it finds. Running it changes existing links, which directly contradicts the artist's requirement to leave links unchanged.
Make Paths Relative (C) is a path-format conversion tool — it rewrites absolute paths as relative ones. It says nothing about whether those files actually exist, and it modifies every path it processes, again violating the "leave links unchanged" condition.
Pack Resources (D) embeds external files directly into the .blend file. While packed resources can resolve missing-file errors, it permanently alters how assets are stored. Any image Blender can't find still won't pack correctly, so this is both destructive and unreliable as a diagnostic method.
The key study tip here: when a Blender question involves not changing anything, eliminate every answer that performs a write or relink operation — only pure reporting tools survive that filter.
- What is the most efficient way to restore the links?
Answer: Choose Find Missing Files and select the Recovered folder as the search location.
When you encounter a question about broken image links in Blender, think about what tool is designed to search for files versus what tools merely reformat or reload existing paths. That distinction is everything here.
Blender's Find Missing Files operator does exactly what the scenario needs: you point it at a folder, and it recursively searches that folder and all subfolders for any file whose name matches a missing image data-block. Since the recovered files kept their original filenames and no two share the same name, Blender can unambiguously match every missing image in one operation. Option B is the right move — one tool, one folder selection, job done.
Option A is technically possible but absurdly impractical. Manually entering an absolute path for every missing image data-block defeats the purpose of having an automated tool and would take enormous time across a large archive. Option C, Make Paths Absolute, converts relative paths to absolute ones based on paths Blender already knows — it does nothing to locate files that are already reported as missing. It's a path-formatting tool, not a search tool. Option D is a fabricated workflow; Blender does not have a "texture cache" you can append folders to, and Reload Images simply re-reads files from their currently linked paths, which won't help if those paths are broken.
A useful study habit: when a question describes missing files that need to be found, look for the tool with "find" or "search" in its name or description. Tools like Make Paths Absolute or Reload Images assume Blender already knows where the files are — they're maintenance tools, not recovery tools.
- Which outcome is expected if the packed image data is intact?
Answer: The materials can still use the embedded images even though the external path strings are unresolved.
When working with Blender's texture system, it helps to understand the distinction between where image data lives and how it's referenced. Blender stores two things separately in a .blend file: a path string (just a text address) and, when packed, the actual pixel data embedded inside the file itself. These are independent — having a broken path doesn't erase embedded data.
When you pack textures using File > External Data > Pack All Into .blend, Blender copies the raw image bytes directly into the .blend file. From that point forward, the file is self-sufficient. The path string remains in the image data-block as metadata, but Blender's loading logic checks for packed data first. If packed data is present and intact, it is used regardless of whether the external path resolves. This is exactly why D is correct — your materials render normally even though the original directory is gone.
A is wrong because Blender doesn't discard packed images just because the external path is invalid. Path resolution failure only matters when there is no packed fallback. B is wrong because it inverts the priority: packed data takes precedence over external paths, not the other way around. Magenta (missing texture) would only appear if packed data were absent and the path was broken. C is wrong because Blender never automatically recreates directories on the filesystem — it has no such capability and doesn't attempt it.
A useful rule of thumb: treat packing as "cut the cord." Once an image is packed, the path string is just a label — the data travels with the file everywhere.
