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)
For most dynamic objects, Halo uses shadow mapping with their render model, unless the object's "does not cast shadow" flag is true. However, with scenery, shadows are baked into the lightmap using the object's collision geometry instead, regardless of the "does not cast shadow" flag.
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 to determine its lighting and can result in a few scenarios:
- 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
- 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.
- 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. Scenery which are outside the BSP will also fail to get a ground point and therefore receive default lighting.
When enabled, toggles if debug information is visible on objects (such as bounding sphere and collision models). Individual debug features can be toggled with the
Toggles the display of object names, for named objects. The names are shown in purple.
Shows the incoming light colour and vector for all objects which results from sampling lightmap data at the ground point beneath the object. This data is used to shade the object and cast its shadow.
Sets the amount of ambient light all objects receive. Note that this only affects moving objects when their lighting updates, so you will not see any change on scenery. Setting this to
Scales ambient light from the lightmap. Defaults to
Toggles if object lighting transitions smoothly when the object moves between different ground point surfaces or default lighting.
Scales secondary light on objects, but doesn't apply to default lighting. Defaults to
The bounding radius sets the approximate maximum size of the object and is used for a variety of optimizations by the game:
The radius should contain this object completely, but not be too large. Setting it too high will cause the object to draw unccessarily when off-screen, but setting it too low will cause the object to have clipped shadows, pop in and out of visibility at the edges of the screen, and have inconsistent collision with other objects.
The bounding radius can be visualized in Sapien or Standalone using debug_
|scales change colors|
|render bounding radius|
|hud text message index|
|forced shader permutation index|
Thanks to the following individuals for their research or contributions to this topic:
- Jakey (Explaining modifier shaders.)
- Kavawuvi (Invader tag definitions)
- MosesOfEgypt (Tag structure research)
- Satania (Explaining acceleration scale.)