Decart has introduced Oasis 3, a real-time world model aimed squarely at one of the hardest problems in autonomous vehicle development: building driving environments that are realistic enough to stress-test perception and planning systems, but controllable enough to reproduce edge cases on demand. The company’s pitch is straightforward—generate photorealistic driving scenes in real time, then let developers use those scenes to evaluate how their vehicles behave. What makes the announcement notable is not just the “photorealistic” framing, but the emphasis on runtime generation and API access, which signals a shift from simulation as a closed tool to simulation as an infrastructure layer.
For AV teams, the bottleneck is rarely the existence of simulation. It’s the gap between what simulation can represent and what real roads actually do. Real-world driving is messy: lighting changes mid-scene, weather alters contrast and reflectance, traffic behavior is inconsistent, and the long tail of rare events can be both safety-critical and difficult to capture with limited data. Traditional approaches—record-and-replay datasets, scripted scenario simulators, or offline rendering pipelines—each solve part of the problem while leaving another part behind. Oasis 3 is positioned as an attempt to compress that gap by generating environments that look like real driving while still being responsive enough for iterative testing.
At the core of the product is the idea of a “world model.” In practice, that means the system doesn’t merely render a static scene from a fixed description. Instead, it produces a driving environment that can evolve as the simulation runs, supporting real-time interaction. Decart describes Oasis 3 as capable of simulating hours of photorealistic driving, which matters because many evaluation workflows require more than short clips. If you’re testing long-horizon behaviors—comfort constraints, stability under repeated maneuvers, sensor drift effects, or the cumulative impact of minor perception errors—then the ability to run extended sessions without collapsing into repetitive patterns becomes a practical requirement.
But “hours” is also where caveats enter the picture. Photorealism and duration are not the same thing as fidelity to every physical and behavioral detail. A world model can generate visually convincing scenes and plausible motion, yet the exact distribution of rare events, the realism of micro-interactions (like how a pedestrian’s gait changes when a vehicle approaches), or the consistency of sensor artifacts can still depend on how the model is integrated into a full testing pipeline. In other words, Oasis 3 appears designed to make simulation more realistic and more scalable, but it doesn’t eliminate the need for validation. For teams used to treating simulation as a complement to real-world testing, this is likely familiar territory—just with a new lever that can change how quickly you can iterate.
The most consequential change in this release is availability via API. That detail may sound like a business update, but it’s actually a technical one. When a world model is exposed through an API, it becomes easier to embed into existing evaluation stacks: scenario generation tools, continuous integration pipelines for autonomy software, synthetic data creation workflows, and even custom research environments where developers want to control parameters and measure outcomes. API access also suggests that Decart expects developers to orchestrate Oasis 3 alongside their own perception and planning components rather than treating it as a standalone simulator.
This matters because AV testing is rarely a single-model problem. A typical workflow might involve generating a scenario, running a perception stack to produce trajectories or object tracks, feeding those outputs into a planner, and then measuring performance against metrics like collision rates, rule compliance, comfort, and robustness under uncertainty. If Oasis 3 can generate scenes in real time, developers can potentially run closed-loop tests—where the vehicle’s actions influence what happens next—rather than relying solely on open-loop playback. Closed-loop evaluation is where many autonomy systems reveal their weaknesses, because the system must recover from its own mistakes, not just follow a script.
Decart’s framing around photorealistic driving environments also points to a specific kind of value: reducing the domain gap between synthetic and real sensor inputs. Domain gap is the silent killer of synthetic training and evaluation. Even if a simulator produces correct geometry, differences in textures, lighting, camera noise, and motion blur can cause models trained or tested in simulation to behave differently in the real world. A world model that can generate photorealistic scenes could help narrow that gap, especially for perception tasks that are sensitive to visual cues—lane markings, traffic sign legibility, reflective surfaces, and subtle changes in contrast.
Still, photorealism alone doesn’t guarantee that the semantics are correct. A scene can look right while containing inconsistencies: a sign might be visually plausible but misread by a downstream model due to incorrect text rendering; a vehicle might appear to obey traffic rules but behave in a way that violates physical constraints; or the timing of interactions might not match real-world statistics. This is why the “caveats” language in the announcement is important. The promise is about generating realistic environments for testing, but the responsibility for ensuring that those environments align with the evaluation goals remains with the developer.
One unique angle in Oasis 3 is the implied shift toward “procedural realism.” Traditional simulation often relies on procedural generation, but procedural systems can become repetitive or obviously artificial. The challenge is to maintain diversity without sacrificing coherence. If Oasis 3 can sustain photorealistic output over long durations, it suggests the system is designed to avoid the common failure mode where scenes degrade into artifacts, repeated patterns, or unrealistic transitions. Long-running sessions are a stress test for any generative system: small errors accumulate, and temporal consistency becomes harder to maintain. The fact that Decart highlights extended simulation time indicates they’ve invested in keeping the experience stable enough for practical evaluation loops.
Another practical benefit of real-time generation is iteration speed. AV teams frequently need to explore parameter spaces: different weather conditions, traffic densities, road geometries, and behavioral assumptions. If generating a new scenario takes minutes or hours, experimentation slows down and teams end up focusing only on a narrow set of cases. Real-time generation can enable faster cycles—generate, run, analyze, adjust—so that developers can converge on robust behaviors more efficiently. This is especially relevant for debugging. When a system fails in simulation, developers want to reproduce the failure deterministically or at least understand which factors correlate with it. A world model accessible via API could allow targeted re-generation with controlled variations, making root-cause analysis less of a guessing game.
There’s also a strategic implication: Oasis 3 positions Decart not just as a simulator vendor, but as a platform provider. World models are increasingly treated as foundational components in AI systems—capable of generating data, simulating environments, and supporting planning research. By offering Oasis 3 through an API, Decart is effectively inviting developers to treat the model as a service. That opens the door to a broader ecosystem: researchers can build novel evaluation methods, startups can integrate synthetic environments into their products, and larger companies can incorporate Oasis 3 into internal tooling without waiting for bespoke integrations.
Of course, the real question for developers is how Oasis 3 fits into their existing constraints. AV testing isn’t only about visuals; it’s about measurable outcomes. Teams care about reproducibility, determinism, and the ability to trace results back to scenario parameters. With generative systems, reproducibility can be tricky unless the API supports seeding, versioning, and explicit control over generation settings. While the announcement emphasizes real-time photorealistic generation and API availability, developers will likely want clarity on how scenarios are specified, how randomness is handled, and what guarantees exist for repeatability. In production evaluation, “close enough” isn’t always acceptable—especially when comparing two versions of an autonomy stack.
Another consideration is integration with sensor models. Many AV pipelines don’t consume raw rendered images directly; they rely on simulated sensors that include noise characteristics, calibration parameters, and timing offsets. If Oasis 3 provides photorealistic environments, developers still need to map those environments into the sensor domain their system expects. That could mean generating camera feeds with realistic artifacts, producing LiDAR point clouds with appropriate density and reflectivity behavior, or simulating radar returns. The announcement doesn’t spell out these details in the summary provided, but the practical reality is that photorealistic world generation is only one layer. The rest of the stack determines whether the simulation is useful for training, evaluation, or both.
Even so, the direction is clear: Oasis 3 aims to make it easier to generate realistic driving scenes at scale. Scale is the missing ingredient in many AV testing strategies. Data collection is expensive, and real-world edge cases are rare by definition. Synthetic generation can fill the gap, but only if it produces scenarios that are both diverse and credible. A world model that can run for hours and generate photorealistic environments suggests a path toward scaling evaluation beyond short clips and narrow scenario libraries.
There’s also a subtle but important shift in how teams might approach scenario design. Historically, scenario-based testing encourages engineers to enumerate specific situations: a cut-in at a certain distance, a pedestrian crossing at a certain angle, a vehicle merging under certain constraints. But enumerating everything is impossible. Generative world models can support a different workflow: define higher-level conditions and let the system generate concrete instances. That can reduce manual scenario authoring and increase coverage of the long tail. The tradeoff is that engineers must trust the generator’s ability to produce meaningful variations rather than superficial changes. Again, this is where integration and validation matter.
Decart’s positioning around autonomous vehicle testing implies that Oasis 3 is intended to be used in evaluation contexts, not just for entertainment or visualization. That means the model likely needs to support consistent scene semantics—roads, lanes, traffic participants, and environmental elements—so that downstream systems can interpret the world correctly. If the model can maintain semantic coherence while generating photorealistic visuals, it becomes more than a rendering engine. It becomes a testbed for autonomy behavior.
The “some caveats” language in the announcement is also a reminder that gener