Exporting Models - Blender

1. Which target-space coordinates should be written for the vertex?
   Answer: $\left(-1,3,2\right)$ When a custom export pipeline remaps coordinate axes, you need to treat each axis independently and apply every rule — including any sign flips — exactly as specified. Think of it as a substitution problem: for each output axis, find the corresponding Blender value and apply any negation. The pipeline defines three rules: target $+Y$ = Blender $+Z$, target $+Z$ = Blender $+Y$, and target $+X$ = Blender $-X$. For the vertex $(1, 2, 3)$ in Blender (where $X=1, Y=2, Z=3$), apply each rule in turn. Target $X$ = $-(\text{Blender } X)$ = $-(1) = -1$. Target $Y$ = Blender $Z$ = $3$. Target $Z$ = Blender $Y$ = $2$. This gives $(-1, 3, 2)$, confirming that A is correct. Choice B, $(1, 3, -2)$, gets the axis swap right for $Y$ and $Z$ but forgets to negate $X$, and incorrectly negates $Z$ instead — a classic sign-flip misapplication. Choice C, $(-1, 2, 3)$, correctly negates $X$ but ignores the $Y \leftrightarrow Z$ swap entirely, leaving the values in their original positions. Choice D, $(1, -3, 2)$, neither negates $X$ nor applies the sign flip correctly — it negates the wrong component entirely. A reliable strategy: write out the three rules as a small table before solving. Map each target axis to its source Blender axis, noting any minus sign. Applying rules out of order or mixing up "which axis gets negated" is the most common trap on coordinate remapping questions.
2. What is the most likely cause if the character arrives lying on its back?
   Answer: The root rotation duplicated the exporter's axis conversion, so the manual rotation should be removed. When exporting from Blender to a Y-up application, you have exactly one job: convert the axis orientation once. The trap this question tests is what happens when you do that job twice. Blender's FBX exporter has a built-in "Apply Transform" or axis-conversion setting that rotates the entire scene by $-90^\circ$ around X to convert from Blender's Z-up to Y-up. When the artist also manually rotates the root object by $-90^\circ$ around X "because the target is Y-up," those two rotations compound. The character ends up rotated $-180^\circ$ around X total — which is exactly what "lying on its back" looks like. Removing the manual root rotation fixes this, making A correct. B is wrong because applying scale has no effect on rotation baking in this scenario — the problem is a duplicate rotation, not a scale mismatch. Scale application matters when you see non-uniform stretching or distorted proportions, not an axis flip. C is a common misconception: unit scale conversion (meters to centimeters) changes the size of the mesh, not its orientation — FBX unit scaling cannot rotate an axis. D misdiagnoses the direction of the fix; the character is already over-rotated, so adding another rotation in the import preset would compound the error further rather than resolve it. The strategic takeaway: whenever a character arrives in an unexpected orientation, audit your pipeline for duplicate axis conversions. Exporter settings and manual root transforms both affect orientation — doing both is a classic double-correction mistake you should always check first.
3. How long should the exported child be if no transforms are applied beforehand?
   Answer: $1$ unit, because the child and parent scale factors cancel in world space. When working with hierarchical transforms in Blender's export pipeline, the key concept to internalize is that world-space scale is the product of all scales in the parent-child chain — not a sum, not a replacement. Here's the math: the child's local scale is $0.5$, the parent's scale is $2$, and the global export scale is $1$. World-space scale = $2 \times 0.5 \times 1 = 1.0$. The child's geometry is originally $1$ unit long, so the exported length is $1.0 \times 1 = 1$ unit. The parent and child scales happen to be reciprocals of each other, so they cancel out — making D correct. Choice A is wrong because it ignores the parent's contribution entirely. In a hierarchy, parent transforms propagate down to all children; you cannot evaluate a child in isolation. Choice B reflects a fundamental misunderstanding — scales multiply through a transform hierarchy, they never add. Adding $0.5 + 2 = 2.5$ has no basis in how transform matrices work. Choice C confuses inheritance with replacement; the parent scale does not overwrite the child's scale, it compounds with it multiplicatively. A useful strategy: whenever a question describes a transform hierarchy, immediately write out the full chain as a multiplication — local scale × parent scale × global scale. This prevents you from being tricked by distractors that suggest addition or replacement. Also watch for cases where values appear to "cancel" — that's not a trick, it's valid math, and D demonstrates exactly that pattern.
