{"authorId":"","cover":"/content/images/2026/10/9e08d4941150-social-background.png","heroes":{"59ab1e54b3a5386e6900ca8678d4e839":"/content/images/2026/10/b1e12503f058-nullg-rl-full-preview.png","7b367212a739706ba4e3e9b999bec15d":"/content/images/2026/10/5febc720f2c6-nullg-rl-hero.png","9f1711a950f76598b42e3b1fd15b45f0":"/content/images/2026/10/44526a0d5fab-nullg-blender-fleet.png","b00b035b3794d4eb5846a7122bf026cf":"/content/images/2026/10/ab60de3338bd-nullg-weekly-fresh-xl-shield.png"},"kind":"tag","logo":"/content/images/2016/08/projectable-me-4.png","nav":[{"id":"62e854d471683dea63488bcbca5c6188","label":"Home","url":"/","sortOrder":0},{"id":"1bc84fb15620acd635df7735a0b8ddd8","label":"Projects","url":"/projects/","sortOrder":1},{"id":"3207e2fec51d66d2a5b3d8d04feb9dd8","label":"Sim Racing","url":"/tag/sim-racing/","sortOrder":2},{"id":"59115afd52e59a74faa4b386e00ae3fa","label":"About","url":"/about-me/","sortOrder":3}],"page":1,"perPage":10,"posts":[{"id":"b00b035b3794d4eb5846a7122bf026cf","siteId":"projectable","slug":"nullg-weekly-progress-xl-fleet-rl-pulse-pure","title":"NullG updates: the XL fleet, shields and a first Pulse race","markdown":"This week's [NullG](https://projectable.me/projects/nullg/) work covered the five rebuilt XL ships, weapon effects, split-screen and the learning pilots. There's also a first playable slice of WipEout Pulse. I've put the ships and all eleven XL weapon types into a new video:\n\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/2VYHD8xlsoM\" frameborder=\"0\" allowfullscreen\u003e\u003c/iframe\u003e\n\n## The XL ships\n\nFEISAR, AG Systems, Auricom, Qirex and Piranha now have rebuilt geometry and physically based materials, with more detail around the cockpits, engines and moving control surfaces. The [Blender article](https://projectable.me/nullg-recreating-wipeout-xl-models-in-blender/) covers how the models were reconstructed with the assistant and reviewed.\n\n![FEISAR and AG Systems in the Model Viewer](https://projectable.me/content/images/2026/10/0f9bf03cf410-nullg-weekly-fresh-fleet-a.png)\n\nA still render only tells part of the story with the moving parts. Qirex has a broad hull to clear when its surfaces move, while the thin surfaces on AG Systems and Piranha needed further refinement. This week's changes included those clearance and thickness checks, then reviews under the menu and track lighting.\n\n![Auricom, Qirex and Piranha with their control surfaces posed](https://projectable.me/content/images/2026/10/a300c3095728-nullg-weekly-fresh-fleet-b.png)\n\nFor the racing footage I used the newest completed RL checkpoint available when capture preparation started on October 25. It was an experimental pace-training checkpoint on simulation revision 48, still unaccepted for gameplay. I wanted the video to show where the training had reached that day.\n\nAll eight racers in each recorded field use the same saved policy, so continuing the training couldn’t change the driver halfway through recording. This week's training work also covered difficulty objectives, rewards, checkpoint retention and resuming earlier runs. The [RL page](https://projectable.me/projects/nullg/reinforcement-learning/) explains how the pilot produces steering, throttle, airbrake, pitch and weapon inputs.\n\n## Shields and weapons\n\nThe shield now has an animated surface around the hull, with the ship and engine flare visible through it. The close-up shows the surface moving while the ship stays visible underneath.\n\n![Blue shield surrounding Qirex on Sagarmatha](https://projectable.me/content/images/2026/10/ecc5894c0244-nullg-weekly-fresh-shield-closeup.png)\n\nFor the weapon shots I used controlled demonstrations with granted inventory. Rockets, missile and electrobolt show their launch, flight and impact; mines, quake, plasma and energy bomb show the larger track effects. Turbo, autopilot and the energy pack have their activation and status feedback too, making eleven types including the shield. The mine sequence also places a live mine to demonstrate the impact.\n\n![Rockets leaving Qirex on Sagarmatha](https://projectable.me/content/images/2026/10/e4a12b0e8f41-nullg-weekly-fresh-xl-rocket-0.png)\n\nTargeting trails, status placement and effect draw order also had fixes. The video uses chase, cockpit and wider views, and the XL camera handoffs and results view needed some stabilization work.\n\nThere was also work on preparing assets and keeping textures available on the GPU. Menus, inspection views and races use the shared lighting and effects; the [architecture page](https://projectable.me/projects/nullg/architecture/) explains how that fits together.\n\n## Split-screen\n\nI've changed the HUD layout to fit each player's viewport. The top readouts stay at the top, speed and thrust sit near the bottom, and status information stays around the edges. That leaves more of the road visible in both horizontal and vertical layouts.\n\n![Two-player split-screen with separate weapon and shield readouts](https://projectable.me/content/images/2026/10/169198aae575-nullg-weekly-fresh-split-hud.png)\n\n*Weapon, shield and lap states were staged here to check the two-player HUD layout.*\n\nHD2097 is used for the racing labels and large figures. Brighter numbers and colored labels distinguish the shield countdown, health, boost and thrust, while compact text keeps names and results readable in the smaller views. Targeting trails and weapon feedback stay with the relevant player's camera.\n\nThree-player mode now uses the spare quadrant for a circuit map and live standings, including lap and speed information. The numbered ship markers, legend and standings use the same colors for each local player.\n\n![Three player views with a map and standings in the fourth quadrant](https://projectable.me/content/images/2026/10/cf608e45de29-nullg-weekly-fresh-split-overview.png)\n\nFinished and retired racers have their own result states, with each driver's results kept inside their view. The [multiplayer page](https://projectable.me/projects/nullg/multiplayer/) covers the rest of the local and network setup.\n\n## A first Pulse race\n\nFor this update, the playable Pulse preview is **Talon's Junction White, FEISAR and Venom**. It goes through the normal import and menus into a one-lap Time Trial or a Single Race against seven native opponents, with difficulty selectable in Race Setup.\n\n![FEISAR with an active shield and HUD countdown on Talon's Junction White](https://projectable.me/content/images/2026/10/e14ca56845db-nullg-weekly-fresh-pulse-shield.png)\n\nGetting that combination running involved grid placement, the countdown and launch behavior, steering, airbrakes and the sideshift gesture. Banking and barrel-roll visuals are in, along with a chase camera that follows the track horizon and feedback for landings, wall contact and recovery.\n\nTime Trial gives you a Turbo at the start/lap line. It uses the normal weapon controls and common HUD, and can be absorbed for energy. Ship and track contact feed into the shared damage handling.\n\nPulse's Shield and three-shot Rocket bursts are connected to the models, rendering and HUD, though the weapon work is still incomplete. Tests covered shielded and unshielded encounters, and all eight racers completed a lap in the validation run. The weapon screenshots use inventory granted by the inspection tool.\n\n![Three Rocket darts ahead of FEISAR on Talon's Junction White](https://projectable.me/content/images/2026/10/9899d3185aba-nullg-weekly-fresh-pulse-rockets.png)\n\nPure is further back, at the import stage. The shared PSP work decodes geometry, materials, textures, collision and animation data while keeping each game's content separate. CPU loader checks cover **16 Pure track layouts and 24 Pulse layouts**, and the ship metadata covers **eleven Pure ships and eight Pulse ships**, including their dependent resources. Sound-bank voices and soundtrack resources have also been decoded and checked.\n\nThose numbers describe what the loaders can read, not a list of playable content. Pulse is the preview described above; Pure isn't at that point yet. The imports feed the existing model cache, staged GPU uploads and track streaming. Pulse imports are checked in a separate installation before being activated in the asset library.\n\n## Working with the inspection tools\n\nA lot of the model and weapon work is done with the engine paused. The MCP harnesses let an agent or script operate the native tools: load a model, position the camera, pose a control surface, inspect its state and save a frame.\n\nFor the fleet, that means going from Blender to the engine's Model Viewer, checking materials and movement, then checking the menus and a race. A control surface can look fine in Blender and still need a clearance adjustment when the engine applies steering or an airbrake.\n\n![Qirex in the Model Viewer with bounds and control-surface hierarchy visible](https://projectable.me/content/images/2026/10/e00793761eb9-nullg-weekly-fresh-mcp-qirex-surfaces.png)\n\nThe weapon harness starts a paused production race and grants a selected weapon. It can then advance the simulation a few frames at a time. A snapshot saved before firing allows the same setup to be restored, with ship state, timers and events available beside the pictures. The demonstration still goes through the game's firing and rendering paths.\n\nPulse now has a couple of useful feedback probes too. One starts the ship above the road with downward velocity and lets hover and collision produce the landing. Another moves it beyond the track so the recovery controller has to respond. The reports record the racer, time and magnitude of the resulting feedback, giving a repeatable case to inspect.\n\n![Track Validator showing geometry and texture inspection controls](https://projectable.me/content/images/2026/10/a43258e42685-nullg-weekly-fresh-mcp-track-inspection.png)\n\nThe replay tools let the camera work happen after the race is recorded. The saved inputs and reports make the captures repeatable, and the same race can be used for landscape and portrait edits. There's more on the harnesses on the [MCP tooling page](https://projectable.me/projects/nullg/mcp-tooling/).\n\nThe music work this week included playlist playback and track announcements, as well as **Zero G Chokehold**, **On Fire** and the **Warehouse Rage** track used in the video. NullG's original soundtrack is generated with Suno.\n\n*WipEout names, designs and imported game content belong to their respective owners. These images show that content and its reconstructed presentation in NullG.*","html":"\u003cp\u003eThis week\u0026#39;s \u003ca href=\"https://projectable.me/projects/nullg/\" rel=\"nofollow\"\u003eNullG\u003c/a\u003e work covered the five rebuilt XL ships, weapon effects, split-screen and the learning pilots. There\u0026#39;s also a first playable slice of WipEout Pulse. I\u0026#39;ve put the ships and all eleven XL weapon types into a new video:\u003c/p\u003e\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/2VYHD8xlsoM\" frameborder=\"0\" allowfullscreen=\"\"\u003e\u003c/iframe\u003e\n\u003ch2\u003eThe XL ships\u003c/h2\u003e\n\u003cp\u003eFEISAR, AG Systems, Auricom, Qirex and Piranha now have rebuilt geometry and physically based materials, with more detail around the cockpits, engines and moving control surfaces. The \u003ca href=\"https://projectable.me/nullg-recreating-wipeout-xl-models-in-blender/\" rel=\"nofollow\"\u003eBlender article\u003c/a\u003e covers how the models were reconstructed with the assistant and reviewed.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/0f9bf03cf410-nullg-weekly-fresh-fleet-a.png\" alt=\"FEISAR and AG Systems in the Model Viewer\"\u003e\n\u003cp\u003eA still render only tells part of the story with the moving parts. Qirex has a broad hull to clear when its surfaces move, while the thin surfaces on AG Systems and Piranha needed further refinement. This week\u0026#39;s changes included those clearance and thickness checks, then reviews under the menu and track lighting.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/a300c3095728-nullg-weekly-fresh-fleet-b.png\" alt=\"Auricom, Qirex and Piranha with their control surfaces posed\"\u003e\n\u003cp\u003eFor the racing footage I used the newest completed RL checkpoint available when capture preparation started on October 25. It was an experimental pace-training checkpoint on simulation revision 48, still unaccepted for gameplay. I wanted the video to show where the training had reached that day.\u003c/p\u003e\n\u003cp\u003eAll eight racers in each recorded field use the same saved policy, so continuing the training couldn’t change the driver halfway through recording. This week\u0026#39;s training work also covered difficulty objectives, rewards, checkpoint retention and resuming earlier runs. The \u003ca href=\"https://projectable.me/projects/nullg/reinforcement-learning/\" rel=\"nofollow\"\u003eRL page\u003c/a\u003e explains how the pilot produces steering, throttle, airbrake, pitch and weapon inputs.\u003c/p\u003e\n\u003ch2\u003eShields and weapons\u003c/h2\u003e\n\u003cp\u003eThe shield now has an animated surface around the hull, with the ship and engine flare visible through it. The close-up shows the surface moving while the ship stays visible underneath.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/ecc5894c0244-nullg-weekly-fresh-shield-closeup.png\" alt=\"Blue shield surrounding Qirex on Sagarmatha\"\u003e\n\u003cp\u003eFor the weapon shots I used controlled demonstrations with granted inventory. Rockets, missile and electrobolt show their launch, flight and impact; mines, quake, plasma and energy bomb show the larger track effects. Turbo, autopilot and the energy pack have their activation and status feedback too, making eleven types including the shield. The mine sequence also places a live mine to demonstrate the impact.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/e4a12b0e8f41-nullg-weekly-fresh-xl-rocket-0.png\" alt=\"Rockets leaving Qirex on Sagarmatha\"\u003e\n\u003cp\u003eTargeting trails, status placement and effect draw order also had fixes. The video uses chase, cockpit and wider views, and the XL camera handoffs and results view needed some stabilization work.\u003c/p\u003e\n\u003cp\u003eThere was also work on preparing assets and keeping textures available on the GPU. Menus, inspection views and races use the shared lighting and effects; the \u003ca href=\"https://projectable.me/projects/nullg/architecture/\" rel=\"nofollow\"\u003earchitecture page\u003c/a\u003e explains how that fits together.\u003c/p\u003e\n\u003ch2\u003eSplit-screen\u003c/h2\u003e\n\u003cp\u003eI\u0026#39;ve changed the HUD layout to fit each player\u0026#39;s viewport. The top readouts stay at the top, speed and thrust sit near the bottom, and status information stays around the edges. That leaves more of the road visible in both horizontal and vertical layouts.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/169198aae575-nullg-weekly-fresh-split-hud.png\" alt=\"Two-player split-screen with separate weapon and shield readouts\"\u003e\n\u003cp\u003e\u003cem\u003eWeapon, shield and lap states were staged here to check the two-player HUD layout.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eHD2097 is used for the racing labels and large figures. Brighter numbers and colored labels distinguish the shield countdown, health, boost and thrust, while compact text keeps names and results readable in the smaller views. Targeting trails and weapon feedback stay with the relevant player\u0026#39;s camera.\u003c/p\u003e\n\u003cp\u003eThree-player mode now uses the spare quadrant for a circuit map and live standings, including lap and speed information. The numbered ship markers, legend and standings use the same colors for each local player.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/cf608e45de29-nullg-weekly-fresh-split-overview.png\" alt=\"Three player views with a map and standings in the fourth quadrant\"\u003e\n\u003cp\u003eFinished and retired racers have their own result states, with each driver\u0026#39;s results kept inside their view. The \u003ca href=\"https://projectable.me/projects/nullg/multiplayer/\" rel=\"nofollow\"\u003emultiplayer page\u003c/a\u003e covers the rest of the local and network setup.\u003c/p\u003e\n\u003ch2\u003eA first Pulse race\u003c/h2\u003e\n\u003cp\u003eFor this update, the playable Pulse preview is \u003cstrong\u003eTalon\u0026#39;s Junction White, FEISAR and Venom\u003c/strong\u003e. It goes through the normal import and menus into a one-lap Time Trial or a Single Race against seven native opponents, with difficulty selectable in Race Setup.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/e14ca56845db-nullg-weekly-fresh-pulse-shield.png\" alt=\"FEISAR with an active shield and HUD countdown on Talon\u0026#39;s Junction White\"\u003e\n\u003cp\u003eGetting that combination running involved grid placement, the countdown and launch behavior, steering, airbrakes and the sideshift gesture. Banking and barrel-roll visuals are in, along with a chase camera that follows the track horizon and feedback for landings, wall contact and recovery.\u003c/p\u003e\n\u003cp\u003eTime Trial gives you a Turbo at the start/lap line. It uses the normal weapon controls and common HUD, and can be absorbed for energy. Ship and track contact feed into the shared damage handling.\u003c/p\u003e\n\u003cp\u003ePulse\u0026#39;s Shield and three-shot Rocket bursts are connected to the models, rendering and HUD, though the weapon work is still incomplete. Tests covered shielded and unshielded encounters, and all eight racers completed a lap in the validation run. The weapon screenshots use inventory granted by the inspection tool.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/9899d3185aba-nullg-weekly-fresh-pulse-rockets.png\" alt=\"Three Rocket darts ahead of FEISAR on Talon\u0026#39;s Junction White\"\u003e\n\u003cp\u003ePure is further back, at the import stage. The shared PSP work decodes geometry, materials, textures, collision and animation data while keeping each game\u0026#39;s content separate. CPU loader checks cover \u003cstrong\u003e16 Pure track layouts and 24 Pulse layouts\u003c/strong\u003e, and the ship metadata covers \u003cstrong\u003eeleven Pure ships and eight Pulse ships\u003c/strong\u003e, including their dependent resources. Sound-bank voices and soundtrack resources have also been decoded and checked.\u003c/p\u003e\n\u003cp\u003eThose numbers describe what the loaders can read, not a list of playable content. Pulse is the preview described above; Pure isn\u0026#39;t at that point yet. The imports feed the existing model cache, staged GPU uploads and track streaming. Pulse imports are checked in a separate installation before being activated in the asset library.\u003c/p\u003e\n\u003ch2\u003eWorking with the inspection tools\u003c/h2\u003e\n\u003cp\u003eA lot of the model and weapon work is done with the engine paused. The MCP harnesses let an agent or script operate the native tools: load a model, position the camera, pose a control surface, inspect its state and save a frame.\u003c/p\u003e\n\u003cp\u003eFor the fleet, that means going from Blender to the engine\u0026#39;s Model Viewer, checking materials and movement, then checking the menus and a race. A control surface can look fine in Blender and still need a clearance adjustment when the engine applies steering or an airbrake.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/e00793761eb9-nullg-weekly-fresh-mcp-qirex-surfaces.png\" alt=\"Qirex in the Model Viewer with bounds and control-surface hierarchy visible\"\u003e\n\u003cp\u003eThe weapon harness starts a paused production race and grants a selected weapon. It can then advance the simulation a few frames at a time. A snapshot saved before firing allows the same setup to be restored, with ship state, timers and events available beside the pictures. The demonstration still goes through the game\u0026#39;s firing and rendering paths.\u003c/p\u003e\n\u003cp\u003ePulse now has a couple of useful feedback probes too. One starts the ship above the road with downward velocity and lets hover and collision produce the landing. Another moves it beyond the track so the recovery controller has to respond. The reports record the racer, time and magnitude of the resulting feedback, giving a repeatable case to inspect.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/a43258e42685-nullg-weekly-fresh-mcp-track-inspection.png\" alt=\"Track Validator showing geometry and texture inspection controls\"\u003e\n\u003cp\u003eThe replay tools let the camera work happen after the race is recorded. The saved inputs and reports make the captures repeatable, and the same race can be used for landscape and portrait edits. There\u0026#39;s more on the harnesses on the \u003ca href=\"https://projectable.me/projects/nullg/mcp-tooling/\" rel=\"nofollow\"\u003eMCP tooling page\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eThe music work this week included playlist playback and track announcements, as well as \u003cstrong\u003eZero G Chokehold\u003c/strong\u003e, \u003cstrong\u003eOn Fire\u003c/strong\u003e and the \u003cstrong\u003eWarehouse Rage\u003c/strong\u003e track used in the video. NullG\u0026#39;s original soundtrack is generated with Suno.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eWipEout names, designs and imported game content belong to their respective owners. These images show that content and its reconstructed presentation in NullG.\u003c/em\u003e\u003c/p\u003e\n","excerpt":"I've been working on the rebuilt XL ships, shields, split-screen and learning pilots, plus the first playable Pulse preview and more PSP imports.","metaTitle":"NullG updates: the XL fleet, shields and a first Pulse race","metaDescription":"I've been working on the rebuilt XL ships, shields, split-screen and learning pilots, plus the first playable Pulse preview and more PSP imports.","status":"published","featured":false,"publishedAt":"2026-10-25T23:34:35Z","authorId":"190160de54f2192bd5b8734ec8808086","authorName":"Daniel Chote","authorSlug":"daniel","heroMediaId":"b6d17adfd043ab59aaf5a462247eea23","projectId":"ae4bdb66da6dc1729a263a475e1cdbe3","tags":[{"id":"10a974c0a281d4fcf3d44f5ef8dae079","name":"NullG","slug":"nullg"},{"id":"1c9e8a1339a8f8b797767e91a9673016","name":"Game","slug":"game"},{"id":"60103f47eb65b46c6138b9d6fc7b17d0","name":"Machine Learning","slug":"machine-learning"}],"createdAt":"2026-10-25T23:12:18Z","updatedAt":"2026-10-26T18:08:27Z"},{"id":"9f1711a950f76598b42e3b1fd15b45f0","siteId":"projectable","slug":"nullg-recreating-wipeout-xl-models-in-blender","title":"Recreating the WipEout XL fleet in Blender","markdown":"I've been working through the WipEout XL models for [NullG](https://projectable.me/projects/nullg/), starting with Feisar and then applying the same process to Qirex, Auricom, AG Systems and Piranha. All five have now been recreated in Blender, with inset cockpit glass, detailed engine housings, moving control surfaces and worn paint and graphics.\n\nThe smaller models have had a pass too: missiles, rockets, mines, the recovery drone, starting lights and track cameras. I've been directing the assistant through the Blender work, using the original geometry and textures as references and checking the results in the engine.\n\n## Starting with Feisar\n\nFeisar was the test for the process. The original XL model supplied the proportions, wing profiles, cockpit position, engine openings and texture placement. Front, rear, side, top and underside views made it possible to compare the rebuilt model against those references.\n\nThe new surfaces were built in Blender. Bevels give the edges some definition, the engines have recessed throats, and the panels and fairings have thickness. Those details need to hold up close, but the whole ship still needs to look like Feisar when it's moving away from the camera.\n\nI split the reviews into stages: shape first, then cockpit and engine details, paint and wear, moving parts, and finally the native rendering. This kept the feedback specific. A windshield corner could need a smaller radius, an emblem a cleaner outline, or a control surface a thinner profile, without reopening the entire model each time.\n\n## Connecting Blender\n\nBlender's community MCP integration lets the assistant inspect and edit the scene, then review the viewport. I use a dedicated Blender session with a saved revision to work from. Scripted recipes sit alongside that interactive access, making construction, material setup, export and comparison captures repeatable.\n\nThe editable work stays in a `.blend` file. The engine receives a self-contained GLB containing the meshes, materials, textures and named parts. That export is then imported into a clean Blender scene for another review, so the pictures show what was actually delivered, including the hierarchy, glass and embedded textures. Each revision has a number and recorded hash, so the comparison pictures can be traced back to the right model.\n\nThat means I can ask for a small correction and compare it from the same angle on the next pass.\n\n## Cockpits\n\nThe cockpit work came down to getting the glass, seals and recesses to agree on the shape of the opening. They now come from the same canopy outline, with a set frame margin and inset depth. Neighboring panes use shared alignment points, so changing one window doesn’t leave its surrounding parts out of place.\n\nFeisar has separate panes following its angular canopy. Auricom has forward glazing and a roof window within the red cockpit section. Piranha's side windows needed a refined profile, with an even orange surround and a flat lower edge. The geometry differs, but the relationships between glass, frame and opening are the same.\n\nThe same approach helped with vents following their supporting panels and lens rims meeting their housings. Much of the close-up work was making neighboring pieces actually meet.\n\n## The five ships\n\n**Feisar** established the material finish: lightly glossy paint, darker machinery, tinted glass and exposed alloy where the hull is scratched. The yellow nose has more contact wear, while the wings retain their blue color blocks. Its emblem is treated as a vinyl sticker over paint. A broader abrasion patch sits underneath toward the nose, where the hull might brush the road.\n\n![Feisar model, cockpit, engine and underside](https://projectable.me/content/images/2026/10/459d0ad8b8c6-nullg-blender-feisar.png)\n\n**Qirex** has a very different shape to work around. The long purple sides frame the cockpit, and the mechanical texture continues across the rear and into the engine. The repeated slots in the emblem use consistent dimensions. Most of the wear sits on the exposed outer surfaces.\n\n![Qirex model, cockpit, engine and underside](https://projectable.me/content/images/2026/10/050f3aa28f05-nullg-blender-qirex.png)\n\n**Auricom** uses red, blue and dark panels, with the front vents following the windshield contour at a consistent margin. Its star artwork needed clean edges, and the engine texture coverage needed checking from the rear as well as the front.\n\n![Auricom model, cockpit, engine and underside](https://projectable.me/content/images/2026/10/158781f9576f-nullg-blender-auricom.png)\n\n**AG Systems** keeps the red-and-white divisions and lettering clear. The vents beside the cockpit follow the panels they sit on, and the rear control surfaces have a thin profile to suit the wings. Wear is concentrated on the exposed areas rather than obscuring the main graphics.\n\n![AG Systems model, cockpit, engine and underside](https://projectable.me/content/images/2026/10/7b3dc657056f-nullg-blender-ag_systems.png)\n\n**Piranha** has warm red wings and a continuous orange canopy section. The crown-like rear motif and long diamond cutouts were reconstructed with clean outlines. The paint carries around the glazing and across adjoining faces, while the engine and rear-wing finish follows the individual components.\n\n![Piranha model, cockpit, engine and underside](https://projectable.me/content/images/2026/10/da4669288dff-nullg-blender-piranha.png)\n\n## Paint, stickers and wear\n\nI wanted the wear to have a reason for being where it was. Leading edges get directional scuffs, selected seams get blended abrasion, and the engine housings and service areas carry more grime. Large areas of paint remain intact.\n\nThe two sides have independent wear placement. Separate masks handle paint abrasion, damaged stickers, engine grime and exposed metal. A chip in a vinyl graphic reveals paint; a deeper hull scratch reveals alloy. The recovery drone also has some oxidation on its older trackside surfaces.\n\nBase color carries the paint and markings. Roughness controls the reflections, metallic values pick out exposed alloy, and normal maps provide shallow seams, rivets and fasteners. The underside and machinery are rougher than the painted upper surfaces. Ship texture masters stay at 4K, with runtime tiers prepared separately.\n\nLettering uses the appropriate game font where available, including XL/2097 lettering on the drone. Logos and cutouts have their own tracing and spacing checks; wear can't fix an incorrect outline.\n\n## Weapons and trackside models\n\nThe weapons have small geometry budgets. The missile is **352 triangles**, the rocket **294**, and the mine **48**. Their shape and colors come from XL, with Pulse used as a secondary reference for mechanical detail. Most of the extra detail comes from the materials, reserving geometry for the outline.\n\n![Low-poly missile, rocket and mine Blender renders](https://projectable.me/content/images/2026/10/6bf9b9d401b7-nullg-blender-weapons.png)\n\n![Animated native mine model review](https://projectable.me/content/images/2026/10/c05ec115e332-nullg-blender-mine-animation.png)\n\nThe recovery drone has **638 triangles**, with worn grey panels, rivets, continuous hazard stripes and a centered warning label at the rear. Its front and rear lamps are modeled, with glass and striped surfaces giving the lights some depth.\n\n![Recovery drone panel, lamp, lettering and underside details](https://projectable.me/content/images/2026/10/e52fe78331da-nullg-blender-drone.png)\n\n![Animated rear lights on the recovery drone](https://projectable.me/content/images/2026/10/5bcccb6c1d7f-nullg-blender-drone-animation.png)\n\nThe starting-light assembly is **308 triangles**. The frame has edge wear and grime, and the recessed glass carries a fine line pattern. Running the sequence in the harness makes it possible to check the lamps and their housing together.\n\n![Animated XL starting-light sequence](https://projectable.me/content/images/2026/10/da33d7093b39-nullg-blender-start-animation.png)\n\nTrack cameras use the same grey panels and yellow-and-black stripes, with recessed optics. The flared lens surrounds and inner bevels needed another adjustment so they met the recesses properly. The replacements were then checked across all six XL tracks that contain them, retaining the original placement and animation.\n\n![Track camera lens, top panel and rear housing details](https://projectable.me/content/images/2026/10/947bb5416a02-nullg-blender-camera.png)\n\n## Checking the moving parts\n\nOnce the GLB is in NullG, the [model viewers and MCP harnesses](https://projectable.me/projects/nullg/mcp-tooling/) provide camera presets, material views and controlled poses. Applying steering and each airbrake moves the control surfaces. Close-ups around hinges and pockets show whether there's enough clearance.\n\nThe exhaust needs checking in the same way. An engine opening can look correct on its own while the plume starts in the wrong place, or a moving surface crosses it. The harness checks the flare and trail attachment locations against the model.\n\n![All five XL ships with blue engine flares, straight and curved exhaust trails, and control-surface poses](https://projectable.me/content/images/2026/10/f22de3d95342-fleet-exhaust-current.png)\n\n*Straight exhaust trails on the left; curved trails with steering and left airbrake applied on the right.*\n\nThe shield adds another check on scale and transparency. Its envelope is authored in Blender, while the runtime shader supplies the flowing plasma. This view shows both around Feisar, with the ship still visible through the effect.\n\n![Animated blue plasma shield surrounding Feisar](https://projectable.me/content/images/2026/10/3f2525adca53-nullg-blender-shield-animation.png)\n\nThe final checks are in the menus and on track. Bright sections, tunnels and shadows each reveal different problems with paint, metal, glass and normal-map detail. Scale and attachment checks keep the replacement models connected to the existing racing behavior. The [architecture overview](https://projectable.me/projects/nullg/architecture/) describes the rendering and simulation systems behind those scenes.\n\n![Five modern XL ships in the pre-game menus](https://projectable.me/content/images/2026/10/f81af4e3c125-fleet-menu-current.png)\n\n![Feisar gameplay captures in varied track lighting](https://projectable.me/content/images/2026/10/491b2039f780-nullg-blender-lighting.png)\n\nThe Blender files and game exports are saved for all five ships and the smaller objects. Being able to ask for a narrower window frame, a better-fitting lens or a thinner moving part, then compare the same view again, has made those small corrections much easier to review.\n","html":"\u003cp\u003eI\u0026#39;ve been working through the WipEout XL models for \u003ca href=\"https://projectable.me/projects/nullg/\" rel=\"nofollow\"\u003eNullG\u003c/a\u003e, starting with Feisar and then applying the same process to Qirex, Auricom, AG Systems and Piranha. All five have now been recreated in Blender, with inset cockpit glass, detailed engine housings, moving control surfaces and worn paint and graphics.\u003c/p\u003e\n\u003cp\u003eThe smaller models have had a pass too: missiles, rockets, mines, the recovery drone, starting lights and track cameras. I\u0026#39;ve been directing the assistant through the Blender work, using the original geometry and textures as references and checking the results in the engine.\u003c/p\u003e\n\u003ch2\u003eStarting with Feisar\u003c/h2\u003e\n\u003cp\u003eFeisar was the test for the process. The original XL model supplied the proportions, wing profiles, cockpit position, engine openings and texture placement. Front, rear, side, top and underside views made it possible to compare the rebuilt model against those references.\u003c/p\u003e\n\u003cp\u003eThe new surfaces were built in Blender. Bevels give the edges some definition, the engines have recessed throats, and the panels and fairings have thickness. Those details need to hold up close, but the whole ship still needs to look like Feisar when it\u0026#39;s moving away from the camera.\u003c/p\u003e\n\u003cp\u003eI split the reviews into stages: shape first, then cockpit and engine details, paint and wear, moving parts, and finally the native rendering. This kept the feedback specific. A windshield corner could need a smaller radius, an emblem a cleaner outline, or a control surface a thinner profile, without reopening the entire model each time.\u003c/p\u003e\n\u003ch2\u003eConnecting Blender\u003c/h2\u003e\n\u003cp\u003eBlender\u0026#39;s community MCP integration lets the assistant inspect and edit the scene, then review the viewport. I use a dedicated Blender session with a saved revision to work from. Scripted recipes sit alongside that interactive access, making construction, material setup, export and comparison captures repeatable.\u003c/p\u003e\n\u003cp\u003eThe editable work stays in a \u003ccode\u003e.blend\u003c/code\u003e file. The engine receives a self-contained GLB containing the meshes, materials, textures and named parts. That export is then imported into a clean Blender scene for another review, so the pictures show what was actually delivered, including the hierarchy, glass and embedded textures. Each revision has a number and recorded hash, so the comparison pictures can be traced back to the right model.\u003c/p\u003e\n\u003cp\u003eThat means I can ask for a small correction and compare it from the same angle on the next pass.\u003c/p\u003e\n\u003ch2\u003eCockpits\u003c/h2\u003e\n\u003cp\u003eThe cockpit work came down to getting the glass, seals and recesses to agree on the shape of the opening. They now come from the same canopy outline, with a set frame margin and inset depth. Neighboring panes use shared alignment points, so changing one window doesn’t leave its surrounding parts out of place.\u003c/p\u003e\n\u003cp\u003eFeisar has separate panes following its angular canopy. Auricom has forward glazing and a roof window within the red cockpit section. Piranha\u0026#39;s side windows needed a refined profile, with an even orange surround and a flat lower edge. The geometry differs, but the relationships between glass, frame and opening are the same.\u003c/p\u003e\n\u003cp\u003eThe same approach helped with vents following their supporting panels and lens rims meeting their housings. Much of the close-up work was making neighboring pieces actually meet.\u003c/p\u003e\n\u003ch2\u003eThe five ships\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eFeisar\u003c/strong\u003e established the material finish: lightly glossy paint, darker machinery, tinted glass and exposed alloy where the hull is scratched. The yellow nose has more contact wear, while the wings retain their blue color blocks. Its emblem is treated as a vinyl sticker over paint. A broader abrasion patch sits underneath toward the nose, where the hull might brush the road.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/459d0ad8b8c6-nullg-blender-feisar.png\" alt=\"Feisar model, cockpit, engine and underside\"\u003e\n\u003cp\u003e\u003cstrong\u003eQirex\u003c/strong\u003e has a very different shape to work around. The long purple sides frame the cockpit, and the mechanical texture continues across the rear and into the engine. The repeated slots in the emblem use consistent dimensions. Most of the wear sits on the exposed outer surfaces.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/050f3aa28f05-nullg-blender-qirex.png\" alt=\"Qirex model, cockpit, engine and underside\"\u003e\n\u003cp\u003e\u003cstrong\u003eAuricom\u003c/strong\u003e uses red, blue and dark panels, with the front vents following the windshield contour at a consistent margin. Its star artwork needed clean edges, and the engine texture coverage needed checking from the rear as well as the front.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/158781f9576f-nullg-blender-auricom.png\" alt=\"Auricom model, cockpit, engine and underside\"\u003e\n\u003cp\u003e\u003cstrong\u003eAG Systems\u003c/strong\u003e keeps the red-and-white divisions and lettering clear. The vents beside the cockpit follow the panels they sit on, and the rear control surfaces have a thin profile to suit the wings. Wear is concentrated on the exposed areas rather than obscuring the main graphics.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/7b3dc657056f-nullg-blender-ag_systems.png\" alt=\"AG Systems model, cockpit, engine and underside\"\u003e\n\u003cp\u003e\u003cstrong\u003ePiranha\u003c/strong\u003e has warm red wings and a continuous orange canopy section. The crown-like rear motif and long diamond cutouts were reconstructed with clean outlines. The paint carries around the glazing and across adjoining faces, while the engine and rear-wing finish follows the individual components.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/da4669288dff-nullg-blender-piranha.png\" alt=\"Piranha model, cockpit, engine and underside\"\u003e\n\u003ch2\u003ePaint, stickers and wear\u003c/h2\u003e\n\u003cp\u003eI wanted the wear to have a reason for being where it was. Leading edges get directional scuffs, selected seams get blended abrasion, and the engine housings and service areas carry more grime. Large areas of paint remain intact.\u003c/p\u003e\n\u003cp\u003eThe two sides have independent wear placement. Separate masks handle paint abrasion, damaged stickers, engine grime and exposed metal. A chip in a vinyl graphic reveals paint; a deeper hull scratch reveals alloy. The recovery drone also has some oxidation on its older trackside surfaces.\u003c/p\u003e\n\u003cp\u003eBase color carries the paint and markings. Roughness controls the reflections, metallic values pick out exposed alloy, and normal maps provide shallow seams, rivets and fasteners. The underside and machinery are rougher than the painted upper surfaces. Ship texture masters stay at 4K, with runtime tiers prepared separately.\u003c/p\u003e\n\u003cp\u003eLettering uses the appropriate game font where available, including XL/2097 lettering on the drone. Logos and cutouts have their own tracing and spacing checks; wear can\u0026#39;t fix an incorrect outline.\u003c/p\u003e\n\u003ch2\u003eWeapons and trackside models\u003c/h2\u003e\n\u003cp\u003eThe weapons have small geometry budgets. The missile is \u003cstrong\u003e352 triangles\u003c/strong\u003e, the rocket \u003cstrong\u003e294\u003c/strong\u003e, and the mine \u003cstrong\u003e48\u003c/strong\u003e. Their shape and colors come from XL, with Pulse used as a secondary reference for mechanical detail. Most of the extra detail comes from the materials, reserving geometry for the outline.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/6bf9b9d401b7-nullg-blender-weapons.png\" alt=\"Low-poly missile, rocket and mine Blender renders\"\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/c05ec115e332-nullg-blender-mine-animation.png\" alt=\"Animated native mine model review\"\u003e\n\u003cp\u003eThe recovery drone has \u003cstrong\u003e638 triangles\u003c/strong\u003e, with worn grey panels, rivets, continuous hazard stripes and a centered warning label at the rear. Its front and rear lamps are modeled, with glass and striped surfaces giving the lights some depth.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/e52fe78331da-nullg-blender-drone.png\" alt=\"Recovery drone panel, lamp, lettering and underside details\"\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/5bcccb6c1d7f-nullg-blender-drone-animation.png\" alt=\"Animated rear lights on the recovery drone\"\u003e\n\u003cp\u003eThe starting-light assembly is \u003cstrong\u003e308 triangles\u003c/strong\u003e. The frame has edge wear and grime, and the recessed glass carries a fine line pattern. Running the sequence in the harness makes it possible to check the lamps and their housing together.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/da33d7093b39-nullg-blender-start-animation.png\" alt=\"Animated XL starting-light sequence\"\u003e\n\u003cp\u003eTrack cameras use the same grey panels and yellow-and-black stripes, with recessed optics. The flared lens surrounds and inner bevels needed another adjustment so they met the recesses properly. The replacements were then checked across all six XL tracks that contain them, retaining the original placement and animation.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/947bb5416a02-nullg-blender-camera.png\" alt=\"Track camera lens, top panel and rear housing details\"\u003e\n\u003ch2\u003eChecking the moving parts\u003c/h2\u003e\n\u003cp\u003eOnce the GLB is in NullG, the \u003ca href=\"https://projectable.me/projects/nullg/mcp-tooling/\" rel=\"nofollow\"\u003emodel viewers and MCP harnesses\u003c/a\u003e provide camera presets, material views and controlled poses. Applying steering and each airbrake moves the control surfaces. Close-ups around hinges and pockets show whether there\u0026#39;s enough clearance.\u003c/p\u003e\n\u003cp\u003eThe exhaust needs checking in the same way. An engine opening can look correct on its own while the plume starts in the wrong place, or a moving surface crosses it. The harness checks the flare and trail attachment locations against the model.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/f22de3d95342-fleet-exhaust-current.png\" alt=\"All five XL ships with blue engine flares, straight and curved exhaust trails, and control-surface poses\"\u003e\n\u003cp\u003e\u003cem\u003eStraight exhaust trails on the left; curved trails with steering and left airbrake applied on the right.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eThe shield adds another check on scale and transparency. Its envelope is authored in Blender, while the runtime shader supplies the flowing plasma. This view shows both around Feisar, with the ship still visible through the effect.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/3f2525adca53-nullg-blender-shield-animation.png\" alt=\"Animated blue plasma shield surrounding Feisar\"\u003e\n\u003cp\u003eThe final checks are in the menus and on track. Bright sections, tunnels and shadows each reveal different problems with paint, metal, glass and normal-map detail. Scale and attachment checks keep the replacement models connected to the existing racing behavior. The \u003ca href=\"https://projectable.me/projects/nullg/architecture/\" rel=\"nofollow\"\u003earchitecture overview\u003c/a\u003e describes the rendering and simulation systems behind those scenes.\u003c/p\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/f81af4e3c125-fleet-menu-current.png\" alt=\"Five modern XL ships in the pre-game menus\"\u003e\n\u003cimg src=\"https://projectable.me/content/images/2026/10/491b2039f780-nullg-blender-lighting.png\" alt=\"Feisar gameplay captures in varied track lighting\"\u003e\n\u003cp\u003eThe Blender files and game exports are saved for all five ships and the smaller objects. Being able to ask for a narrower window frame, a better-fitting lens or a thinner moving part, then compare the same view again, has made those small corrections much easier to review.\u003c/p\u003e\n","excerpt":"How I used Blender and the assistant to rebuild the five XL ships, weapons and trackside models, then check their materials and movement in NullG.","metaTitle":"Recreating the WipEout XL fleet in Blender","metaDescription":"How I used Blender and the assistant to rebuild the five XL ships, weapons and trackside models, then check their materials and movement in NullG.","status":"published","featured":false,"publishedAt":"2026-10-25T14:05:33Z","authorId":"190160de54f2192bd5b8734ec8808086","authorName":"Daniel Chote","authorSlug":"daniel","heroMediaId":"ec095655019808e4dac9f18d8ff4eb75","projectId":"ae4bdb66da6dc1729a263a475e1cdbe3","tags":[{"id":"1c9e8a1339a8f8b797767e91a9673016","name":"Game","slug":"game"},{"id":"10a974c0a281d4fcf3d44f5ef8dae079","name":"NullG","slug":"nullg"}],"createdAt":"2026-10-25T13:58:21Z","updatedAt":"2026-10-26T18:09:38Z"},{"id":"59ab1e54b3a5386e6900ca8678d4e839","siteId":"projectable","slug":"nullg-reinforcement-learning-journey","title":"Teaching NullG pilots to drive and use weapons","markdown":"I've been working on getting a learned pilot to race in [NullG](https://projectable.me/projects/nullg/). It trains against the native simulation, exports into a model the game can run, and uses the same controls as a player. The latest work is on weapons: keeping the driving it has already learned while training it to use what it picks up.\n\nGetting a ship around a circuit is only part of this. The pilot also has to deal with traffic, pickups, Turbo and the consequences of firing a weapon. Changes that help one part can upset another, so a lot of the work between training runs has been figuring out what actually changed and replaying it on other tracks.\n\nThe [YouTube playlist](https://www.youtube.com/playlist?list=PLaR-_mRLlb6E) has the driving and combat recordings. This is the longer account of how the training works and what the latest results mean.\n\n## Connecting the pilot to the game\n\nPython communicates with isolated native workers, each running NullG's C++ race simulation with its physics, pickups, weapons and rules. Gymnasium supplies the environment interface, with PyTorch and [Stable-Baselines3 PPO](https://stable-baselines3.readthedocs.io/en/master/modules/ppo.html) handling the main training implementation.\n\nThe policy is the network that turns observations into controls. During training, a second network, the critic, estimates the return expected from a state. PPO collects experience with the current policy and makes bounded updates to those networks.\n\nThe pilot gets structured information about motion, health, the connected road ahead, nearby racers, pickups, visible projectiles, inventory and previous controls. That makes the observation design quite concrete: how much road can it see, how is sideways motion represented, and what happens to those measurements at a section boundary?\n\nIt produces throttle, analog steering, left and right airbrakes, pitch and weapon commands at **30 Hz**. These pass through the normal player-input path. The session advances at **60 Hz**, with the selected source physics cadence; movement is held between decisions and weapon commands follow the engine's input timing.\n\nThe trained actor exports to a compact `.ngpolicy` package. A native C++ evaluator then produces the controls in the game, without Python in that runtime path. The package records which observations and configuration the model expects, along with its identity, so it can be checked against the training setup.\n\n![Title view from a NullG reinforcement-learning evaluation replay](/content/images/2026/10/b1b8220f350c-nullg-rl-full-title-preview.png)\n\n*An evaluation race rendered by the cinematic replay exporter. The driving policy and camera director are separate systems.*\n\n## Useful references\n\nThere is plenty of existing racing RL work to learn from. I've used different projects for different parts of this, adapting the ideas to an anti-gravity racer and NullG's own simulation.\n\n[Sony AI's account of training Gran Turismo Sophy](https://ai.sony/blog/how-to-train-your-race-car) is useful for thinking about the practice a driver needs: solo driving, traffic and specialized situations. That informs the mix of circuits, opponents and difficult starting states used here.\n\n[TMRL](https://github.com/trackmania-rl/tmrl) covers real-time control, observation histories, analog actions and off-policy learning in TrackMania. It helped motivate a controlled SAC steering comparison alongside PPO. [Linesight](https://linesight-rl.github.io/linesight/build/html/main_objects.html), another TrackMania project, uses IQN and explicit reference-line geometry. Its handling of progress and training coverage is useful even though NullG's integration is different. [Learn-to-Race](https://github.com/learn-to-race/l2r) provides an autonomous-racing environment and baselines for comparing conventional and learned controllers against a defined task.\n\n[CAPS](https://ai.bu.edu/caps/) informed the smooth-control studies, including looking at action variation and the frequency content of motion. [NeuralKart](https://github.com/rameshvarun/NeuralKart) provided a reference for searching for useful driving actions and learning from them. NullG does that search from native snapshots of states reached by its own learner. [DAgger](https://proceedings.mlr.press/v15/ross11a.html) explains why collecting corrections in those states matters: the learner's previous decisions determine where it ends up needing help.\n\n## The observations and steering\n\nOnce the basic loop worked, the next job was checking what information actually reached the network. That meant auditing scaling, feature connections, road preview and the steering adapter.\n\nA value can be present in an observation and still be nearly useless after normalization and clipping. The corrected observations use explicit physical scales and identity normalization, which leaves those scaled values unchanged. Checks also trace features all the way to the network inputs, so adding a field isn't mistaken for successfully teaching the model about it.\n\nThe road observations now include forward directions, heading error, longitudinal and lateral velocity, displacement across the road, curvature and clearance. Connected-road projection supplies a continuous position through section boundaries and qualified junctions. Progress rewards use distance along the road and only count new ground beyond the previous furthest point. Pickups and boost pads make limited contributions.\n\nThe XL input adapter now provides **513 signed positions** for analog steering. That made it possible to compare observation designs while keeping the control protocol and experience budget fixed. A separate PPO-versus-SAC study used the same restricted auxiliary controls. These smaller comparisons helped isolate decisions before asking the full driver to do more.\n\n## What happens between training runs\n\nBetween October 15 and 20, the work repeatedly went from recorded races and telemetry to a focused change, then back through evaluation. Simply turning up a steering-change penalty wasn't enough. It could make sampled actions quieter, so the checks also looked at the policy's mean output and the ship's actual heading and lateral movement. Longer road preview and different brake commitment were tested separately.\n\nExploration adds another complication. The actions sampled during training can behave differently from deterministic native inference, so both need checking. The exported driver is the one that eventually has to race.\n\nA steering update changes the trajectory from which Turbo is fired, even when the weapon weights stay fixed. States with naturally earned Turbo were added to the comparisons and examples used to preserve existing behaviour. Speed alone isn't enough to judge the result; health, recovery and what happens over the rest of the race matter too.\n\nFor corrective driving, the tools save a native state reached by the learner and try small steering interventions from that exact point. Accepted examples become labels for training, with unchanged actions retained as anchors. Work on Gare d'Europa and Odessa Keys added longer follow-through checks and preservation samples from the other circuits.\n\nTrying a correction involves quite a few steps: restore the state, check that the original run replays correctly, try alternative inputs, train a limited update, export it and run complete races. A turn can look better for a few seconds and still lead to trouble further down the road, so the follow-through checks were extended.\n\nThree completed combat jobs—the eight-hour run on October 18, the four-hour run on October 19 and the latest four-hour continuation—account for **more than 16 hours of training wall time**. They branch from selected earlier checkpoints, so that isn't sixteen continuous hours on one policy. Short comparisons, earlier driving work, evaluations and corrective searches are additional work. That total doesn't include reading, reviewing footage or changing the tools; there isn't a combined time counter for those.\n\n## Adding combat\n\nFor combat, I kept the actor's driving features and movement outputs frozen while training the weapon outputs and critic. Weight checks verify that the protected parameters stay unchanged. Full races are still necessary, because a new weapon decision can change the situation the driver has to deal with.\n\nFinishing position matters most in the reward, with limited extra credit for effective combat and useful pickups or pads. Firing more shots doesn't earn a bonus by itself.\n\nThe experiments covered longer credit assignment, combat reward weighting and critic calibration. Calibration fits the value estimate to returns collected from the retained policy without changing the actor. For extra practice, a race can start from a saved state where the driver had reached an opponent while carrying an offensive weapon. Those chances can be sparse in a normal race.\n\nThe latest configuration mixes ordinary races with **ten-second combat opportunity windows**. These start from verified native states and collect fresh actions from the current policy. The end of a practice window isn't counted as finishing or being eliminated from a race.\n\nThe opponents include original XL drivers, a retained learned challenger and mixed fields. The training rotation uses Talon's Reach, Sagarmatha, Gare d'Europa and Odessa Keys.\n\n## The latest four-hour run\n\nThis continuation started from the earlier combat run's hour-two checkpoint. Four CPU workers added **6,639,616 decisions**, taking that checkpoint lineage from **32,651,264 to 39,290,880**. Other experiments have their own experience counts.\n\nThe run retained the driving parameters and trained the weapon outputs and critic, using gamma **1.0**, GAE lambda **0.95**, combat reward scale **1.0** and **300-decision** opportunity windows. Hourly saves allowed intermediate checkpoints to be compared with the final one.\n\nThe review covered six policies, each with 48 standard evaluation races, plus cross-play and confirmation panels. [RLiable's evaluation guidance](https://research.google/blog/rliable-towards-reliable-evaluation-reporting-in-reinforcement-learning/) is useful here: paired conditions, several seeds and the distribution of outcomes give more information than a single good race.\n\nThe final checkpoint **won 18 of 48 races and finished 31** in the standard panel. In the additional 24-race confirmation panel, it **won 9 and finished 15**. The intermediate checkpoints had different strengths; the last save wasn't simply better at everything.\n\n![Gare d'Europa race from the final combat-training checkpoint](/content/images/2026/10/b1e12503f058-nullg-rl-full-preview.png)\n\n## The recordings\n\nThe learned pilot is in slot 0 in the latest full race. The automatic cameras move around the field, so every ship shown in a close-up isn't necessarily that pilot.\n\n### Gare d'Europa, complete race\n\nThis is the three-lap race from the final checkpoint of the four-hour continuation. It runs for about three minutes, with native race audio and cinematic cameras.\n\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/__kpDHYbsCg\" frameborder=\"0\" allowfullscreen\u003e\u003c/iframe\u003e\n\n[Watch the full Gare d'Europa race on YouTube](https://youtu.be/__kpDHYbsCg).\n\n### Racing and combat Short\n\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/lTbLUj1QKt4\" frameborder=\"0\" allowfullscreen\u003e\u003c/iframe\u003e\n\n[Watch the racing and combat Short](https://youtu.be/lTbLUj1QKt4).\n\n### Earlier training: update 3\n\nThe earlier upload, “NullG - 8 hour AI driving training 3 (reinforcement learning)”, shows another point in the driving work.\n\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/fkUTwW2p_8k\" frameborder=\"0\" allowfullscreen\u003e\u003c/iframe\u003e\n\n[Watch training update 3](https://youtu.be/fkUTwW2p_8k).\n\n### Earlier training: update 2\n\nThe preceding upload is “NullG - 8 hour AI driving training 2 (reinforcement learning)”.\n\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/9ddeaoyyIY4\" frameborder=\"0\" allowfullscreen\u003e\u003c/iframe\u003e\n\n[Watch training update 2](https://youtu.be/9ddeaoyyIY4).\n\nThe next experiments will build on these comparisons, working on weapon decisions while checking that the driving still holds up across the four circuits. The [reinforcement-learning page](https://projectable.me/projects/nullg/reinforcement-learning/) has more detail on the engine integration.\n","html":"\u003cp\u003eI\u0026#39;ve been working on getting a learned pilot to race in \u003ca href=\"https://projectable.me/projects/nullg/\" rel=\"nofollow\"\u003eNullG\u003c/a\u003e. It trains against the native simulation, exports into a model the game can run, and uses the same controls as a player. The latest work is on weapons: keeping the driving it has already learned while training it to use what it picks up.\u003c/p\u003e\n\u003cp\u003eGetting a ship around a circuit is only part of this. The pilot also has to deal with traffic, pickups, Turbo and the consequences of firing a weapon. Changes that help one part can upset another, so a lot of the work between training runs has been figuring out what actually changed and replaying it on other tracks.\u003c/p\u003e\n\u003cp\u003eThe \u003ca href=\"https://www.youtube.com/playlist?list=PLaR-_mRLlb6E\" rel=\"nofollow\"\u003eYouTube playlist\u003c/a\u003e has the driving and combat recordings. This is the longer account of how the training works and what the latest results mean.\u003c/p\u003e\n\u003ch2\u003eConnecting the pilot to the game\u003c/h2\u003e\n\u003cp\u003ePython communicates with isolated native workers, each running NullG\u0026#39;s C++ race simulation with its physics, pickups, weapons and rules. Gymnasium supplies the environment interface, with PyTorch and \u003ca href=\"https://stable-baselines3.readthedocs.io/en/master/modules/ppo.html\" rel=\"nofollow\"\u003eStable-Baselines3 PPO\u003c/a\u003e handling the main training implementation.\u003c/p\u003e\n\u003cp\u003eThe policy is the network that turns observations into controls. During training, a second network, the critic, estimates the return expected from a state. PPO collects experience with the current policy and makes bounded updates to those networks.\u003c/p\u003e\n\u003cp\u003eThe pilot gets structured information about motion, health, the connected road ahead, nearby racers, pickups, visible projectiles, inventory and previous controls. That makes the observation design quite concrete: how much road can it see, how is sideways motion represented, and what happens to those measurements at a section boundary?\u003c/p\u003e\n\u003cp\u003eIt produces throttle, analog steering, left and right airbrakes, pitch and weapon commands at \u003cstrong\u003e30 Hz\u003c/strong\u003e. These pass through the normal player-input path. The session advances at \u003cstrong\u003e60 Hz\u003c/strong\u003e, with the selected source physics cadence; movement is held between decisions and weapon commands follow the engine\u0026#39;s input timing.\u003c/p\u003e\n\u003cp\u003eThe trained actor exports to a compact \u003ccode\u003e.ngpolicy\u003c/code\u003e package. A native C++ evaluator then produces the controls in the game, without Python in that runtime path. The package records which observations and configuration the model expects, along with its identity, so it can be checked against the training setup.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/b1b8220f350c-nullg-rl-full-title-preview.png\" alt=\"Title view from a NullG reinforcement-learning evaluation replay\"\u003e\n\u003cp\u003e\u003cem\u003eAn evaluation race rendered by the cinematic replay exporter. The driving policy and camera director are separate systems.\u003c/em\u003e\u003c/p\u003e\n\u003ch2\u003eUseful references\u003c/h2\u003e\n\u003cp\u003eThere is plenty of existing racing RL work to learn from. I\u0026#39;ve used different projects for different parts of this, adapting the ideas to an anti-gravity racer and NullG\u0026#39;s own simulation.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://ai.sony/blog/how-to-train-your-race-car\" rel=\"nofollow\"\u003eSony AI\u0026#39;s account of training Gran Turismo Sophy\u003c/a\u003e is useful for thinking about the practice a driver needs: solo driving, traffic and specialized situations. That informs the mix of circuits, opponents and difficult starting states used here.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://github.com/trackmania-rl/tmrl\" rel=\"nofollow\"\u003eTMRL\u003c/a\u003e covers real-time control, observation histories, analog actions and off-policy learning in TrackMania. It helped motivate a controlled SAC steering comparison alongside PPO. \u003ca href=\"https://linesight-rl.github.io/linesight/build/html/main_objects.html\" rel=\"nofollow\"\u003eLinesight\u003c/a\u003e, another TrackMania project, uses IQN and explicit reference-line geometry. Its handling of progress and training coverage is useful even though NullG\u0026#39;s integration is different. \u003ca href=\"https://github.com/learn-to-race/l2r\" rel=\"nofollow\"\u003eLearn-to-Race\u003c/a\u003e provides an autonomous-racing environment and baselines for comparing conventional and learned controllers against a defined task.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://ai.bu.edu/caps/\" rel=\"nofollow\"\u003eCAPS\u003c/a\u003e informed the smooth-control studies, including looking at action variation and the frequency content of motion. \u003ca href=\"https://github.com/rameshvarun/NeuralKart\" rel=\"nofollow\"\u003eNeuralKart\u003c/a\u003e provided a reference for searching for useful driving actions and learning from them. NullG does that search from native snapshots of states reached by its own learner. \u003ca href=\"https://proceedings.mlr.press/v15/ross11a.html\" rel=\"nofollow\"\u003eDAgger\u003c/a\u003e explains why collecting corrections in those states matters: the learner\u0026#39;s previous decisions determine where it ends up needing help.\u003c/p\u003e\n\u003ch2\u003eThe observations and steering\u003c/h2\u003e\n\u003cp\u003eOnce the basic loop worked, the next job was checking what information actually reached the network. That meant auditing scaling, feature connections, road preview and the steering adapter.\u003c/p\u003e\n\u003cp\u003eA value can be present in an observation and still be nearly useless after normalization and clipping. The corrected observations use explicit physical scales and identity normalization, which leaves those scaled values unchanged. Checks also trace features all the way to the network inputs, so adding a field isn\u0026#39;t mistaken for successfully teaching the model about it.\u003c/p\u003e\n\u003cp\u003eThe road observations now include forward directions, heading error, longitudinal and lateral velocity, displacement across the road, curvature and clearance. Connected-road projection supplies a continuous position through section boundaries and qualified junctions. Progress rewards use distance along the road and only count new ground beyond the previous furthest point. Pickups and boost pads make limited contributions.\u003c/p\u003e\n\u003cp\u003eThe XL input adapter now provides \u003cstrong\u003e513 signed positions\u003c/strong\u003e for analog steering. That made it possible to compare observation designs while keeping the control protocol and experience budget fixed. A separate PPO-versus-SAC study used the same restricted auxiliary controls. These smaller comparisons helped isolate decisions before asking the full driver to do more.\u003c/p\u003e\n\u003ch2\u003eWhat happens between training runs\u003c/h2\u003e\n\u003cp\u003eBetween October 15 and 20, the work repeatedly went from recorded races and telemetry to a focused change, then back through evaluation. Simply turning up a steering-change penalty wasn\u0026#39;t enough. It could make sampled actions quieter, so the checks also looked at the policy\u0026#39;s mean output and the ship\u0026#39;s actual heading and lateral movement. Longer road preview and different brake commitment were tested separately.\u003c/p\u003e\n\u003cp\u003eExploration adds another complication. The actions sampled during training can behave differently from deterministic native inference, so both need checking. The exported driver is the one that eventually has to race.\u003c/p\u003e\n\u003cp\u003eA steering update changes the trajectory from which Turbo is fired, even when the weapon weights stay fixed. States with naturally earned Turbo were added to the comparisons and examples used to preserve existing behaviour. Speed alone isn\u0026#39;t enough to judge the result; health, recovery and what happens over the rest of the race matter too.\u003c/p\u003e\n\u003cp\u003eFor corrective driving, the tools save a native state reached by the learner and try small steering interventions from that exact point. Accepted examples become labels for training, with unchanged actions retained as anchors. Work on Gare d\u0026#39;Europa and Odessa Keys added longer follow-through checks and preservation samples from the other circuits.\u003c/p\u003e\n\u003cp\u003eTrying a correction involves quite a few steps: restore the state, check that the original run replays correctly, try alternative inputs, train a limited update, export it and run complete races. A turn can look better for a few seconds and still lead to trouble further down the road, so the follow-through checks were extended.\u003c/p\u003e\n\u003cp\u003eThree completed combat jobs—the eight-hour run on October 18, the four-hour run on October 19 and the latest four-hour continuation—account for \u003cstrong\u003emore than 16 hours of training wall time\u003c/strong\u003e. They branch from selected earlier checkpoints, so that isn\u0026#39;t sixteen continuous hours on one policy. Short comparisons, earlier driving work, evaluations and corrective searches are additional work. That total doesn\u0026#39;t include reading, reviewing footage or changing the tools; there isn\u0026#39;t a combined time counter for those.\u003c/p\u003e\n\u003ch2\u003eAdding combat\u003c/h2\u003e\n\u003cp\u003eFor combat, I kept the actor\u0026#39;s driving features and movement outputs frozen while training the weapon outputs and critic. Weight checks verify that the protected parameters stay unchanged. Full races are still necessary, because a new weapon decision can change the situation the driver has to deal with.\u003c/p\u003e\n\u003cp\u003eFinishing position matters most in the reward, with limited extra credit for effective combat and useful pickups or pads. Firing more shots doesn\u0026#39;t earn a bonus by itself.\u003c/p\u003e\n\u003cp\u003eThe experiments covered longer credit assignment, combat reward weighting and critic calibration. Calibration fits the value estimate to returns collected from the retained policy without changing the actor. For extra practice, a race can start from a saved state where the driver had reached an opponent while carrying an offensive weapon. Those chances can be sparse in a normal race.\u003c/p\u003e\n\u003cp\u003eThe latest configuration mixes ordinary races with \u003cstrong\u003eten-second combat opportunity windows\u003c/strong\u003e. These start from verified native states and collect fresh actions from the current policy. The end of a practice window isn\u0026#39;t counted as finishing or being eliminated from a race.\u003c/p\u003e\n\u003cp\u003eThe opponents include original XL drivers, a retained learned challenger and mixed fields. The training rotation uses Talon\u0026#39;s Reach, Sagarmatha, Gare d\u0026#39;Europa and Odessa Keys.\u003c/p\u003e\n\u003ch2\u003eThe latest four-hour run\u003c/h2\u003e\n\u003cp\u003eThis continuation started from the earlier combat run\u0026#39;s hour-two checkpoint. Four CPU workers added \u003cstrong\u003e6,639,616 decisions\u003c/strong\u003e, taking that checkpoint lineage from \u003cstrong\u003e32,651,264 to 39,290,880\u003c/strong\u003e. Other experiments have their own experience counts.\u003c/p\u003e\n\u003cp\u003eThe run retained the driving parameters and trained the weapon outputs and critic, using gamma \u003cstrong\u003e1.0\u003c/strong\u003e, GAE lambda \u003cstrong\u003e0.95\u003c/strong\u003e, combat reward scale \u003cstrong\u003e1.0\u003c/strong\u003e and \u003cstrong\u003e300-decision\u003c/strong\u003e opportunity windows. Hourly saves allowed intermediate checkpoints to be compared with the final one.\u003c/p\u003e\n\u003cp\u003eThe review covered six policies, each with 48 standard evaluation races, plus cross-play and confirmation panels. \u003ca href=\"https://research.google/blog/rliable-towards-reliable-evaluation-reporting-in-reinforcement-learning/\" rel=\"nofollow\"\u003eRLiable\u0026#39;s evaluation guidance\u003c/a\u003e is useful here: paired conditions, several seeds and the distribution of outcomes give more information than a single good race.\u003c/p\u003e\n\u003cp\u003eThe final checkpoint \u003cstrong\u003ewon 18 of 48 races and finished 31\u003c/strong\u003e in the standard panel. In the additional 24-race confirmation panel, it \u003cstrong\u003ewon 9 and finished 15\u003c/strong\u003e. The intermediate checkpoints had different strengths; the last save wasn\u0026#39;t simply better at everything.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/b1e12503f058-nullg-rl-full-preview.png\" alt=\"Gare d\u0026#39;Europa race from the final combat-training checkpoint\"\u003e\n\u003ch2\u003eThe recordings\u003c/h2\u003e\n\u003cp\u003eThe learned pilot is in slot 0 in the latest full race. The automatic cameras move around the field, so every ship shown in a close-up isn\u0026#39;t necessarily that pilot.\u003c/p\u003e\n\u003ch3\u003eGare d\u0026#39;Europa, complete race\u003c/h3\u003e\n\u003cp\u003eThis is the three-lap race from the final checkpoint of the four-hour continuation. It runs for about three minutes, with native race audio and cinematic cameras.\u003c/p\u003e\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/__kpDHYbsCg\" frameborder=\"0\" allowfullscreen=\"\"\u003e\u003c/iframe\u003e\n\u003cp\u003e\u003ca href=\"https://youtu.be/__kpDHYbsCg\" rel=\"nofollow\"\u003eWatch the full Gare d\u0026#39;Europa race on YouTube\u003c/a\u003e.\u003c/p\u003e\n\u003ch3\u003eRacing and combat Short\u003c/h3\u003e\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/lTbLUj1QKt4\" frameborder=\"0\" allowfullscreen=\"\"\u003e\u003c/iframe\u003e\n\u003cp\u003e\u003ca href=\"https://youtu.be/lTbLUj1QKt4\" rel=\"nofollow\"\u003eWatch the racing and combat Short\u003c/a\u003e.\u003c/p\u003e\n\u003ch3\u003eEarlier training: update 3\u003c/h3\u003e\n\u003cp\u003eThe earlier upload, “NullG - 8 hour AI driving training 3 (reinforcement learning)”, shows another point in the driving work.\u003c/p\u003e\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/fkUTwW2p_8k\" frameborder=\"0\" allowfullscreen=\"\"\u003e\u003c/iframe\u003e\n\u003cp\u003e\u003ca href=\"https://youtu.be/fkUTwW2p_8k\" rel=\"nofollow\"\u003eWatch training update 3\u003c/a\u003e.\u003c/p\u003e\n\u003ch3\u003eEarlier training: update 2\u003c/h3\u003e\n\u003cp\u003eThe preceding upload is “NullG - 8 hour AI driving training 2 (reinforcement learning)”.\u003c/p\u003e\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/9ddeaoyyIY4\" frameborder=\"0\" allowfullscreen=\"\"\u003e\u003c/iframe\u003e\n\u003cp\u003e\u003ca href=\"https://youtu.be/9ddeaoyyIY4\" rel=\"nofollow\"\u003eWatch training update 2\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eThe next experiments will build on these comparisons, working on weapon decisions while checking that the driving still holds up across the four circuits. The \u003ca href=\"https://projectable.me/projects/nullg/reinforcement-learning/\" rel=\"nofollow\"\u003ereinforcement-learning page\u003c/a\u003e has more detail on the engine integration.\u003c/p\u003e\n","excerpt":"What changed in NullG's pilot training, from steering and Turbo to weapons, and what the latest four-hour combat run managed.","metaTitle":"Teaching NullG pilots to drive and use weapons","metaDescription":"What changed in NullG's pilot training, from steering and Turbo to weapons, and what the latest four-hour combat run managed.","status":"published","featured":false,"publishedAt":"2026-10-20T13:21:42Z","authorId":"190160de54f2192bd5b8734ec8808086","authorName":"Daniel Chote","authorSlug":"daniel","heroMediaId":"2de6b37e96d56188d9b74019123198cd","projectId":"ae4bdb66da6dc1729a263a475e1cdbe3","tags":[{"id":"10a974c0a281d4fcf3d44f5ef8dae079","name":"NullG","slug":"nullg"},{"id":"1c9e8a1339a8f8b797767e91a9673016","name":"Game","slug":"game"},{"id":"60103f47eb65b46c6138b9d6fc7b17d0","name":"Machine Learning","slug":"machine-learning"}],"createdAt":"2026-10-20T13:10:40Z","updatedAt":"2026-10-26T18:09:37Z"},{"id":"7b367212a739706ba4e3e9b999bec15d","siteId":"projectable","slug":"introducing-nullg-anti-gravity-racing-and-ai","title":"Introducing NullG","markdown":"I've been building an anti-gravity racing engine called [NullG](https://projectable.me/projects/nullg/). It's written in C++20 with Vulkan rendering, and currently combines imported game assets with racing physics, weapons, multiplayer and replay tools.\n\nThe longer-term idea is a motion simulator pod, with acceleration, braking, cornering and impacts driving physical movement. Positional audio and multiple displays are part of that plan. My [Car-cade](https://projectable.me/my-dirt-rally-tabletop-car-cade-game/) and [motion rig](https://projectable.me/sim-racing-motion-rig-v2-updates/) explored the hardware side of racing; this time I'm working on the engine that would feed it.\n\nDevelopment started in January 2026 with AI-assisted planning and implementation. I've used coding agents throughout, with a large part of the work going into the references, constraints and tools they need to make changes that can actually be inspected and tested.\n\n![Original NullG ship artwork](/content/images/2026/10/583bdbe059a6-ship.png)\n\n## Getting started\n\nThe first git commit was on January 22. It contained the outline, research files, architecture notes and initial application code: a window, Vulkan setup, input, configuration and logging. The plans already included asset conversion, audio, networking, computer-controlled opponents and motion output.\n\nI put the race simulation at the center of the design. Graphics and sound consume its state, and the eventual motion hardware would read from the same data. That kept the simulator idea part of the engine rather than something to bolt on after the rendering worked.\n\nEarly development used Cursor, with commands for planning, preparation and review. Preparation meant reading the relevant references and tracing the code before making changes. Smaller tasks, examples and written decisions gave the next session something useful to start from.\n\n![Early NullG team-selection screen with FEISAR selected](/content/images/2026/10/037075fac8ed-G_jZiq3WQAAg2Cz.jpeg)\n\nAsset conversion and the first renderer pass arrived on January 23. Menus, model loading, asset management and track parsing followed over the next few days. Existing WipEout research and community projects supplied references for the ships, tracks, textures and scenery.\n\nBy February 8, NullG could load PlayStation assets directly. That work covered track geometry, scene objects, sprites and texture transparency. With those pieces in the renderer, the imported data could finally be compared with what appeared on screen. The file-format notes and agent rules grew alongside the loaders.\n\n## Getting a race working\n\nMarch was more about how the ship moved: hover height, coasting, weight, jumps, boost, recovery and tunnel-wall collisions. There was also work on scenery placement, skies, pickups, boost pads and the track camera behind the menus.\n\nLighting, shadows and GPU particles were added to the presentation. By March 6, the code included race-session flow and a weapon system, including getting into a race and back to the menus. The changes were handled as individual tasks with code review and updated notes, rather than expecting one session to keep the whole engine in context.\n\nIn May I split the original engine plan into focused documents with a shared status index. Renderer work covered dynamic rendering, geometry access, material organization and moving runtime shaders to Slang. Animated scene lights, illuminated pickups, shields and scenery shadows on ships received attention too.\n\nAn entity/component scene system and render snapshots were added during that period. A render snapshot holds the data needed for a frame, including ship and object positions, so the renderer has a consistent state to draw.\n\nBy May 28 there were headless tests for the job system, memory and asset handling. Agents could run them after an edit and read the results. The inspection tools grew from there.\n\nJune brought Jolt collision integration and more GPU effects work. Research notes on effects, shadows and physics kept established examples available for implementation tasks. On June 9, XL became the default asset source. Each source supplied the information the menus needed to show its available choices. Waterfall texture scrolling and the starting-grid camera were among the other changes.\n\nThe next concentrated stretch started on October 9, bringing the agent guidance into Codex, adding native engine inspectors and establishing the fixed 60 Hz race setup. Multiplayer followed on October 10, with more XL reconstruction work on October 11.\n\n## Letting the agent inspect the result\n\nIn October I switched NullG's coding-agent work exclusively to OpenAI Codex. The planning commands, rules and research notes came across from Cursor. The next step was giving Codex access to the engine tools it needed to check its own work.\n\nI'd recently watched videos about Blender MCP showing an agent working directly with a scene and inspecting the result. That helped shape both the model-authoring process and the decision to connect agents to NullG's native tools.\n\n[MCP, the Model Context Protocol](https://modelcontextprotocol.io/introduction), connects AI applications to external tools and data. In NullG it exposes inspection windows, track validators, model viewers and controlled race sessions. The agent can load a track, pick a camera, inspect geometry and save a frame. For a model, it can look at materials, bounds and different angles.\n\n![NullG Track Validator showing track geometry, texture inspection, and timeline controls](/content/images/2026/10/nullg/intro-track-inspection.png)\n\nThe weapon harness opens a paused production race. It lets the agent deploy a weapon and advance a few frames at a time, then inspect a projectile, impact or Quake effect at a particular moment. The simulation state is available beside the picture.\n\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/pbUzB3j74p8\" frameborder=\"0\" allowfullscreen\u003e\u003c/iframe\u003e\n\n*Reactive engine plumes in the MCP harness.*\n\nFor a weapon-effect fix, the process is to set up the scene, fire the weapon, step through it and follow the responsible code. After an edit, the agent builds the affected code and repeats the same case. Reports keep the inputs and settings so another session can reproduce it.\n\nThe different checks answer different questions. Physics tests compare movement with expected values; track checks look at road geometry. Replaying the same inputs helps find changes in behaviour. I still need to review appearance and handling, but the agent can do more of the setup and leave the reports and captures for me to inspect.\n\n![Ships racing with engine trails and a weapon effect in NullG](/content/images/2026/10/nullg/nullg-ships-weapon-action.png)\n\n![Diagram showing an agent connected through MCP to native inspection and headless validation tools](/content/images/2026/10/nullg/intro-agent-workflow.png)\n\n## Reconstructing XL behavior\n\nOctober's research went further into WipEout XL / 2097 steering, weapon updates, starting positions and animated objects.\n\n[REA, Reverse Engineer Anything](https://github.com/morluto/rea), was part of that setup, connecting agents to tools for investigating applications and binaries. The PlayStation executable decompilation used a PSX-aware Ghidra workflow. Scripts saved the instructions, references, annotations and findings so the investigation could be picked up again.\n\nStarting-grid placement is a useful example. Following the original track numbering and route links established where the ships should start. Those findings became checks against the imported track, and the inspector could show the selected position on the road.\n\n![An overhead track inspection with a highlighted grid marker](/content/images/2026/10/nullg/intro-grid-placement.png)\n\nThe research covers USA and European editions, retaining the edition and executable details with each finding. A timing value from one build shouldn't quietly become a claim about every version.\n\nThe recovered calculations and state changes are first turned into small C++ reference models and tests, then integrated into NullG. The notes keep track of what came from the executable, what was adapted, and what was observed in the engine. Players supply their own game files; I'm developing original NullG content separately.\n\n## Other reconstruction projects\n\nThis was happening while agent-assisted software reconstruction was getting much more attention. [Coverage of REA's growth](https://www.onfirstlaunch.com/blog/reverse-engineer-anything-rea-explained) described the interest around demonstrations of agents inspecting applications and reproducing their behavior.\n\n[ArtCraft's projects](https://github.com/storytold) include photo, video and PDF tools, with [WordCraft](https://github.com/storytold/wordcraft), [GridCraft](https://github.com/storytold/gridcraft) and [DeckCraft](https://github.com/storytold/deckcraft) targeting Word, Excel and PowerPoint-style work. [October coverage](https://www.techradar.com/computing/office-suites/developer-who-vibe-coded-free-adobe-clones-reveals-apps-to-take-down-microsoft-office-next-and-says-there-is-no-reason-to-save-broken-software) connected those AI-assisted projects with interest in alternatives to Adobe and Microsoft software.\n\nThe work is similar in one respect: study how something behaves, implement it, then check whether it matches. With racing behaviour, that means taking the executable research into tests and the native inspectors.\n\n## Blender models\n\nThe first concrete use of those Blender MCP ideas was preparing original menu models. The assistant could inspect the scene, edit individual parts, export a candidate and produce comparison views in the same task.\n\nThe process starts with visual references and generated models where useful, followed by a Blender finishing pass. That covers shape, individual parts, surface cleanup, materials and polygon count. Saved revisions and repeatable exports make it possible to change one part and compare it with the previous version.\n\n![Four Blender review renders of the original monitor-shaped Graphics menu model](/content/images/2026/10/nullg/intro-blender-graphics-model.png)\n\nThe model is then checked in NullG's Model Viewer and menus at its intended size. The source files, exports and comparison images are saved for each revision. A Blender viewport is useful, but the asset still has to work under the engine's lighting and at the size a player will see it.\n\n## Recording races\n\nNullG can record a race, replay it with cinematic cameras and export video with titles and audio. The camera can follow a ship or cut to action elsewhere in the field. Landscape, portrait and square output cover the longer videos and shorter clips.\n\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/tREm0SM8zmg\" frameborder=\"0\" allowfullscreen\u003e\u003c/iframe\u003e\n\n*The XL cinematic race intro.*\n\nThe screenshot tools cover menus, starting grids, tracks and weapon effects too. Agents can select and organize the captures with their settings and source details. A recorded race can be reviewed first, then used for footage in an update.\n\n## Learning pilots\n\nThere are two different uses of AI here. The development agent works on code and tools; the learned pilot is a model selecting controls during a race.\n\nThe pilot gets information about speed and direction, road geometry ahead, nearby ships and pickups. It selects throttle, steering, airbrakes, pitch and weapon commands, which enter the simulation as player-style inputs.\n\nTraining uses Python, Gymnasium, Stable-Baselines3 and PyTorch, with PPO as the learning algorithm. Native workers run NullG's race simulation, allowing several driving attempts in parallel while training updates the model.\n\n![RL evaluation replay on Gare d'Europa](/content/images/2026/10/nullg/intro-rl-city-race.png)\n\nA short run checks the setup and controls. Longer runs save checkpoints for evaluation on selected tracks and race configurations. Settings and seeds are retained so the checks can be repeated.\n\nThe evaluations measure completion, time, damage and steering smoothness. Traffic and combat runs also look at placing, pickups and weapon timing. A checkpoint is just a saved stage of training; it still needs evaluation before being approved for gameplay.\n\nReplays help explain the numbers. A chase view shows the ship working through a corner, while an overhead view shows the surrounding traffic. Both can be compared with the controls and metrics recorded during the race.\n\n![Overhead RL evaluation replay with colored racer markers](/content/images/2026/10/nullg/intro-rl-overhead.png)\n\nThe exported pilot runs in native C++, with Python handling the training. Saved checkpoints can be compared using the same race setup, and agents can run those comparisons and prepare the replays for review.\n\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/fkUTwW2p_8k\" frameborder=\"0\" allowfullscreen\u003e\u003c/iframe\u003e\n\n*An AI-driving training clip from the NullG playlist.*\n\nThe [reinforcement-learning page](https://projectable.me/projects/nullg/reinforcement-learning/) covers the training integration, and the [MCP tooling page](https://projectable.me/projects/nullg/mcp-tooling/) describes the inspection tools.\n\n## Keeping the project updated\n\nI'm also using the agent-assisted workflow for projectable.me. The agent starts with git history, project documentation and relevant captures, prepares an illustrated article and saves a draft. I can then review and edit it on the site before publication. This post was prepared that way, using repository history for the timeline and existing engine captures for the images.\n\nThere’s now a playable racer underneath all this tooling: weapons, computer-controlled opponents, local split-screen, LAN and private online rooms.\n\n![Two-player vertical split-screen racing with WipEout XL content in NullG](/content/images/2026/10/nullg/intro-xl-splitscreen.png)\n\nOriginal ships and tracks, sound, and handling for gamepad and simulator use remain part of the longer-term work. Motion output, positional audio and multiple displays are still part of the pod plan.\n\nThe [project pages](https://projectable.me/projects/nullg/) have the engine details, the [video playlist](https://www.youtube.com/playlist?list=PLaR-_mRLlb6E) has development footage, and further updates are collected in the [project blog](https://projectable.me/projects/nullg/blog/).\n","html":"\u003cp\u003eI\u0026#39;ve been building an anti-gravity racing engine called \u003ca href=\"https://projectable.me/projects/nullg/\" rel=\"nofollow\"\u003eNullG\u003c/a\u003e. It\u0026#39;s written in C++20 with Vulkan rendering, and currently combines imported game assets with racing physics, weapons, multiplayer and replay tools.\u003c/p\u003e\n\u003cp\u003eThe longer-term idea is a motion simulator pod, with acceleration, braking, cornering and impacts driving physical movement. Positional audio and multiple displays are part of that plan. My \u003ca href=\"https://projectable.me/my-dirt-rally-tabletop-car-cade-game/\" rel=\"nofollow\"\u003eCar-cade\u003c/a\u003e and \u003ca href=\"https://projectable.me/sim-racing-motion-rig-v2-updates/\" rel=\"nofollow\"\u003emotion rig\u003c/a\u003e explored the hardware side of racing; this time I\u0026#39;m working on the engine that would feed it.\u003c/p\u003e\n\u003cp\u003eDevelopment started in January 2026 with AI-assisted planning and implementation. I\u0026#39;ve used coding agents throughout, with a large part of the work going into the references, constraints and tools they need to make changes that can actually be inspected and tested.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/583bdbe059a6-ship.png\" alt=\"Original NullG ship artwork\"\u003e\n\u003ch2\u003eGetting started\u003c/h2\u003e\n\u003cp\u003eThe first git commit was on January 22. It contained the outline, research files, architecture notes and initial application code: a window, Vulkan setup, input, configuration and logging. The plans already included asset conversion, audio, networking, computer-controlled opponents and motion output.\u003c/p\u003e\n\u003cp\u003eI put the race simulation at the center of the design. Graphics and sound consume its state, and the eventual motion hardware would read from the same data. That kept the simulator idea part of the engine rather than something to bolt on after the rendering worked.\u003c/p\u003e\n\u003cp\u003eEarly development used Cursor, with commands for planning, preparation and review. Preparation meant reading the relevant references and tracing the code before making changes. Smaller tasks, examples and written decisions gave the next session something useful to start from.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/037075fac8ed-G_jZiq3WQAAg2Cz.jpeg\" alt=\"Early NullG team-selection screen with FEISAR selected\"\u003e\n\u003cp\u003eAsset conversion and the first renderer pass arrived on January 23. Menus, model loading, asset management and track parsing followed over the next few days. Existing WipEout research and community projects supplied references for the ships, tracks, textures and scenery.\u003c/p\u003e\n\u003cp\u003eBy February 8, NullG could load PlayStation assets directly. That work covered track geometry, scene objects, sprites and texture transparency. With those pieces in the renderer, the imported data could finally be compared with what appeared on screen. The file-format notes and agent rules grew alongside the loaders.\u003c/p\u003e\n\u003ch2\u003eGetting a race working\u003c/h2\u003e\n\u003cp\u003eMarch was more about how the ship moved: hover height, coasting, weight, jumps, boost, recovery and tunnel-wall collisions. There was also work on scenery placement, skies, pickups, boost pads and the track camera behind the menus.\u003c/p\u003e\n\u003cp\u003eLighting, shadows and GPU particles were added to the presentation. By March 6, the code included race-session flow and a weapon system, including getting into a race and back to the menus. The changes were handled as individual tasks with code review and updated notes, rather than expecting one session to keep the whole engine in context.\u003c/p\u003e\n\u003cp\u003eIn May I split the original engine plan into focused documents with a shared status index. Renderer work covered dynamic rendering, geometry access, material organization and moving runtime shaders to Slang. Animated scene lights, illuminated pickups, shields and scenery shadows on ships received attention too.\u003c/p\u003e\n\u003cp\u003eAn entity/component scene system and render snapshots were added during that period. A render snapshot holds the data needed for a frame, including ship and object positions, so the renderer has a consistent state to draw.\u003c/p\u003e\n\u003cp\u003eBy May 28 there were headless tests for the job system, memory and asset handling. Agents could run them after an edit and read the results. The inspection tools grew from there.\u003c/p\u003e\n\u003cp\u003eJune brought Jolt collision integration and more GPU effects work. Research notes on effects, shadows and physics kept established examples available for implementation tasks. On June 9, XL became the default asset source. Each source supplied the information the menus needed to show its available choices. Waterfall texture scrolling and the starting-grid camera were among the other changes.\u003c/p\u003e\n\u003cp\u003eThe next concentrated stretch started on October 9, bringing the agent guidance into Codex, adding native engine inspectors and establishing the fixed 60 Hz race setup. Multiplayer followed on October 10, with more XL reconstruction work on October 11.\u003c/p\u003e\n\u003ch2\u003eLetting the agent inspect the result\u003c/h2\u003e\n\u003cp\u003eIn October I switched NullG\u0026#39;s coding-agent work exclusively to OpenAI Codex. The planning commands, rules and research notes came across from Cursor. The next step was giving Codex access to the engine tools it needed to check its own work.\u003c/p\u003e\n\u003cp\u003eI\u0026#39;d recently watched videos about Blender MCP showing an agent working directly with a scene and inspecting the result. That helped shape both the model-authoring process and the decision to connect agents to NullG\u0026#39;s native tools.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://modelcontextprotocol.io/introduction\" rel=\"nofollow\"\u003eMCP, the Model Context Protocol\u003c/a\u003e, connects AI applications to external tools and data. In NullG it exposes inspection windows, track validators, model viewers and controlled race sessions. The agent can load a track, pick a camera, inspect geometry and save a frame. For a model, it can look at materials, bounds and different angles.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/nullg/intro-track-inspection.png\" alt=\"NullG Track Validator showing track geometry, texture inspection, and timeline controls\"\u003e\n\u003cp\u003eThe weapon harness opens a paused production race. It lets the agent deploy a weapon and advance a few frames at a time, then inspect a projectile, impact or Quake effect at a particular moment. The simulation state is available beside the picture.\u003c/p\u003e\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/pbUzB3j74p8\" frameborder=\"0\" allowfullscreen=\"\"\u003e\u003c/iframe\u003e\n\u003cp\u003e\u003cem\u003eReactive engine plumes in the MCP harness.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eFor a weapon-effect fix, the process is to set up the scene, fire the weapon, step through it and follow the responsible code. After an edit, the agent builds the affected code and repeats the same case. Reports keep the inputs and settings so another session can reproduce it.\u003c/p\u003e\n\u003cp\u003eThe different checks answer different questions. Physics tests compare movement with expected values; track checks look at road geometry. Replaying the same inputs helps find changes in behaviour. I still need to review appearance and handling, but the agent can do more of the setup and leave the reports and captures for me to inspect.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/nullg/nullg-ships-weapon-action.png\" alt=\"Ships racing with engine trails and a weapon effect in NullG\"\u003e\n\u003cimg src=\"/content/images/2026/10/nullg/intro-agent-workflow.png\" alt=\"Diagram showing an agent connected through MCP to native inspection and headless validation tools\"\u003e\n\u003ch2\u003eReconstructing XL behavior\u003c/h2\u003e\n\u003cp\u003eOctober\u0026#39;s research went further into WipEout XL / 2097 steering, weapon updates, starting positions and animated objects.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://github.com/morluto/rea\" rel=\"nofollow\"\u003eREA, Reverse Engineer Anything\u003c/a\u003e, was part of that setup, connecting agents to tools for investigating applications and binaries. The PlayStation executable decompilation used a PSX-aware Ghidra workflow. Scripts saved the instructions, references, annotations and findings so the investigation could be picked up again.\u003c/p\u003e\n\u003cp\u003eStarting-grid placement is a useful example. Following the original track numbering and route links established where the ships should start. Those findings became checks against the imported track, and the inspector could show the selected position on the road.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/nullg/intro-grid-placement.png\" alt=\"An overhead track inspection with a highlighted grid marker\"\u003e\n\u003cp\u003eThe research covers USA and European editions, retaining the edition and executable details with each finding. A timing value from one build shouldn\u0026#39;t quietly become a claim about every version.\u003c/p\u003e\n\u003cp\u003eThe recovered calculations and state changes are first turned into small C++ reference models and tests, then integrated into NullG. The notes keep track of what came from the executable, what was adapted, and what was observed in the engine. Players supply their own game files; I\u0026#39;m developing original NullG content separately.\u003c/p\u003e\n\u003ch2\u003eOther reconstruction projects\u003c/h2\u003e\n\u003cp\u003eThis was happening while agent-assisted software reconstruction was getting much more attention. \u003ca href=\"https://www.onfirstlaunch.com/blog/reverse-engineer-anything-rea-explained\" rel=\"nofollow\"\u003eCoverage of REA\u0026#39;s growth\u003c/a\u003e described the interest around demonstrations of agents inspecting applications and reproducing their behavior.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://github.com/storytold\" rel=\"nofollow\"\u003eArtCraft\u0026#39;s projects\u003c/a\u003e include photo, video and PDF tools, with \u003ca href=\"https://github.com/storytold/wordcraft\" rel=\"nofollow\"\u003eWordCraft\u003c/a\u003e, \u003ca href=\"https://github.com/storytold/gridcraft\" rel=\"nofollow\"\u003eGridCraft\u003c/a\u003e and \u003ca href=\"https://github.com/storytold/deckcraft\" rel=\"nofollow\"\u003eDeckCraft\u003c/a\u003e targeting Word, Excel and PowerPoint-style work. \u003ca href=\"https://www.techradar.com/computing/office-suites/developer-who-vibe-coded-free-adobe-clones-reveals-apps-to-take-down-microsoft-office-next-and-says-there-is-no-reason-to-save-broken-software\" rel=\"nofollow\"\u003eOctober coverage\u003c/a\u003e connected those AI-assisted projects with interest in alternatives to Adobe and Microsoft software.\u003c/p\u003e\n\u003cp\u003eThe work is similar in one respect: study how something behaves, implement it, then check whether it matches. With racing behaviour, that means taking the executable research into tests and the native inspectors.\u003c/p\u003e\n\u003ch2\u003eBlender models\u003c/h2\u003e\n\u003cp\u003eThe first concrete use of those Blender MCP ideas was preparing original menu models. The assistant could inspect the scene, edit individual parts, export a candidate and produce comparison views in the same task.\u003c/p\u003e\n\u003cp\u003eThe process starts with visual references and generated models where useful, followed by a Blender finishing pass. That covers shape, individual parts, surface cleanup, materials and polygon count. Saved revisions and repeatable exports make it possible to change one part and compare it with the previous version.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/nullg/intro-blender-graphics-model.png\" alt=\"Four Blender review renders of the original monitor-shaped Graphics menu model\"\u003e\n\u003cp\u003eThe model is then checked in NullG\u0026#39;s Model Viewer and menus at its intended size. The source files, exports and comparison images are saved for each revision. A Blender viewport is useful, but the asset still has to work under the engine\u0026#39;s lighting and at the size a player will see it.\u003c/p\u003e\n\u003ch2\u003eRecording races\u003c/h2\u003e\n\u003cp\u003eNullG can record a race, replay it with cinematic cameras and export video with titles and audio. The camera can follow a ship or cut to action elsewhere in the field. Landscape, portrait and square output cover the longer videos and shorter clips.\u003c/p\u003e\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/tREm0SM8zmg\" frameborder=\"0\" allowfullscreen=\"\"\u003e\u003c/iframe\u003e\n\u003cp\u003e\u003cem\u003eThe XL cinematic race intro.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eThe screenshot tools cover menus, starting grids, tracks and weapon effects too. Agents can select and organize the captures with their settings and source details. A recorded race can be reviewed first, then used for footage in an update.\u003c/p\u003e\n\u003ch2\u003eLearning pilots\u003c/h2\u003e\n\u003cp\u003eThere are two different uses of AI here. The development agent works on code and tools; the learned pilot is a model selecting controls during a race.\u003c/p\u003e\n\u003cp\u003eThe pilot gets information about speed and direction, road geometry ahead, nearby ships and pickups. It selects throttle, steering, airbrakes, pitch and weapon commands, which enter the simulation as player-style inputs.\u003c/p\u003e\n\u003cp\u003eTraining uses Python, Gymnasium, Stable-Baselines3 and PyTorch, with PPO as the learning algorithm. Native workers run NullG\u0026#39;s race simulation, allowing several driving attempts in parallel while training updates the model.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/nullg/intro-rl-city-race.png\" alt=\"RL evaluation replay on Gare d\u0026#39;Europa\"\u003e\n\u003cp\u003eA short run checks the setup and controls. Longer runs save checkpoints for evaluation on selected tracks and race configurations. Settings and seeds are retained so the checks can be repeated.\u003c/p\u003e\n\u003cp\u003eThe evaluations measure completion, time, damage and steering smoothness. Traffic and combat runs also look at placing, pickups and weapon timing. A checkpoint is just a saved stage of training; it still needs evaluation before being approved for gameplay.\u003c/p\u003e\n\u003cp\u003eReplays help explain the numbers. A chase view shows the ship working through a corner, while an overhead view shows the surrounding traffic. Both can be compared with the controls and metrics recorded during the race.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/nullg/intro-rl-overhead.png\" alt=\"Overhead RL evaluation replay with colored racer markers\"\u003e\n\u003cp\u003eThe exported pilot runs in native C++, with Python handling the training. Saved checkpoints can be compared using the same race setup, and agents can run those comparisons and prepare the replays for review.\u003c/p\u003e\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/fkUTwW2p_8k\" frameborder=\"0\" allowfullscreen=\"\"\u003e\u003c/iframe\u003e\n\u003cp\u003e\u003cem\u003eAn AI-driving training clip from the NullG playlist.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eThe \u003ca href=\"https://projectable.me/projects/nullg/reinforcement-learning/\" rel=\"nofollow\"\u003ereinforcement-learning page\u003c/a\u003e covers the training integration, and the \u003ca href=\"https://projectable.me/projects/nullg/mcp-tooling/\" rel=\"nofollow\"\u003eMCP tooling page\u003c/a\u003e describes the inspection tools.\u003c/p\u003e\n\u003ch2\u003eKeeping the project updated\u003c/h2\u003e\n\u003cp\u003eI\u0026#39;m also using the agent-assisted workflow for projectable.me. The agent starts with git history, project documentation and relevant captures, prepares an illustrated article and saves a draft. I can then review and edit it on the site before publication. This post was prepared that way, using repository history for the timeline and existing engine captures for the images.\u003c/p\u003e\n\u003cp\u003eThere’s now a playable racer underneath all this tooling: weapons, computer-controlled opponents, local split-screen, LAN and private online rooms.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/nullg/intro-xl-splitscreen.png\" alt=\"Two-player vertical split-screen racing with WipEout XL content in NullG\"\u003e\n\u003cp\u003eOriginal ships and tracks, sound, and handling for gamepad and simulator use remain part of the longer-term work. Motion output, positional audio and multiple displays are still part of the pod plan.\u003c/p\u003e\n\u003cp\u003eThe \u003ca href=\"https://projectable.me/projects/nullg/\" rel=\"nofollow\"\u003eproject pages\u003c/a\u003e have the engine details, the \u003ca href=\"https://www.youtube.com/playlist?list=PLaR-_mRLlb6E\" rel=\"nofollow\"\u003evideo playlist\u003c/a\u003e has development footage, and further updates are collected in the \u003ca href=\"https://projectable.me/projects/nullg/blog/\" rel=\"nofollow\"\u003eproject blog\u003c/a\u003e.\u003c/p\u003e\n","excerpt":"My anti-gravity racing engine, the simulator I want to build around it, and how AI-assisted development grew into tools for inspecting and testing the game.","metaTitle":"Introducing NullG","metaDescription":"My anti-gravity racing engine, the simulator I want to build around it, and how AI-assisted development grew into tools for inspecting and testing the game.","status":"published","featured":true,"publishedAt":"2026-10-19T02:27:51Z","authorId":"190160de54f2192bd5b8734ec8808086","authorName":"Daniel Chote","authorSlug":"daniel","heroMediaId":"3cd28585400f94ee7115b744db06b6a1","projectId":"ae4bdb66da6dc1729a263a475e1cdbe3","tags":[{"id":"1c9e8a1339a8f8b797767e91a9673016","name":"Game","slug":"game"},{"id":"ecaaace3f367d1a9865ae0933d53d715","name":"Sim Racing","slug":"sim-racing"}],"createdAt":"2026-10-19T02:05:13Z","updatedAt":"2026-10-26T18:08:23Z"},{"id":"b1e03f83e9994cc176806835fefac821","siteId":"projectable","slug":"a-gopinoccio-based-game","title":"A @goPinoccio based game","markdown":"\u003cp\u003eSo. Sitting on the \u0026ldquo;can\u0026rdquo;, and I just came up with a cool game idea!\u003c/p\u003e\n\n\u003cp\u003e2 scouts, each with a small NeoPixel strip, and a gyro inside a small box. Each scout is basically an egg timer, you flip it upside down and the NeoPixel strip represents a countdown. Once the countdown is started, the other player must flip their scout over to start the countdown in the other direction. Gameplay takes place over a long period of time, the looser doesn\u0026rsquo;t need to play their move immediately, so the winner doesn\u0026rsquo;t know when they may have to flip theirs again!\u003c/p\u003e","html":"\u003cp\u003eSo. Sitting on the “can”, and I just came up with a cool game idea!\u003c/p\u003e\n\u003cp\u003e2 scouts, each with a small NeoPixel strip, and a gyro inside a small box. Each scout is basically an egg timer, you flip it upside down and the NeoPixel strip represents a countdown. Once the countdown is started, the other player must flip their scout over to start the countdown in the other direction. Gameplay takes place over a long period of time, the looser doesn’t need to play their move immediately, so the winner doesn’t know when they may have to flip theirs again!\u003c/p\u003e","excerpt":"","metaTitle":"","metaDescription":"","status":"published","featured":false,"publishedAt":"2014-07-01T12:43:02Z","authorId":"190160de54f2192bd5b8734ec8808086","authorName":"Daniel Chote","authorSlug":"daniel","heroMediaId":"","projectId":"","tags":[{"id":"bad79ac70a78dabfd99590c1b590b839","name":"Pinnocio","slug":"pinnocio"},{"id":"1c9e8a1339a8f8b797767e91a9673016","name":"Game","slug":"game"},{"id":"261e5d05408565a56b2859d32323a8e8","name":"Neopixel","slug":"neopixel"}],"createdAt":"2026-10-18T13:16:27Z","updatedAt":"2026-10-18T13:16:27Z"}],"site":{"id":"projectable","theme":"projectable","title":"Daniel Chote's Project Blog","description":"Software Development, Game Development, Hardware Hacking, Sim Racing, Multi-rotors and Robots!","timezone":"America/New_York","postsPerPage":10,"logoMediaId":"21557257b3f2ecc4b3fa875b808097a7","coverMediaId":"6d7e99f0997d13aac98da38677ca7064","copyright":"© Daniel Chote","twitterUrl":"https://twitter.com/dchote","linkedinUrl":"https://www.linkedin.com/in/dchote","googleTagId":"G-07GJBQVM38","hosts":[{"host":"new.projectable.me","canonical":false},{"host":"projectable.me","canonical":true},{"host":"www.projectable.me","canonical":false}]},"tag":{"description":"","name":"Game","slug":"game"},"tagId":"1c9e8a1339a8f8b797767e91a9673016","total":5}

Game

Software Development, Game Development, Hardware Hacking, Sim Racing, Multi-rotors and Robots!

NullG updates: the XL fleet, shields and a first Pulse race
I've been working on the rebuilt XL ships, shields, split-screen and learning pilots, plus the first playable Pulse preview and more PSP imports.
Recreating the WipEout XL fleet in Blender
How I used Blender and the assistant to rebuild the five XL ships, weapons and trackside models, then check their materials and movement in NullG.
Teaching NullG pilots to drive and use weapons
What changed in NullG's pilot training, from steering and Turbo to weapons, and what the latest four-hour combat run managed.
Introducing NullG
My anti-gravity racing engine, the simulator I want to build around it, and how AI-assisted development grew into tools for inspecting and testing the game.
A @goPinoccio based game
So. Sitting on the “can”, and I just came up with a cool game idea! 2 scouts, each with a small NeoPixel strip, and a gyro inside a small box. Each scout is