Blender Quiz: Export Models To Obj Fbx Gltf With Correct Scale And Axis Orientation Intro
10 questions · exam conditions
0:00
Export Models To Obj Fbx Gltf With Correct Scale And Axis Orientation IntroQuestion 1 of 10

A character is authored upright in Blender. An FBX exporter is configured to convert Blender's orientation to the target application's Y-up convention. Before exporting, an artist also rotates the character's root object by −90∘-90^\circ around the X axis because the target is Y-up. In the target application, the import preset performs no additional axis conversion.

What is the most likely cause if the character arrives lying on its back?

The root rotation duplicated the exporter's axis conversion, so the manual rotation should be removed.
The root rotation was necessary, but its scale should have been applied before FBX export.
The FBX unit scale converted meters to centimeters, which also rotated the character's up axis.
The import preset omitted a second Y-up conversion, so another rotation should be added there.
← Back to quizzes

Blender Quiz

Blender Quiz: Export Models To Obj Fbx Gltf With Correct Scale And Axis Orientation Intro

Practice Export Models To Obj Fbx Gltf With Correct Scale And Axis Orientation Intro in Blender with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Export Models To Obj Fbx Gltf With Correct Scale And Axis Orientation Intro, giving you a quick way to practice the rules, question types, and explanations that matter most for Blender.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A character is authored upright in Blender. An FBX exporter is configured to convert Blender's orientation to the target application's Y-up convention. Before exporting, an artist also rotates the character's root object by −90∘-90^\circ around the X axis because the target is Y-up. In the target application, the import preset performs no additional axis conversion.

What is the most likely cause if the character arrives lying on its back?

  1. The root rotation duplicated the exporter's axis conversion, so the manual rotation should be removed. (correct answer)
  2. The root rotation was necessary, but its scale should have been applied before FBX export.
  3. The FBX unit scale converted meters to centimeters, which also rotated the character's up axis.
  4. The import preset omitted a second Y-up conversion, so another rotation should be added there.
Explanation: 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∘-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∘-90^\circ around X "because the target is Y-up," those two rotations compound. The character ends up rotated −180∘-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.

Question 2

A custom export pipeline defines this coordinate conversion: Blender +Z+Z maps to target +Y+Y, Blender +Y+Y maps to target +Z+Z, and Blender +X+X maps to target −X-X. A vertex has Blender coordinates (1,2,3)\left(1,2,3\right).

Which target-space coordinates should be written for the vertex?

  1. (−1,3,2)\left(-1,3,2\right) (correct answer)
  2. (1,3,−2)\left(1,3,-2\right)
  3. (−1,2,3)\left(-1,2,3\right)
  4. (1,−3,2)\left(1,-3,2\right)
Explanation: 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+Y = Blender +Z+Z, target +Z+Z = Blender +Y+Y, and target +X+X = Blender −X-X. For the vertex (1,2,3)(1, 2, 3) in Blender (where X=1,Y=2,Z=3X=1, Y=2, Z=3), apply each rule in turn. Target XX = −(Blender X)-(\text{Blender } X) = −(1)=−1-(1) = -1. Target YY = Blender ZZ = 33. Target ZZ = Blender YY = 22. This gives (−1,3,2)(-1, 3, 2), confirming that A is correct. Choice B, (1,3,−2)(1, 3, -2), gets the axis swap right for YY and ZZ but forgets to negate XX, and incorrectly negates ZZ instead — a classic sign-flip misapplication. Choice C, (−1,2,3)(-1, 2, 3), correctly negates XX but ignores the Y↔ZY \leftrightarrow Z swap entirely, leaving the values in their original positions. Choice D, (1,−3,2)(1, -3, 2), neither negates XX 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.

Question 3

A child mesh is 11 unit long in its local geometry. The child has a uniform scale of 0.50.5, and its parent has a uniform scale of 22. An exporter evaluates the complete hierarchy and writes the child's world-space result. Its global export scale is 11.