4. Which preparation produces the required result without changing the visible size?
   Answer: Apply the object's scale so the mesh becomes $0.02$ meters wide and the scale becomes $1$. Whenever you see a question about exporting from Blender with scale constraints, think about the difference between clearing and applying a transform — they produce opposite results, and confusing them is the most common mistake here. In Blender, an object's displayed size equals its mesh dimensions multiplied by its object scale. Here, the mesh is $2\,\text{m}$ wide and the scale is $0.01$, so the displayed size is $2 \times 0.01 = 0.02\,\text{m}$. The goal is to keep the visible size at $0.02\,\text{m}$ while resetting the scale to $1$. Applying the scale does exactly this: Blender bakes the current scale into the mesh geometry, rewriting the mesh's actual vertex positions to $0.02\,\text{m}$, then sets the object scale to $1$. The object looks identical in the viewport, but now carries an identity transform — precisely what the receiving tool requires. That makes B correct. A is the classic trap. Clearing the scale resets it to $1$ but discards the $0.01$ multiplier, so the displayed size snaps back to the original $2\,\text{m}$ — the visible size changes, violating the requirement. C sets the scale to $100$, which would display the mesh at $2 \times 100 = 200\,\text{m}$, a dramatic size change in the wrong direction, and the scale is still not $1$. D applies the rotation, not the scale. Rotation has no effect on scale values; the object scale remains $0.01$ and the problem is unsolved. A reliable tip: in Blender, apply (Ctrl+A) bakes the transform into the mesh; clear (Alt+G/R/S) discards it. Always ask yourself which operation preserves the visual result versus which one throws it away.
5. Which explanation and correction best fit the evidence?
   Answer: OBJ lacks a dependable shared unit convention, so its coordinates need a meter-to-centimeter scale conversion. When working through 3D pipeline questions, focus on what each format natively supports in terms of unit and metadata conventions — that's the real source of most cross-pipeline scale errors. The OBJ format is one of the oldest 3D interchange formats and was designed with minimal metadata. It has no standardized field for embedding physical unit information. When Blender (or any DCC tool) exports an OBJ, the numeric coordinate values are written out, but there's no reliable mechanism to tell the receiving application whether those numbers represent meters, centimeters, inches, or anything else. The studio's legacy pipeline assumes one unit equals one centimeter, so a one-meter asset — whose coordinates span 1.0 units — gets interpreted as 1 centimeter instead of 100 centimeters. The fix is to scale the export by 100 (meters × 100 = centimeters), making C the correct answer. Answer A is wrong because axis direction (forward/up) and unit scale are entirely separate properties. Flipping an axis changes orientation, not physical size. Answer B conflates texture/material data with geometric scale — embedding textures affects surface appearance, not the coordinate values that determine object size. Answer D invents a scenario where FBX metadata "bleeds" into the OBJ export; these are independent pipelines, and OBJ doesn't read FBX metadata at all, so there's nothing to divide out. As a study tip, remember that glTF and FBX both have defined unit conventions (glTF is always meters; FBX embeds a scale factor), while OBJ leaves units entirely to convention — making it a frequent source of scale mismatches in real pipelines.
6. Which preparation is the most reliable way to address the export problem?
   Answer: Apply the negative scale, recalculate normals outward, and verify face orientation before exporting. When exporting game assets from Blender, negative scale values are a common source of triangle winding order problems. Winding order determines which side of a face a normal points toward — engines using backface culling discard faces whose normals point away from the camera. A scale of $-1$ on any axis flips the winding order of every triangle on that object, so normals that appeared outward in Blender effectively point inward in the engine. The reliable fix is captured in B: applying the negative scale (Object → Apply → Scale) bakes the transformation into the mesh data, eliminating the $-1$ scale. Recalculating normals outward (Mesh → Normals → Recalculate Outside) then corrects any faces that ended up flipped, and checking face orientation (Overlay → Face Orientation) lets you visually confirm everything is blue before export. This three-step sequence directly attacks the root cause. A is wrong because adjusting the global scale and forward axis controls overall size and coordinate handedness — neither of these reverses per-triangle winding caused by a negative scale. C is wrong because omitting normal export doesn't fix winding; the engine reconstructs normals from winding order, so corrupted winding just produces corrupted reconstructed normals. D is wrong because applying only rotation leaves the $-1$ X scale unapplied — the scale is still negative, the winding problem remains, regardless of what the unit scale says. A reliable study tip: whenever a question involves negative scale and missing or inverted faces in an engine, immediately think "apply scale → recalculate normals → verify orientation." That sequence solves the vast majority of winding-related export issues.
7. Which workflow best preserves the model's intended orientation?
   Answer: Leave the model upright and allow the glTF exporter to perform the coordinate conversion. When working with Blender and glTF export, the key concept to understand is the coordinate system mismatch: Blender uses a Z-up convention, while glTF uses Y-up. Blender's built-in glTF exporter is specifically designed to handle this conversion automatically, and understanding that pipeline saves you from introducing unnecessary manual transforms. Because the model is already upright with zero rotation values applied, the correct move is simply to let the exporter do its job — making B the right answer. Blender's glTF exporter applies an internal coordinate conversion behind the scenes, rotating the scene's basis so that your Z-up world maps correctly to glTF's Y-up world. The model arrives in the viewer oriented exactly as intended, with no extra work required from you. A is a trap that doubles up on corrections. Manually rotating $-90^\circ$ around X and disabling the exporter's Y-up conversion means you're trying to compensate manually for a problem the exporter would have solved automatically — and disabling the conversion then leaves that manual rotation unaccounted for in the target coordinate space, resulting in a misoriented model. C introduces an arbitrary $90^\circ$ Z rotation that has no relationship to the Z-up/Y-up conversion problem. Applying only scale while leaving a rotation unapplied creates additional transform complications downstream. D describes swapping X and Y dimensions, which conflates axis remapping with a geometric dimension swap — these are fundamentally different operations and would distort or misalign the model entirely. Your takeaway: trust Blender's glTF exporter to handle coordinate conversion automatically. Only intervene manually if you have a specific reason to override the default behavior.
