Unit 1: Working in Unity 3D - Subjective Questions

Unity's coordinate system is used to describe the location and orientation of GameObjects in a three-dimensional scene.

• X-axis: Represents horizontal movement. Positive X points to the right, while negative X points to the left.
• Y-axis: Represents vertical movement. Positive Y points upward, while negative Y points downward.
• Z-axis: Represents depth. Positive Z generally points forward, while negative Z points backward.

Every GameObject has a Transform component containing:

• Position: Stores the object's location as .
• Rotation: Stores orientation using Euler angles in the Inspector, although Unity internally uses quaternions.
• Scale: Stores the size multiplier along each axis. A scale of represents the original size.

Unity distinguishes between world space, which uses the scene's global origin, and local space, which defines a child object's transform relative to its parent.

World space describes a GameObject's transform relative to the global scene origin . Local space describes its transform relative to its parent.

For example, suppose a parent object is located at and its child has a local position of . If no rotation or scaling affects the relationship, the child's world position is:

Effects of parenting include:

• Moving the parent also moves its children.
• Rotating the parent changes the children's world positions and orientations.
• Scaling the parent can alter the apparent size and spacing of its children.
• The child's transform.localPosition is relative to the parent.
• The child's transform.position is its location in world space.

Parenting is useful for structures such as vehicles with wheels, characters holding weapons, and camera rigs.

Unity's Transform tools allow developers to place and manipulate GameObjects visually in the Scene view.

• Translation: Changes the object's position along the X, Y, and Z axes. It is performed with the Move tool or by changing Transform.position.
• Rotation: Changes the direction in which the object is oriented. It is performed with the Rotate tool or by changing Transform.rotation.
• Scaling: Changes the object's size along one or more axes. It is performed with the Scale tool or by changing Transform.localScale.

The tools can operate using:

• Global orientation: Gizmo handles align with the world axes.
• Local orientation: Gizmo handles align with the object's own rotated axes.
• Pivot mode: Manipulation occurs around the object's pivot.
• Center mode: Manipulation occurs around the calculated center of the selection.

Accurate transformation is important for level construction, object alignment, animation, physics, and camera composition.

A behavior defines how a GameObject responds, changes, or interacts during gameplay. In Unity, behaviors are commonly implemented as C# classes derived from MonoBehaviour and attached as components.

A simple movement script can:

• Store movement speed in a public or serialized variable.
• read player input every frame.
• calculate a movement direction.
• update the object's Transform or Rigidbody.

Example:

using UnityEngine;

public class PlayerMovement : MonoBehaviour
{
    [SerializeField] private float speed = 5f;

    void Update()
    {
        float horizontal = Input.GetAxis("Horizontal");
        float vertical = Input.GetAxis("Vertical");
        Vector3 direction = new Vector3(horizontal, 0f, vertical);
        transform.Translate(direction * speed * Time.deltaTime);
    }
}

Time.deltaTime makes movement approximately frame-rate independent because distance is calculated as:

The script becomes an active behavior when it is attached to a GameObject.

Unity invokes lifecycle methods at specific stages while a component is active.

• Awake: Called when the script instance is loaded. It is suitable for initializing internal references and state, even before gameplay begins.
• Start: Called before the first frame update when the component is enabled. It is useful when initialization depends on other objects completing Awake.
• Update: Called once per rendered frame. It is commonly used for input, timers, and non-physics gameplay logic.
• FixedUpdate: Called at a fixed time interval. It is preferred for applying forces or making physics-related Rigidbody changes.
• LateUpdate: Called after all regular Update calls. It is useful for follow cameras and logic that must occur after another object has moved.

A common arrangement is to collect input in Update, apply Rigidbody forces in FixedUpdate, and reposition a follow camera in LateUpdate.

Transform-based movement directly changes transform.position, calls Translate, or sets rotation. It provides exact control but may bypass parts of Unity's physics simulation.

Rigidbody-based movement uses methods such as AddForce, MovePosition, and MoveRotation, allowing the physics engine to process collisions, mass, drag, and momentum.

Transform-based movement is suitable for:

• Non-physical objects such as markers or interface elements in world space.
• Simple moving platforms when collision handling is carefully designed.
• Teleportation or deliberate instant repositioning.
• Objects that do not require realistic physical interaction.

Rigidbody-based movement is suitable for:

