The Japanese automaker is building developer tools traditionally left to game studios—a sign that control over the software stack matters more than ever
In a drafty conference room in Brussels on February 1, Joel Winarske stood before a crowd of open-source developers at FOSDEM 2026 and unveiled something unexpected: a 3D game engine built by Toyota. Not a simulation tool for internal testing. Not middleware licensed from Epic or Unity. An actual, console-grade rendering engine that runs inside Flutter, aimed squarely at the touchscreens inside your next car.
Fluorite, as Toyota Connected North America calls it, marks a curious turn for an automaker. Game engines are typically the domain of studios like Epic Games or Unity Technologies—companies that have spent years courting automotive manufacturers to power their digital cockpits. Yet here was Toyota Connected, a North American subsidiary focused on data and connected services, announcing it had built its own alternative. And it's designed specifically for the resource-starved processors that populate most vehicle infotainment systems.
Winarske, a Principal Engineer III at Toyota Connected, delivered the 25-minute session alongside Jamie Kerber from Very Good Ventures, a Flutter consultancy. The project's website, fluorite.game, went live shortly after with sweeping promises: "the first console-grade game engine fully integrated with Flutter." Physically-based rendering via Google's Filament. Hot reload for rapid iteration. Model-defined touch zones authored in Blender. A C++ entity-component-system core for performance on constrained hardware, all wrapped in Dart-based APIs that work natively with Flutter widgets.
It sounds ambitious, perhaps more than one might expect from a carmaker's software arm. But the rationale becomes clearer when you consider what Toyota Connected has already accomplished—and what it's reacting against.
The Licensing Problem Nobody Talks About
Unity and Unreal dominate automotive human-machine interfaces, and not by accident. Epic's Unreal Engine Human-Machine Interface initiative, launched in 2020, landed the GMC Hummer EV as its first production deployment. Rivian's multi-display interfaces run on Unreal. Unity, meanwhile, secured a partnership with Toyota Motor Corporation itself just last February for next-generation HMI development.
Both engines deliver visual sophistication. Both also carry licensing complexities and resource demands that don't sit well with embedded engineers accustomed to squeezing every CPU cycle. "They're seen as resource-heavy and costly for the lower-end processors common in vehicle infotainment systems," according to technical coverage from Phoronix, which has been tracking Fluorite's development threads.
Toyota Connected evaluated Godot, the open-source darling often positioned as a leaner alternative. Too slow to start, according to internal assessments cited by Phoronix. Too resource-intensive for the embedded Linux environments Toyota Connected prefers. Which brings us to why a carmaker might build a game engine in the first place: if the off-the-shelf options don't fit your constraints—or your licensing philosophy—you build your own.
Toyota Connected has been shipping Flutter-based infotainment systems for some time now. The 2026 RAV4 runs one in production, built atop a custom Yocto Linux and Wayland stack. The company's ivi-homescreen repository on GitHub reveals years of groundwork: Flutter embedders for embedded Linux, Vulkan support, early experiments with Filament plugins. Fluorite didn't emerge from nowhere. It's the logical extension of infrastructure already deployed in dealerships across North America.
That Toyota Motor Corporation simultaneously pursues a Unity partnership while Toyota Connected builds Fluorite speaks to a broader industry pattern: automakers hedging bets across multiple technology stacks, unwilling to commit fully to any single vendor's ecosystem. Call it strategic redundancy or internal competition—either way, it underscores how seriously car companies now take software control.
Under the Hood: Filament, Dart, and the "Console-Grade" Debate
Fluorite's architecture divides labor between two languages. The core runs in C++, using a data-oriented entity-component-system designed for the kind of performance embedded hardware demands. Game logic, UI elements, and high-level APIs live in Dart, where developers write gameplay code that shares state directly with Flutter widgets through a component called FluoriteView.
Rendering duties fall to Google's Filament, an open-source physically-based rendering engine originally built with mobile efficiency in mind. Filament supports Vulkan, OpenGL, Metal, and WebGL backends, along with post-processing effects and custom shader capabilities. It's a solid choice for constrained environments, which makes the repeated use of "console-grade" in Fluorite's marketing somewhat puzzling.
Techzine Global, in its February 8 coverage, raised an eyebrow at that claim. Filament was built for mobile-first scenarios, not PlayStation 5-level fidelity. The term "console-grade" carries specific expectations in the games industry—expectations that typically require far more GPU headroom than an infotainment ECU provides. Still, Toyota Connected's intent seems clear: deliver hardware-accelerated visuals that approach what gamers consider acceptable, even on the lower-end chips scattered throughout most vehicle architectures.
Developer workflows show thoughtful design. Hot reload lets engineers iterate on 3D scenes without recompiling. Model-defined trigger zones, configured in Blender, allow artists to tag clickable regions that Flutter listens to for onClick events—a detail that matters when designers need to prototype interactive 3D interfaces quickly. Multiple 3D scene views can exist as separate Flutter widgets, enabling the complex multi-display setups becoming standard in vehicle cockpits.
What's Missing: Code, Documentation, and a Release Date
Here's where the story gets murky. Despite positioning Fluorite as an open-source project across multiple coverage outlets—Open Source For You, Reddit's r/FlutterDev community, developer blogs—Toyota Connected has not published the source code. As of February 13, no public repository exists. The project website offers a "more coming soon" placeholder but no SDK, no documentation, no sample projects, no performance benchmarks, and no release timeline.
Platform support remains similarly vague. The FOSDEM session abstract mentions mobile, desktop, embedded, and console targets. Open Source For You lists Android, iOS, macOS, Windows, Linux, and WebGL. Reddit threads discuss SDL3 embedder work and potential console portability through SDL, though no official console support has been confirmed. Planned integrations include Jolt Physics, per notes recapped by Phoronix from the FOSDEM presentation.
This creates an odd limbo. Fluorite clearly exists—it's running in production vehicles. Toyota Connected engineers spoke about it publicly. But without code or documentation, the broader developer community can't evaluate performance claims, assess API design, or determine whether "console-grade" means anything substantive. The February 1 FOSDEM session, available via video recording, offers the fullest picture currently available. Everything else is projection.
A Different Path Than Unity or Unreal
Within the Flutter ecosystem, Fluorite would occupy territory currently held by Flame, a mature 2D engine, and Rive GameKit, which focuses on vector animation and runtime performance for UI elements. Neither targets 3D rendering at the fidelity Fluorite promises, which would make it the first Flutter-integrated 3D engine aimed at console-grade visuals—assuming that descriptor holds up under scrutiny.
Automotive Grade Linux, acknowledged in coverage as a collaborator, added Flutter support to its UCB 14 platform in November 2022. That move signaled broader industry acceptance of Flutter for vehicle infotainment, creating a foundation Fluorite could build upon. Very Good Ventures' involvement, evidenced by Jamie Kerber's speaking role, suggests commercial consulting ties that could accelerate adoption if Toyota Connected releases the engine publicly.
Toyota Connected describes Fluorite as early stage and actively seeks collaborators and partners. The lack of public code, paired with a FOSDEM reveal and placeholder website, reads like a community-interest campaign ahead of a full open-source release. Whether that release happens—and when—remains unclear.
The Broader Pattern: Software as Competitive Advantage
Fluorite matters less for what it does today and more for what it represents. Automakers increasingly view software as competitive differentiation, not just a cost center. Tesla proved that approach works. Rivian built its own software stack from scratch. Even legacy manufacturers like Ford and GM have poured billions into software development organizations, often with mixed results.
Toyota Connected's decision to build a game engine reflects that same calculus: better to control the entire stack, licensing terms and all, than depend on third-party vendors whose roadmaps may not align with automotive timelines. That Unity and Toyota Motor Corporation maintain a separate partnership while Toyota Connected pursues Fluorite suggests internal hedging, perhaps even healthy competition between business units.
For now, Fluorite exists as a compelling idea backed by real production experience but without the public artifacts developers need to evaluate or adopt it. The "console-grade" language may prove aspirational. The Flutter integration could be transformative or simply convenient. The open-source promise may materialize next month or next year.
What's certain: Toyota Connected has committed serious engineering resources to solving a problem most automakers address by writing checks to Epic or Unity. That alone tells you something about where the industry is heading—and how much leverage those traditional game engines currently hold over automotive software architectures.
The video from Brussels is available for those curious enough to sit through 25 minutes of technical presentation. Beyond that, we wait for code.
