Custom Boot Models

Custom Boot Models

The native build can replace the models on its boot screens with a glTF of your own, without editing source and without rebuilding. Drop a file in, the game draws it; delete the file, the original comes back. The feature is documented in full in docs/asset-overrides.md.

Only the model is replaceable. Each screen keeps its own duration, camera, rotation, scale-in, fade and transitions, so a custom model inherits the original's spin — Rare's choreography, faithfully reproduced.

What can be replaced

Asset id	What it replaces
boot.nintendo_logo	the model on the Nintendo boot screen
boot.rareware_logo	the model on the Rareware boot screen
boot.goldeneye_logo	the GOLDENEYE logo model on the logo screen
boot.legal_page	the artwork layer of the Legal screen (six flat quads; the legal wording is font-rendered at run time and is not part of the model)
controllers.xbox	the Xbox-family controller on the watch's Control Options page (a model with a part table: one node per physical control, extras.sl_part — see docs/asset-overrides.md, "Parts")
controllers.dualsense	the PlayStation-family controller, the same page

The shipped models

The repository ships original artwork authored for Sightline: four replacement boot models under data/asset-overrides/source/boot/ — goldeneye_logo, legal_page, nintendo_logo and rareware_logo. Each is committed as source (the glTF, its buffers, PNG textures and provenance notes), and build.ps1 converts every package into build\win32\data\asset-overrides\, so a build shows them with no import step. The converted .slmodel is a build output and is not tracked.

The four boot models are released under CC0 1.0 Universal — see data/asset-overrides/LICENSE.md and Licensing. A release package ships the compiled .slmodel files under data\asset-overrides\boot\.

To see the original logos instead, turn the whole feature off:

$env:SL_ASSET_OVERRIDES = "0"

The controller models

Since v0.2.0 the tree also ships two controller models under data/asset-overrides/source/controllers/ — xbox (asset id controllers.xbox) and dualsense (controllers.dualsense). The watch's Control Options page draws the attached controller in place of the N64 pad when an Xbox-family or PlayStation-family pad is driving the game, its parts moving with your hands and the family's own button names beside it (see Running the Game). Like the boot models they are committed as glTF source, compiled by build.ps1, and shipped compiled in a release package under data\asset-overrides\controllers\. With no such pad, or with the feature turned off, the page draws the original N64 controller.

These two models are not Sightline-authored and are not CC0. They are third-party work under CC-BY-4.0, modified for Sightline:

• the Xbox pad is based on "Xbox Controller" by umkhero (source);
• the DualSense is based on "Playstation 5 Dualsense" by AHarmlessPotato (source);

both under CC-BY-4.0. The changes (each mesh split into one node per physical control with pivots, re-based into the N64 pad's model frame, PBR maps dropped, textures resized, manufacturer logos removed, compiled to .slmodel) and the full credit line a release must reproduce are in each package's ATTRIBUTION.md, which the release package carries under LICENSES\third-party\controllers\<name>\. Their glTF declares every image as extras.sl_third_party, never sl_authored, and the importer refuses a file that claims both. The one Sightline-authored part in each — the plain Guide and PS buttons that replace the logo-shaped originals — is flagged sl_authored_part. No endorsement by the authors is implied. Neither model is derived from any GoldenEye data.

Installing your own

Export from Blender with File → Export → glTF 2.0 (.glb or .gltf, PNG textures only) and point asset-import.ps1 at what it wrote:

.\tools\windows\asset-import.ps1 -Asset boot.nintendo_logo -Input D:\Models\mine.glb
.\tools\windows\asset-import.ps1 -Asset boot.rareware_logo -Input D:\Models\other.glb
.\tools\windows\play.ps1

Nothing needs rebuilding; the next launch picks the model up. Other parameters:

Parameter	Effect
-Remove <asset id>	Delete the override you installed. The shipped model (if any) renders next, otherwise the original.
-Where	Print the resolved override directory and exit.
-List	Show which overrides are currently installed.
-Scale <n>	A uniform scale baked into the model at import (default 1.0). One glTF unit is one N64 model unit; every import prints your model's bounds beside what the target screen frames and suggests a -Scale when they are far apart.
-Output <path>	Write the converted model somewhere of your choosing instead of installing it, for inspection.
-TextureRef IMAGE=IDENTIFIER	Declare that an image is one of the game's own textures when it has been re-saved or edited and is no longer recognised by content.
-GameTextures	List the game textures a model may reference, and exit.
-Help	Print the converter's full help: the supported glTF subset, the coordinate contract and the size limits.
-Repo	Write into the repository's data/asset-overrides/ instead of your install directory (for contributors; see the provenance rule below).

Your model is installed outside the tree, beside the save file. The search order at run time puts yours first:

your install directory  ->  data/asset-overrides  ->  the original

so importing replaces a shipped model, and -Remove uncovers the shipped one again. The install directory is SL_ASSET_OVERRIDE_DIR if set, otherwise %LOCALAPPDATA%\sightline\assets.

The supported glTF subset is static triangle meshes with POSITION, NORMAL, TEXCOORD_0 and COLOR_0, base-colour factors and PNG textures, OPAQUE/MASK/BLEND alpha modes and KHR_materials_unlit. Skinning, morph targets, animation, JPEG textures and other extensions are rejected with a message rather than a wrong picture. There is no PBR renderer: a model with normals gets one fixed light from the camera; one without is drawn unlit from its base colour.

No ROM-derived pixels, and the provenance declaration

Anything derived from a ROM never enters the repository. A model may reuse one of the game's own textures — but the pixels do not travel with it. The importer hashes every incoming texture against the game textures it knows (rareware.env_field, rareware.env_gold, nintendo.logo_i8); on a match it stores a reference by identifier and drops the pixels, and the game resolves the texture from your own ROM at load. This applies to models you install for yourself too: no .slmodel the tool writes contains game pixels.

For a model committed to the repository (-Repo), the rule is stricter: the importer refuses to write any embedded pixels at all, unless the glTF itself declares them as the author's own work:

"extras": {
  "sl_authored": true,
  "sl_authored_provenance": "how these pixels were made"
}

on the glTF image or texture. The declaration is never inferred, the provenance string is required and non-empty, and it is read only after game-texture detection has already turned any recognised texture into a reference — so it cannot carry ROM pixels into the tree. "No ROM-derived assets" and "no artwork of our own" are different rules, and only the first applies.

Related

• data/asset-overrides/README.md
• Licensing