• Player characters that interact with physics objects.
• Vehicles, projectiles, and movable props.
• Objects requiring collision response, gravity, momentum, or forces.

Physics operations should generally be applied in FixedUpdate. Directly changing the Transform of a dynamic Rigidbody can produce tunneling, jitter, or unrealistic collision responses. For controlled physics movement, Rigidbody.MovePosition is often preferable to directly changing transform.position.

Unity's Particle System generates and controls many small visual elements to simulate fire, smoke, sparks, rain, and similar effects.

Important modules for a fire effect include:

• Main: Sets particle duration, start lifetime, speed, size, gravity, simulation space, and maximum particle count.
• Emission: Controls how frequently particles are produced. A steady rate creates continuous flames, while bursts can create explosions.
• Shape: Defines the emission region. A cone or small hemisphere is suitable for fire.
• Color over Lifetime: Changes particles from bright yellow or white to orange, red, and transparent.
• Size over Lifetime: Makes flames expand or shrink as they rise.
• Velocity over Lifetime: Adds upward movement and sideways variation.
• Noise: Produces turbulent, irregular motion.
• Renderer: Assigns the particle material, rendering mode, and sorting behavior.

A convincing fire effect usually combines short lifetimes, upward motion, warm colors, fading transparency, random variation, and an additive or alpha-blended material.

The behavior of a Particle System depends strongly on the following properties:

• Simulation space: In local space, emitted particles continue to move relative to the Particle System. In world space, emitted particles remain independent when the emitter moves.
• Emission rate: Determines the number of particles produced per unit of time or distance.
• Particle lifetime: Determines how long each particle remains active.
• Particle speed: Determines how quickly particles move after emission.

For rain:

• Use a high emission rate.
• Use a large box-shaped emitter above the scene.
• Give particles high downward speed.
• Use a lifetime long enough for drops to reach the ground.
• World simulation space is generally useful for moving weather systems.

For smoke:

• Use a moderate emission rate.
• Give particles a longer lifetime.
• Use low upward speed and add noise.
• Increase particle size and reduce opacity over time.
• Use world space when smoke should remain behind a moving emitter.

These settings must be balanced with the maximum particle count to maintain performance.

A material defines how the surface of a GameObject is rendered. It stores a reference to a shader and the values or textures required by that shader.

• Shader: A program executed by the GPU to determine how vertices and pixels are processed.
• Texture: An image or data map applied to a surface through UV coordinates.
• Albedo or Base Map: Defines the basic visible color of the material without lighting details.
• Normal Map: Simulates small bumps and surface details by modifying lighting calculations without adding geometry.
• Metallic value: Indicates whether the surface behaves like a metal. Metallic surfaces reflect their environment differently from non-metals.
• Smoothness: Controls the sharpness of reflections. High smoothness creates sharp highlights, while low smoothness creates broad, dull highlights.

Materials allow the same mesh to appear as wood, stone, plastic, glass, or metal without changing its geometry.

Opaque materials fully block objects behind them and are generally the most efficient to render. They are appropriate for walls, terrain, furniture, and solid characters.

Transparent materials blend their color with previously rendered pixels. They are used for glass, water, smoke, holograms, and translucent effects. However, they can introduce:

• Sorting problems when multiple transparent surfaces overlap.
• Higher overdraw because pixels behind the surface may also be rendered.
• Limited or disabled depth writing, depending on the shader.

Emission-based materials appear to produce light visually by adding an emission color or texture. They are suitable for screens, neon signs, lava, and magical objects. Emission does not automatically illuminate surrounding objects in every rendering setup; actual lights or baked global illumination may also be required.

For performance, developers should minimize unnecessary transparency, reduce large overlapping transparent surfaces, and use simple shaders when targeting mobile or low-end hardware.

Unity provides different light types for different illumination requirements:

• Directional Light: Represents a very distant light source whose rays are treated as parallel. Its position does not affect illumination, but its rotation determines direction. It is commonly used for sunlight or moonlight.
• Point Light: Emits light in all directions from a single position within a specified range. It is suitable for bulbs, lamps, torches, and explosions.
• Spot Light: Emits light in a cone. Its position, rotation, range, and cone angle affect the result. It is used for flashlights, vehicle headlights, and stage lighting.
• Area Light: Emits light from a rectangular or shaped surface, producing softer and more realistic illumination. Its availability and behavior depend on the render pipeline and whether lighting is baked or real-time.

