Objects are a high-level abstract tag, meaning they serve as a base for many other tag types but cannot be directly created themselves. Generally, they are "things" with a position in the world but are distinct from the "level" itself. Some examples include elevators, trees, warthogs, and the player.

Some capabilities available to objects (though not used by every subtype) are:

• Be rendered with a model
• Have physics and be collideable
• Cast shadows using lightmap data
• Have attachments like particles, sounds, and lights
• Be attached to each other (e.g. pelicans carrying warthogs)

Functions

Functions are values of objects that can change over time and/or react to external stimulus. They can be combined in complex ways and used to drive dynamic changes across various aspects of the object, like its appearance, sound, and attachments. Some examples are Jackal shields changing colour in reaction to damage, Warthog headlights turning on when you enter the vehicle, Banshee wingtips emitting contrails when banking, and the Assault Rifle's compass pointing north.

Objects can receive up to 4 sources of input from the engine called A in, B in, C in, and D in. These can be used as inputs by your functions or change colors. Every type of object has access to sources from the export to functions section. However, certain types of objects can override these base sources with additional sources related to that object type. To name a few, devices have access to position and power while vehicles have access to speed and slide.

The next relevant section is the functions block. This is where you can define functions and how the change over time, and if they use any of the export to functions inputs. Each function produces a simple numeric value over time, typically between 0 and 1. This could be as simple as an oscillating sine wave or as complex as a noise value scaled by recent damage and clipped to a certain range. You can create up to 4 functions.

The outputs of functions can be used by a variety of other tags related to the object, including but not limited to:

• Set the scales of attachments like lights or sounds.
• Affect values in widgets like glows.
• Scale or darken change colors.
• Affect the object's shaders in various ways, like fade or texture animation.

Shadows and lighting

For most dynamic objects, Halo uses shadow mapping with their render model, unless the object's "does not cast shadow" flag is true or render_shadows is disabled. Scenery shadows are baked into the lightmap using the object's collision geometry instead, regardless of the "does not cast shadow" flag. Static objects can be forced to use shadow mapping if the cast shadow by default flag is set.

Objects receive a few parameters from the environment as inputs to their lighting model. These include up to two distant light sources (direction and colour), ambient light, reflection tint, shadow direction, and shadow colour. Lighting is calculated when objects are created and also when dynamic objects move. To do this the game casts a ray straight down to a BSP ground point up to 10 world units away (device_machine can optionally sample nearby surfaces instead) to determine its lighting and can result in a few scenarios:

1. If a ground point is found within 10 units, that surface's lightmap colour is used to light the object. This is why even an object in direct sunlight can appear dark when it is sampling the ground beneath it. The shadow vector is an interpolation of lightmap vertex normals. In this scenario you will see a coloured vector drawn over objects with debug_object_lights 1.
2. If a ground point is not found and the BSP tag has a non-zero red value for default ambient color field, BSP default lighting fields will apply.
3. Otherwise the object receives hard-coded white light from the +x +y direction and casts shadows straight down.

You can test the latter two scenarios by setting debug_collision_skip_vectors 1 to make the ray cast always fail. Objects which are outside the BSP will fail to find a valid ground point and therefore receive default lighting. Objects above phantom BSP and nearly coplanar faces may similarly fail.

BSP switches do not cause fixed objects to resample lighting.

Related HaloScript

(debug_objects [boolean])

(debug_objects_biped_autoaim_pills [boolean])

(debug_objects_biped_physics_pills [boolean])

(debug_objects_bounding_spheres [boolean])

(debug_objects_collision_models [boolean])

(debug_objects_names [boolean])

(debug_objects_pathfinding_spheres [boolean])

(debug_objects_physics)

(debug_objects_position_velocity)

(debug_objects_root_node)

(debug_objects_unit_seats)

(debug_objects_unit_vectors)

(debug_object_lights)

(object_light_ambient_base)

(object_light_ambient_scale)

(object_light_interpolate)

(object_light_secondary_scale)

(rasterizer_environment_shadows [boolean])

(render_shadows [boolean])

Structure and fields

Acknowledgements

Thanks to the following individuals for their research or contributions to this topic:

• Connor Dawn (Explaining cast shadow by default)
• Conscars (Shadow behaviour testing)
• Jakey (Explaining modifier shaders.)
• Kavawuvi (Invader tag definitions)
• MosesOfEgypt (Tag structure research)
• Satania (Explaining acceleration scale)