StadiView: A Procedural 3D Football Stadium Concept for Browser-Based Seat Previewing

What StadiView Is and Who Would Use It

Choosing a seat for a live football match is often done blind: a venue map shows rows and numbers, but not the actual sight line from that specific seat to the pitch. StadiView demonstrates what a real-time 3D seat preview could look like in a browser, without requiring a plugin or native app.

The README frames it as a concept demo. The fixture information, pricing, availability, seating tiers, and blocks are all procedurally generated rather than drawn from a real database. The project is aimed at developers who want to see how a browser-based 3D stadium could work, UI/UX designers exploring spatial ticketing interfaces, and anyone building a prototype for a sports venue or ticketing product who needs a starting point.

The repository is published by thebuggeddev, who describes it as an experimental, vibe-coded project. The live hosted version is at football-stadium-ruddy.vercel.app.

Procedural Generation and Three.js Architecture

The README's most distinctive technical claim is that the stadium contains no imported 3D models. Every structural element is generated procedurally at runtime using Three.js. This means the stadium geometry, seating sections, stands, and pitch-side displays are all built in code rather than loaded from a file. The benefit is that the experience has no large asset download; the entire application is self-contained in index.html.

Seats are rendered using instancing. Instancing is a rendering technique where many identical objects, in this case individual seats, are drawn in a single GPU call by passing per-instance transformation data. The README states that thousands of individually selectable seats are rendered this way. This is a meaningful engineering choice: naive rendering of thousands of separate seat objects would be far too slow for interactive frame rates.

GSAP handles animation. The animated camera flights when flying into a seat view, the animated players and ball on the pitch, and the crowd animations all go through GSAP's animation library. Vite is used as the build tool; package.json lists vite as the only dev dependency, with the main libraries loaded via the index.html.

Running StadiView Locally

The README documents a two-command setup:

npm install
npm run dev

After running npm run dev, Vite starts a local development server and prints the local address to the terminal. Opening that address in a browser loads the 3D stadium. The package.json also includes npm run build for producing a static export and npm run preview for previewing the built output locally.

The controls are documented in a table in the README. Click and drag to rotate the view around the stadium. Mouse wheel or on-screen controls zoom in and out. Clicking a seat triggers a camera flight into a first-person preview from that seat. While in seat view, dragging lets you look around. Pressing Escape or clicking the Back to stadium button exits the seat view. Pressing Enter or clicking Grab seat confirms the simulated selection.

Seat Preview System and Generated Data

The first-person seat view is the core feature. When a visitor clicks a seat, the camera animates from its current position down to the selected seat's position and orientation. From there, the view approximates what the pitch and stadium would look like from that specific location. The generated data for each seat includes a price, availability status, tier, block, and listed benefits, all created procedurally to simulate a realistic ticketing interface.

The README makes the simulated nature explicit in a note at the top of the document: fixture, prices, seat availability, checkout, and other ticketing data are simulated, and no real tickets are sold. This means the project cannot be deployed as-is for actual event ticketing without replacing the generated data layer with a real backend. The visual and navigation experience is complete; the data integration is not.

The scoreboard, pitch-side displays, crowd, and player animations add context to the seat preview. These are not interactive but contribute to a realistic spatial impression of the venue during a live match.

Licensing: Noncommercial Source Available, Not Open Source

StadiView is released under the PolyForm Noncommercial License 1.0.0. The README specifies that this license permits studying, sharing, and adapting the project for noncommercial purposes, with required attribution. Commercial use is explicitly excluded. The README lists examples of commercial use: a paid product, a client project, a ticketing platform, a stadium or club experience, or any other business activity. Each of these requires a separate commercial license.

The repository also notes that it is source available but not an OSI-approved open source project. Third-party libraries, including Three.js and GSAP, remain under their own licenses. The THIRD_PARTY_NOTICES.md file in the repository documents those dependencies.

Developers who want to use StadiView as a reference for their own work can study and adapt it under the noncommercial terms. Agencies or studios building a real stadium seat selection tool for a client need to contact thebuggeddev for a commercial license before shipping any derivative work.

Comparison with Standard Venue Seat Map Tools

Existing stadium and arena seat selection tools on ticketing platforms typically use SVG or canvas-based 2D maps with hover popups showing section details. They are data-driven: the seat layout comes from a venue configuration file, availability comes from an inventory API, and prices come from a pricing engine. None of this is present in StadiView.

What StadiView adds is the spatial, immersive dimension that 2D maps cannot provide. A 2D map tells a buyer that they are in Row G, Block 14. StadiView shows them what Row G, Block 14 actually looks like from eye level. This distinction is meaningful for high-demand events where seat location significantly affects the experience and buyers are making decisions without prior venue knowledge.

Implementing a production-quality version of what StadiView demonstrates would require integrating with a real seat inventory API, replacing the procedural geometry with venue-specific measurements, and handling the performance requirements of a public-facing web application. StadiView demonstrates the visual concept; the data and infrastructure layer is entirely absent.

Editorial conclusion

StadiView is a credible proof of concept for developers and studios exploring procedural 3D stadium experiences in the browser. It is not a ready-made ticketing integration: all seat data is generated, not sourced from a real venue, and the PolyForm Noncommercial License requires a separate commercial license for any paid or commercial use. Before adapting it for a production ticketing or stadium experience, read the commercial licensing terms directly, since that use case is explicitly named as requiring a separate agreement.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. thebuggeddev/football-stadium on GitHub