Choosing the correct light type improves realism and performance. For example, one directional light is usually more efficient for sunlight than many point lights distributed across an outdoor scene.

Real-time lighting is recalculated while the game runs. It supports moving lights and objects but can be computationally expensive.

Baked lighting is calculated in advance and stored mainly in lightmaps. It provides high-quality indirect lighting at a lower runtime cost, but baked light does not dynamically respond to changes in static geometry or lighting.

Mixed lighting combines baked illumination for static objects with real-time contributions for dynamic objects. Its exact behavior depends on the selected mixed-lighting mode and render pipeline.

Supporting systems include:

• Shadows: Provide depth and spatial cues but increase rendering cost. Resolution, distance, cascades, and light count influence performance.
• Lightmaps: Textures containing precomputed lighting for static geometry.
• Light Probes: Store sampled lighting information so dynamic objects can appear integrated with baked environments.
• Reflection Probes: Capture environmental reflections for shiny or metallic materials.

A practical optimization is to bake static architectural lighting, use probes for moving characters, and reserve real-time shadow-casting lights for important dynamic effects.

Unity primarily uses an Audio Source and an Audio Listener to play and hear sound.

• An Audio Source is attached to the GameObject that produces sound.
• An Audio Clip contains the recorded or generated sound data.
• An Audio Listener receives audio for the player and is normally attached to the main camera.

Important Audio Source properties include:

• Volume: Controls loudness.
• Pitch: Changes playback speed and perceived pitch.
• Loop: Repeats the clip continuously.
• Play On Awake: Starts playback when the object becomes active.
• Spatial Blend: Selects between 2D and 3D sound.
• Min Distance: Defines the range within which the sound is heard at maximum volume.
• Max Distance: Defines the range beyond which attenuation stops or the sound becomes effectively inaudible.
• Doppler Level: Controls the pitch change caused by relative motion.

Unity normally requires only one active Audio Listener in a scene to avoid ambiguous audio output.

2D audio is not affected by the position of the Audio Source relative to the listener. It is appropriate for menu music, user-interface sounds, and non-diegetic background music.

3D audio changes according to the spatial relationship between the source and listener. It is suitable for footsteps, vehicles, enemies, environmental machines, and explosions.

• Spatial Blend: A value near 0 produces 2D behavior, while a value near 1 produces fully spatial 3D behavior. Intermediate values blend both.
• Attenuation: Reduces perceived volume as distance increases. Unity supports logarithmic, linear, and custom rolloff curves.
• Stereo panning: Makes sound appear more strongly from the left or right according to source direction.
• Doppler effect: Changes perceived pitch when the source and listener move relative to one another. An approaching vehicle sounds higher in pitch, while a departing vehicle sounds lower.

Effective 3D audio communicates direction and distance, helping players locate events even when they are outside the camera's view.

Camera positioning determines what the player sees and strongly affects gameplay, navigation, and visual composition.

Important positioning factors include:

• Keeping the main subject clearly visible.
• Choosing a suitable height, distance, and viewing angle.
• Preventing walls and objects from blocking the subject.
• Maintaining a stable horizon and avoiding uncomfortable motion.
• Considering gameplay information such as enemies, obstacles, and destinations.

Important Camera properties include:

• Field of View: Controls the vertical angular extent of a perspective camera. A larger field of view displays more of the scene but can create edge distortion. A smaller value creates a zoomed appearance.
• Near Clipping Plane: Objects closer than this distance are not rendered. A very small value can reduce depth-buffer precision.
• Far Clipping Plane: Objects farther than this distance are not rendered. Excessively large values can also reduce depth precision and render unnecessary content.
• Aspect Ratio: Represents the ratio of screen width to height and changes horizontal framing across devices.

Good camera design balances visibility, performance, spatial awareness, and player comfort.

A basic third-person camera can be created by maintaining an offset from a player target.

Implementation steps:

1. Store a reference to the player Transform.
2. Define an offset such as .
3. Read mouse or controller input to update yaw and pitch.
4. Rotate the offset using the desired camera rotation.
5. Calculate the desired position:

