Aether Grid：由開源 AI 驅動交通的未來城市景觀

I Built a Living Futuristic City Where Open-Source AI Drives the Traffic

Tags: #hf26challenge #hacktoberfest2026 #ai #webdev #open-source

What I Built

Aether Grid is a real-time, procedurally generated futuristic cityscape where every flying car, drone taxi, and sky-rail is orchestrated by a local open-weight language model. No API calls. No cloud. The city thinks for itself.

The core idea: instead of hand-coding traffic patterns or using a physics engine, a small open-weight model (running via Ollama) acts as the city's nervous system. It decides:

• Where each vehicle spawns and which lane it takes
• When congestion builds and how to reroute
• Which districts light up at "night" based on a narrative prompt you type

You get a 3D city rendered with Three.js that responds to natural-language commands. Type "a storm is rolling in from the east" and the vehicles scatter, neon signs flicker, and the sky darkens — all decided by the model, not by hardcoded rules.

Demo

[Video / Live Demo Link Here]

Code

[GitHub Repository Link Here]

Repo structure:

aether-grid/
├── src/
│ ├── city/ # Three.js scene, buildings, roads
│ ├── traffic/ # Vehicle spawning, lane logic
│ ├── ai/
│ │ ├── prompt.js # System prompt for the city model
│ │ ├── parse.js # JSON response → scene actions
│ │ └── client.js # Ollama local inference wrapper
│ └── ui/ # Prompt input, stats overlay
├── models/ # Local model config (llama3.2:3b)
└── README.md

How I Built It

The AI layer. I used Llama 3.2 3B via Ollama, running entirely on my machine. The system prompt instructs the model to act as a city traffic controller and return structured JSON:

{
"spawn": [{ "type": "taxi", "lane": 3, "speed": 1.2 }],
"reroute": [{ "vehicle_id": "v-42", "new_lane": 7 }],
"atmosphere": { "sky": "storm", "lighting": "neon-amber" }
}

The response parser maps each field to a Three.js action. No external API — the model runs at ~15 tokens/sec on my laptop, which is plenty for a city that updates every 2 seconds.

The 3D scene. Buildings are instanced meshes with emissive window textures. Flying cars are simple box-and-wing geometries on spline paths. The trick that made it feel alive: each vehicle has a slight sinusoidal bob, and the camera slowly orbits the city center unless the user takes control.

The prompt interface. A single text input at the bottom. You describe what's happening in the city, the model decides how the city reacts. This is where the open-weight model does the heavy lifting — it's not generating text for a user, it's generating actions for a simulation.

Why Open Innovation Matters

This is the part I care about most.

I could have called a hosted API to do this. I didn't, and here's why:

1. It works offline. I built this on a flight. No signal, no API key, no rate limit. The city ran the entire 6-hour flight because the model was local.
2. It's cheap to run. A 3B parameter model fits in 2 GB of RAM. Any laptop from the last 5 years can run this. There's no per-token cost that scales with how fun the city gets.
3. You can fork it. The model, the prompt, the parser — everything is in the repo. Someone in a low-connectivity area can run this same city on a $200 laptop and modify the prompt to make their own version. That's not possible with a closed API.
4. The prompt is the code. The "intelligence" of the city lives in a ~50-line system prompt. You can change how the city behaves by editing text, not by retraining a model or paying for fine-tuning.

That last point is what excites me about open-weight models. The barrier between "I have an idea for how a city should feel" and "here's a city that feels that way" is a text file.

What's Next

• Add a multi-city mode where two models negotiate trade routes
• Port the traffic logic to a WebGPU renderer for mobile
• Let users fine-tune the prompt with a slider that interpolates between "chaotic" and "orderly"

Built during Hacktoberfest 2026. All code is MIT-licensed. Go build a city.