How long should the exported child be if no transforms are applied beforehand?

  1. 0.50.5 unit, because only the child's local scale affects its exported geometry.
  2. 2.52.5 units, because parent and child scale values are added by the hierarchy.
  3. 22 units, because the parent scale replaces the child's local scale during export.
  4. 11 unit, because the child and parent scale factors cancel in world space. (correct answer)
Explanation: 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.50.5, the parent's scale is 22, and the global export scale is 11. World-space scale = 2×0.5×1=1.02 \times 0.5 \times 1 = 1.0. The child's geometry is originally 11 unit long, so the exported length is 1.0×1=11.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.50.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.

Question 4

A studio exports the same meter-sized asset through three pipelines. Its glTF pipeline expects meters, its FBX pipeline reads embedded unit metadata, and its legacy OBJ pipeline assumes one coordinate unit equals one centimeter. The asset has correct dimensions in glTF and FBX but is much too small through OBJ.

Which explanation and correction best fit the evidence?

  1. OBJ changed the up axis into a unit scale, so reversing the forward axis will restore the dimensions.
  2. OBJ omitted the material scale metadata, so embedding textures will restore the physical dimensions.
  3. OBJ lacks a dependable shared unit convention, so its coordinates need a meter-to-centimeter scale conversion. (correct answer)
  4. OBJ applied the FBX unit metadata twice, so the OBJ export scale should be divided by the FBX scale.
Explanation: 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.

Question 5

An FBX model arrives upright and at the correct size in a target application, but its front points along target −Z-Z instead of the required target +Z+Z. The current preset already maps Blender's up direction to target +Y+Y correctly, and there are no corrective rotations in the target scene.

Which preset change most directly fixes the model while preserving its verified up direction and scale?

  1. Keep target Up at +Y+Y and reverse the selected target Forward axis from −Z-Z to +Z+Z. (correct answer)
  2. Change target Up from +Y+Y to −Y-Y and leave the target Forward axis at −Z-Z.
  3. Keep both axis selections and change the global export scale from 11 to −1-1.
  4. Exchange the target Up and Forward selections, then compensate with a larger unit scale.
Explanation: 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+Y up mapping is already confirmed correct, so the only problem is that the model's front face lands on target −Z-Z instead of +Z+Z. That's a pure forward-axis mismatch — the fix belongs entirely in the Forward axis field. Switching the Forward axis from −Z-Z to +Z+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+Y to −Y-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-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.

Question 6

A model is 2.52.5 units long in Blender. An export preset multiplies all coordinates by 100100, and the receiving application's import preset multiplies the imported coordinates by 0.010.01. No other object, parent, or unit scaling is present.

What length will the model have after import, and what does that reveal about the pipeline?

  1. It will be 250250 units long because only the exporter changes the stored coordinates.
  2. It will be 0.0250.025 units long because the import scale overrides the export scale.
  3. It will be 2525 units long because the two scale settings partially cancel.
  4. It will be 2.52.5 units long because the two conversion factors cancel exactly. (correct answer)
Explanation: 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.52.5 units. The export preset multiplies all coordinates by 100100, producing 2.5×100=2502.5 \times 100 = 250 units in the stored file. The receiving application's import preset then multiplies those stored coordinates by 0.010.01, giving 250×0.01=2.5250 \times 0.01 = 2.5 units. The two factors combine as 100×0.01=1100 \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.010.01 applies to the original 2.52.5, yielding 0.0250.025 — but that's not how chained multipliers work; both apply sequentially. Choice C imagines a partial cancellation, suggesting the math produces 2525, which would require a net factor of 1010 — neither 100×0.01100 \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.

Question 7

A game asset was mirrored by setting its object X scale to −1-1. It appears correct in Blender, but after FBX export some triangles disappear when backface culling is enabled in the engine. The engine otherwise receives the correct size and up axis.

Which preparation is the most reliable way to address the export problem?

  1. Increase the FBX global scale and reverse the chosen forward axis to restore the missing faces.
  2. Apply the negative scale, recalculate normals outward, and verify face orientation before exporting. (correct answer)
  3. Disable normal export and rely on unit conversion to reconstruct the original triangle winding.
  4. Apply only the rotation and change the scene unit scale so the X scale becomes positive.