6. Smoothly move the camera toward that position with Vector3.Lerp or Vector3.SmoothDamp.
7. Aim the camera toward a point near the character's upper body.
8. Perform a raycast or sphere cast from the target toward the desired camera position. If a wall is detected, move the camera in front of the obstacle.
9. Run the follow logic in LateUpdate so the target has already completed its movement.

Pitch should be clamped to prevent the camera from rotating through the ground or flipping upside down. Collision recovery should also be smoothed to avoid abrupt changes.

Shader Graph is Unity's node-based system for visually creating shaders without manually writing all shader code. It is primarily used with supported Scriptable Render Pipelines such as URP and HDRP.

Its main elements are:

• Nodes: Perform operations such as sampling textures, combining colors, calculating vectors, and generating procedural patterns.
• Properties: Exposed values such as colors, textures, floats, and vectors that can be edited through a material.
• Ports: Input and output connection points through which data passes between nodes.
• Blackboard: Stores and organizes exposed shader properties.
• Master Stack: Defines the final surface and vertex outputs used by the shader.

For a lit material, the graph may connect:

• A texture sample to Base Color.
• A normal map to Normal after appropriate normal processing.
• Float properties to Metallic and Smoothness.
• An HDR color or texture to Emission.
• An alpha value to Alpha when transparency or clipping is required.

Shader Graph provides immediate visual feedback and supports reusable, artist-friendly material controls.

A pulsing emissive material can be created by varying emission intensity with time.

Graph construction:

1. Create a Color property and enable HDR so it can produce strong emission values.
2. Add a Time node.
3. Multiply the time value by a Speed property.
4. Pass the result through a Sine node.
5. Since sine produces values between and , remap it to through :

where is time and is pulse speed.

6. Multiply by an Intensity property.
7. Multiply the result by the HDR emission color.
8. Connect the final value to the Emission block of a Lit Master Stack.
9. Connect the normal texture and surface properties to Base Color, Normal, Metallic, and Smoothness if the surface should also respond to scene lights.

The Lit target allows direct-light interaction, while the emission output makes the material appear self-illuminated. Bloom can create a visible glow around bright pixels. To illuminate nearby static surfaces, baked global illumination may be used; dynamic illumination may require an actual Light component or a render-pipeline-specific solution.

Cinemachine is Unity's camera-control system for creating dynamic camera behavior without writing every movement rule manually.

Its major elements include:

• Cinemachine Brain: Usually attached to the Unity Camera. It selects the active Cinemachine camera and applies its calculated position, rotation, and blending.
• Cinemachine Virtual Camera: Stores camera behavior and shot settings. It does not render directly; the Brain transfers its result to the real Camera.
• Follow target: The Transform whose movement influences the virtual camera's position. It is commonly assigned to a player or camera rig.
• Look At target: The Transform toward which the camera aims or composes the shot.

Additional settings can control damping, offsets, framing, procedural rotation, lens properties, noise, and extensions. Multiple virtual cameras can represent gameplay, dialogue, aiming, and cinematic shots. Cinemachine chooses between them according to activation state or priority and can blend smoothly during transitions.

A multi-mode system can use separate Cinemachine cameras for different gameplay situations.

Exploration camera:

• Follows the player with a moderately wide field of view.
• Uses damping for smooth motion.
• Keeps the character slightly off-center to show the direction of travel.

Aiming camera:

• Uses a closer over-the-shoulder offset.
• Has a narrower field of view.
• Uses lower damping for responsive control.
• Looks toward an aim target or reticle direction.

Dialogue camera:

• Frames the active speaker or both characters.
• May use a stationary angle or target-tracking shot.
• Can use multiple virtual cameras for shot and reverse-shot composition.

Control strategy:

• Assign each camera a priority.
• Raise the aiming camera's priority while the aim input is held.
• Raise the dialogue camera's priority during a conversation.
• Restore the exploration camera when special modes end.
• Configure the Cinemachine Brain's default blend to create smooth transitions.
• Use custom blends if aiming must transition quickly while dialogue transitions slowly.

Quality and safety:

• Tune damping to remove jitter without creating excessive delay.
• Use screen composition settings to keep the subject within a safe region.
• Add a collision or deocclusion extension so the camera moves closer when walls block the target.
• Use impulse or noise carefully for impacts and camera shake.

This structure separates each shot's requirements while allowing Cinemachine to manage transitions and final camera movement.