8. Which export setting will make the prop arrive at the intended real-world length?
   Answer: Use an OBJ export scale of $100$ so the file stores a length of $240$ units. Whenever you see a unit-conversion export question, your job is to figure out what numerical value needs to land in the file so the receiving application interprets it correctly in real-world terms. Here's the core logic: Blender stores the prop as $2.4$ units, where each unit means $1\text{ m}$. The target application reads each unit as $1\text{ cm}$. Since $1\text{ m} = 100\text{ cm}$, you need the file to store $240$ units so the receiver interprets it as $240\text{ cm} = 2.4\text{ m}$. That means multiplying by $100$, which is exactly what an export scale of $100$ does: $2.4 \times 100 = 240$. Answer C is correct. A is wrong in the opposite direction — scaling by $0.01$ shrinks the value to $0.024$ units, which the receiver reads as $0.024\text{ cm}$, making the prop absurdly tiny rather than the intended size. This is the classic "divide when you should multiply" trap. B exports the raw Blender value of $2.4$ unchanged. The receiving app then reads that as $2.4\text{ cm}$, which is roughly the width of a finger — nowhere near $2.4\text{ m}$. A scale of $1$ only works when both applications share the same unit definition. D uses the inches-to-centimeters factor ($2.54$), which applies to an inch/centimeter conversion, not a meter/centimeter one. It's a plausible-looking number that tests whether you know which conversion factor actually applies here. Study tip: Always write out the unit equation before touching the scale field — identify what one source unit equals in destination units, then use that ratio as your multiplier.
9. Which preset change most directly fixes the model while preserving its verified up direction and scale?
   Answer: Keep target Up at $+Y$ and reverse the selected target Forward axis from $-Z$ to $+Z$. When exporting from Blender, the FBX preset defines two independent axes: Up and Forward. These tell the target application how to interpret Blender's coordinate space. The key insight is that each axis setting does exactly one job — changing one should not disturb the other. Here, the $+Y$ up mapping is already confirmed correct, so the only problem is that the model's front face lands on target $-Z$ instead of $+Z$. That's a pure forward-axis mismatch — the fix belongs entirely in the Forward axis field. Switching the Forward axis from $-Z$ to $+Z$ directly tells Blender to flip which direction it exports as "front," rotating the model 180° around the up axis in the output. Everything else — scale, up direction, proportions — remains untouched. That's choice A, and it's the most surgical, minimal fix available. Choice B changes Up from $+Y$ to $-Y$, which would flip the model upside down. Since the up direction is already verified correct, this introduces a new error rather than correcting the existing one. Choice C uses a negative export scale of $-1$, which doesn't rotate the model — it mirrors it, producing a geometry that is scaled incorrectly and potentially inverted in ways the target application won't interpret as a simple facing change. Choice D swaps the Up and Forward roles entirely and then tries to compensate with a unit scale adjustment; this conflates two separate problems and breaks the verified up mapping for no reason. A useful rule of thumb: isolate the broken axis, fix only that axis. When one export axis is confirmed correct, treat it as locked and adjust only the failing one.
10. What length will the model have after import, and what does that reveal about the pipeline?
    Answer: It will be $2.5$ units long because the two conversion factors cancel exactly. When working through pipeline scaling questions in Blender, think of each conversion factor as a multiplier in a chain — the final result is simply their product applied to the original value. Here, your model starts at $2.5$ units. The export preset multiplies all coordinates by $100$, producing $2.5 \times 100 = 250$ units in the stored file. The receiving application's import preset then multiplies those stored coordinates by $0.01$, giving $250 \times 0.01 = 2.5$ units. The two factors combine as $100 \times 0.01 = 1$, meaning they cancel exactly and the model arrives at its original size. This reveals something important about pipelines: opposing scale presets can be designed intentionally to round-trip data losslessly across unit systems. Choice A is wrong because it stops the calculation halfway — it correctly computes the exported value but ignores that the import preset also acts on those coordinates. Choice B describes the import preset overriding the export preset, which would mean only $0.01$ applies to the original $2.5$, yielding $0.025$ — but that's not how chained multipliers work; both apply sequentially. Choice C imagines a partial cancellation, suggesting the math produces $25$, which would require a net factor of $10$ — neither $100 \times 0.01$ nor any logical combination produces that. Choice D correctly chains both multipliers and recognizes the net effect is neutral, making it the right answer. As a study tip, whenever you see stacked scale conversions in a pipeline question, multiply all the factors together first before drawing any conclusions — partial calculations are the most common trap on these questions.

Start this quiz