FIT1033 Chap.3 Scene Cleanup and Unity Handoff
Scene Cleanup and Unity Handoff
The Maya to Unity boundary tests whether the asset is organised, not merely whether an FBX file can be created. Clear names, a deliberate hierarchy, appropriate grouping or parenting, deleted history and intentional transforms make import predictable.
This chapter treats export as a contract and validates scale, orientation, material slots, camera framing and the working build inside Unity rather than trusting the source scene alone.
What this chapter covers
- 01
Role-based object naming
- 02
Grouping, combining and parenting
- 03
History deletion and transform baselines
- 04
FBX export from Maya
- 05
Unity scale and orientation checks
- 06
Material slots, camera view and build validation
Worked example · free
Prepare a delivery rover for Unity
- 1Rename parts and sort them under one understandable rover group.
- 1Remove accidental relationships and preserve only intentional parents.
- 1Delete history, check pivots and freeze the intended transform baseline.
- 1Import into Unity and inspect scale, materials, camera and build behaviour.
Key terms
- Hierarchy
- The parent, child and group relationships used to organise and transform scene objects.
- Parenting
- A relationship in which a child object inherits transformations from a parent.
- History
- The recorded construction operations that can be removed after modelling is settled.
- Transform Baseline
- The intentional position, rotation and scale state recorded as the clean starting point.
Scene Cleanup and Unity Handoff FAQ
What is the difference between grouping and combining?
Grouping lets objects move together while remaining separate meshes with their own pivots and material roles. Combining turns selected meshes into one mesh object. Use the structure the destination needs, and avoid combining merely to make the Outliner shorter because that can remove useful control.
Why should I delete history before export?
Construction history can retain old operations and dependencies that are no longer useful. Once modelling is complete, removing it simplifies the asset and reduces surprises in later edits or export. Save a version before destructive cleanup so the earlier construction state remains recoverable if a change is required.
What should I check after importing into Unity?
Inspect scale, orientation, pivot behaviour, hierarchy, material slots and the actual game or camera view. Move around the asset and confirm that important surfaces remain readable. A successful file import is only the start; the destination must reproduce the intended form and presentation without hidden dependencies.
Assessment move
Use one deliberately messy scene as a cleanup exercise. Rename every object, justify each group and parent, remove unwanted history, check pivots and establish transforms. Export it into a fresh Unity scene rather than the supplied project. The fresh destination makes hidden dependencies and poor naming much easier to detect. Start by making an inventory before changing anything.
Record the visible asset parts, the objects that should move together, the materials they need and the transform that should define the asset origin. Compare that inventory with the Outliner. Names such as pCube12 or group3 are not merely untidy; they make it difficult to diagnose which object, slot or hierarchy branch failed after import.
Rename from broad assembly to specific component, and use a pattern that remains readable when Unity adds instances or suffixes. Practise grouping and parenting on duplicate scenes. A group can provide an organisational or transform container, while parenting creates a direct inherited relationship.
Rotate the proposed parent and watch what follows; if an unrelated component moves, the hierarchy communicates the wrong structure. Place pivots where the asset is meant to rotate or sit, and inspect scale and orientation without blindly freezing values that still carry useful intent. Delete construction history only after saving an editable checkpoint, since cleanup should not erase the ability to recover.
Treat FBX export as a testable contract. Write down the expected object count, material-slot count, forward direction, up direction, origin and approximate Unity scale. Import into a blank destination, not only the familiar project, and compare each expectation with the result.
If the model arrives tiny, sideways or with merged material behaviour, return to the source scene and correct the cause instead of compensating with arbitrary destination transforms. Re-export to the same controlled location and verify that the correction survives a clean import. Add a presentation validation pass after technical import.
Assign temporary high-contrast materials to confirm slots, place a known-size proxy nearby, add neutral light and frame the object with a simple camera. Orbit around the asset to expose reversed normals, floating parts or unexpected clipping. Then test the working build rather than relying on the editor view alone. Keep a handoff log with the fault, source-side correction and destination evidence for each attempt.
Before submission, repeat the contract from a clean Maya checkpoint and a fresh Unity scene. A reliable handoff is reproducible: another person should be able to identify the asset, import it at sensible scale, reconnect its intended materials and understand its hierarchy without guessing what any object represents.