Explanation: 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-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-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-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.

Question 8

An upright mechanical model has unapplied rotation values of zero in Blender. It will be exported as glTF to a viewer that follows glTF's standard Y-up coordinate system. Blender's glTF exporter is left at its normal Y-up export behavior.

Which workflow best preserves the model's intended orientation?

  1. Rotate the model by −90∘-90^\circ around X and disable the exporter's Y-up conversion.
  2. Leave the model upright and allow the glTF exporter to perform the coordinate conversion. (correct answer)
  3. Rotate the model by 90∘90^\circ around Z and apply only its scale before export.
  4. Swap the model's X and Y dimensions and export with the original Z-up basis.
Explanation: 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∘-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∘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.

Question 9

A mesh has an untransformed X dimension of 22 meters. Its object scale is 0.010.01 on all axes, so its displayed X dimension in Blender is 0.020.02 meters. The model must be exported at its currently displayed size, but the receiving tool requires identity object scale.

Which preparation produces the required result without changing the visible size?

  1. Clear the object's scale so the displayed dimension becomes 22 meters and the scale becomes 11.
  2. Apply the object's scale so the mesh becomes 0.020.02 meters wide and the scale becomes 11. (correct answer)
  3. Set the object's scale to 100100 so the mesh remains 22 meters wide after unit conversion.
  4. Apply the object's rotation so the mesh becomes 0.020.02 meters wide and the scale becomes 11.
Explanation: 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 m2\,\text{m} wide and the scale is 0.010.01, so the displayed size is 2×0.01=0.02 m2 \times 0.01 = 0.02\,\text{m}. The goal is to keep the visible size at 0.02 m0.02\,\text{m} while resetting the scale to 11. 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 m0.02\,\text{m}, then sets the object scale to 11. 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 11 but discards the 0.010.01 multiplier, so the displayed size snaps back to the original 2 m2\,\text{m} — the visible size changes, violating the requirement. C sets the scale to 100100, which would display the mesh at 2×100=200 m2 \times 100 = 200\,\text{m}, a dramatic size change in the wrong direction, and the scale is still not 11. D applies the rotation, not the scale. Rotation has no effect on scale values; the object scale remains 0.010.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.

Question 10

A Blender scene uses the default convention that one Blender unit represents one meter. A prop is exactly 2.42.4 Blender units long. It will be exported as OBJ and opened in an application that treats each OBJ coordinate unit as one centimeter. The receiving application offers no automatic unit conversion.

Which export setting will make the prop arrive at the intended real-world length?

  1. Use an OBJ export scale of 0.010.01 so the file stores a length of 0.0240.024 units.
  2. Use an OBJ export scale of 11 so the file stores a length of 2.42.4 units.
  3. Use an OBJ export scale of 100100 so the file stores a length of 240240 units. (correct answer)
  4. Use an OBJ export scale of 2.542.54 so the file stores a length of 6.0966.096 units.
Explanation: 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.42.4 units, where each unit means 1 m1\text{ m}. The target application reads each unit as 1 cm1\text{ cm}. Since 1 m=100 cm1\text{ m} = 100\text{ cm}, you need the file to store 240240 units so the receiver interprets it as 240 cm=2.4 m240\text{ cm} = 2.4\text{ m}. That means multiplying by 100100, which is exactly what an export scale of 100100 does: 2.4×100=2402.4 \times 100 = 240. Answer C is correct. A is wrong in the opposite direction — scaling by 0.010.01 shrinks the value to 0.0240.024 units, which the receiver reads as 0.024 cm0.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.42.4 unchanged. The receiving app then reads that as 2.4 cm2.4\text{ cm}, which is roughly the width of a finger — nowhere near 2.4 m2.4\text{ m}. A scale of 11 only works when both applications share the same unit definition. D uses the inches-to-centimeters factor (2.542.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.