This chapter links to the course’s interactive demos and uses MathJax for its formulas. Read it through the course website (or download the file and open it in a browser); a Canvas inline preview will reach neither the demos nor the math. All chapters.

Unity for This Course: the Editor, Objects, Scripts, and the Math Types

Unity 1.0 was launched on stage at Apple's WWDC in June 2005, and its editor ran only on Mac OS X. Unity Technologies; Apple WWDC 2005

The mathematics of this text is engine-independent. The practice is not. Each homework (HW1 to HW6) can be done in either of two tracks, Unity or WebGL (the course’s JavaScript demo library over three.js), and HW7 and HW8 in JavaScript or Python. This chapter serves the Unity track, which assumes a working knowledge of the editor, the object model, the scripting lifecycle and the engine’s math types that no lecture has time to teach; the chapter supplies that knowledge in the order the homework needs it. It is not a Unity tutorial in the usual sense. It skips terrain, physics, audio, animation clips and everything else a game needs, and it goes deeper than a tutorial on the four things a graphics course needs: the transform hierarchy and what local and world mean in numbers, the frame loop and its two clocks, the matrix type and its storage, and the difference between the engine’s conventions and the text’s. The course rule, implement and replace, is stated at the end with the list of helpers it forbids and the primitives it allows.

1 · Installing, and the one version

Unity is installed through Unity Hub, a launcher that manages editor versions, licenses and projects. The course pins one editor version, Unity 6000.3.11f1 LTS, and every class-example project was saved by it. Opening a project in a different version triggers an upgrade that rewrites project files, produces diffs that are not your work, and occasionally breaks a script; if Hub offers to open a project in a newer version, decline and install the pinned one from Installs. A personal license is free and sufficient. The editor download is several gigabytes; start it before the first homework, not during it.

A project is a folder. Everything the editor knows about it lives under Assets/ (your scenes, scripts, materials, textures, in whatever subfolders you make) and ProjectSettings/; the Library/ folder is a cache the editor rebuilds and should never be shared or committed. The class-example projects arrive as zip files on Canvas; unzip one, add its folder in Hub under Projects, and open it. The first open of any project compiles its scripts and imports its assets, which takes a minute and is normal.

2 · The editor: six windows and a button

• Hierarchy lists the objects in the open scene as a tree. Indentation is parenting, and parenting is the scene graph of the scene-graph chapter: a child’s transform is expressed in its parent’s frame. Drag one object onto another to parent it.
• Scene is the world seen from the editor camera, which is not an object in the scene and is not what the player sees. Orbit it with Alt and the left mouse button, pan with the middle button, zoom with the wheel, and press F with an object selected to frame it. The three colored handles on a selected object are the move gizmo (x red, y green, z blue); W, E, R switch between move, rotate and scale.
• Game is the scene’s own camera’s view, the player’s picture, drawn only in Play mode.
• Inspector shows the selected object’s components with their editable fields, including the public fields of your scripts. Dragging a scene object onto a field of object or component type is how references are wired without code.
• Project is Assets/ on disk. Double-click a script to open it in the external editor (Visual Studio, Rider or VS Code); double-click a scene to load it.
• Console shows Debug.Log output, warnings, and compile errors. A compile error anywhere in the project stops Play from starting; the Console names the file and line.

3 · Scenes, objects, components

Two consequences shape every class-example script. First, a script needs to know which object it is on and which others it should touch: transform and gameObject are the script’s own; GetComponent<T>() finds a sibling component on the same object; and a public field of type GameObject, Transform or a script type is filled by dragging in the Inspector. Second, the Inspector is the engine’s view of your model: a public field is visible and editable there, and its Inspector value overrides the initializer in the code. The class-example projects use this constantly, and it is the first place to look when a value in the code seems to have no effect.

4 · Scripts: the lifecycle and the two clocks

A console program runs top to bottom and exits. An interactive program exits only when the player quits: until then the engine runs the loop of the rasterization chapter (read input, update the state, draw), and a script hooks the middle of it; on quit it calls OnApplicationQuit, then OnDestroy. The hooks are methods with fixed names on a class deriving from MonoBehaviour.

using UnityEngine;

public class Bounce : MonoBehaviour {
    public float yRange = 3f;          // visible in the Inspector; its value there wins
    public float speed  = 2f;
    private float dir   = 1f;          // private: not shown, not overridden

    void Start() {                     // once, before the first frame this object is active
        Debug.Log("Bounce on " + gameObject.name);
    }

    void Update() {                    // once per frame, whatever the frame rate
        Vector3 p = transform.localPosition;         // a copy (Vector3 is a struct)
        p.y += dir * speed * Time.deltaTime;         // rate times seconds: per-second motion
        if (p.y > yRange || p.y < -yRange) dir = -dir;
        transform.localPosition = p;                 // write the copy back, or nothing moves
    }
}

5 · C# for people who know Java or C++

Unity scripts are C#, and a programmer who knows Java or C++ can read them at once. The differences that matter for the homework fit in one table; the one that causes bugs is the last row.

6 · The Transform: local, world, parent

Two facts about scale. A non-uniform scale on a parent shears a rotated child, which is why the engine exposes lossyScale rather than a true world scale and why the scene-graph chapter warns against scaling anything but leaves. And localScale scales about the object’s own origin, which for an imported mesh is wherever the modeler put it; the class examples’ pivot sandwich (the affine chapter) exists because the mesh origin and the desired pivot rarely coincide.

7 · The math types, against the text’s conventions

Unity’s Vector3, Quaternion and Matrix4x4 are the objects of the vectors, rotation and affine chapters with a few differences of convention. All the algebra transfers; three conventions need naming.

8 · Meshes, materials, textures, prefabs, cameras, lights

Mesh. A Mesh object holds the arrays of the meshes chapter: vertices (Vector3[]), triangles (int[], three per triangle, clockwise seen from the front in Unity’s left-handed convention), normals, uv (Vector2[]). A MeshFilter holds the mesh and a MeshRenderer draws it. Build by filling local arrays and assigning each whole array once; RecalculateNormals() computes the averaged normals the chapter derives by hand, and the class-example projects compute them by hand instead, which is the point.

Material and texture. A material is a shader plus the values of its properties; the same shader with different values is a different material. renderer.material returns a per-object copy (editing it affects one object), sharedMaterial the asset itself. A texture is an image asset; drop it into the Assets folder and Unity imports it, and the material’s main texture slot takes it. The shader chapter covers what the material feeds to the shader and how a script sets properties from code.

Prefab. A prefab is a saved GameObject (with its components and children) that can be instantiated any number of times: Instantiate(prefab, position, rotation) returns a new copy, and Destroy(obj) removes one at the end of the frame. The class examples’ vertex handles are instantiated sphere prefabs, one per vertex.

Camera and light. The scene’s camera is a GameObject with a Camera component; its Transform is the eye and its fields (fieldOfView, aspect, nearClipPlane, farClipPlane, orthographic) are the parameters of the viewing chapter. Camera.main finds the one tagged MainCamera; ScreenPointToRay(Input.mousePosition) is the unprojection of the interactive-systems chapter. A Light component makes its object a directional, point or spot light with a color and an intensity; the class-example shaders ignore the engine’s lighting and read the light’s transform themselves.

9 · Input, UI, and drawing debug geometry

The class-example projects use the classic input API: Input.GetKey(KeyCode.W) is true while a key is held, GetKeyDown on the frame it was pressed, Input.GetMouseButton(0) for the left button, Input.mousePosition for the pointer in window pixels (origin at the bottom left), and Input.GetAxis("Mouse X") for the pointer’s motion this frame. Unity 6 also ships the newer Input System package; the class-example code does not use it, and a project set to one API silently ignores the other.

User interface elements (sliders, buttons, toggles) live on a Canvas object and are wired to scripts by events: a Slider’s onValueChanged.AddListener(handler) calls the handler with the new value. The first class-example projects are built this way, and the pattern is the controller of model-view-controller: the handler writes the model, and the views read it on the next frame.

Drawing a line or a point for debugging needs no mesh. Debug.DrawLine(a, b, Color.red) draws a segment in the Scene view for one frame (call it every Update); Debug.DrawRay(origin, dir) likewise; Gizmos.DrawSphere inside an OnDrawGizmos() method draws in the editor even when not playing. The vector class examples use line-renderer prefabs for the same purpose so the lines appear in the Game view too.

10 · Reading a class-example project

Every class-example project follows one layout: a single scene under Assets/Scenes, scripts under Assets/Source (sometimes split into Model, UI Support, Prefab Support), and a MainController script on an object named Controller that wires the UI and owns the world. The reading order that works:

1. Open the scene and press Play to see what it does; stop.
2. In the Hierarchy, select Controller and read its Inspector: the public fields are the model’s parameters and the references to the objects it drives.
3. Open MainController.cs. Start is the wiring (the AddListener calls); Update is the per-frame work; the handlers are the controller of MVC.
4. Follow one value from a UI event to the screen: which handler, which model field, which object’s transform or mesh or material changes.
5. Predict the effect of one change, make it, Play, compare. That loop is the homework’s method.

The projects are Kelvin Sung’s CSS 451 class examples, written for teaching rather than for shipping: names are explicit, helpers are avoided on purpose, and the comments say what the code is for. Where a project’s convention differs from the lecture’s (a quad split along the other diagonal, a matrix built from rows rather than columns), the homework page says so, and both are correct.

11 · The course rule: implement and replace

Each homework page (one per assignment, homework/hwNN/index.html on the course site) names its own list for both tracks and is the authority on which helpers it forbids. This table is also the WebGL track’s (its third column); WebGL and three.js for This Course refers to it rather than repeating it. The habit the rule builds is the one the text is written for: to know what the helper does, and to be able to say, with a number, whether it did it.

12 · Exercises