Lena Lehuby
← Selected work Case 02 / 04
02

Stellantis · R&D internship · 2026

Traffic that moves naturally in VR, with the physics baked in

The brief was one car, seen from inside and outside, in VR. Physics makes a car move naturally, but running it while a headset renders costs too much. My answer: run the physics once, write the result into the scene as USD animation, and let VR play it back. The single car grew into traffic, and a scenario came down to three inputs: a route drawn from above, a target speed and where to stop.

Role
R&D intern, development and project management
Period
March – September 2026
Ownership
The idea, the plan, both extensions and their guides
With
Requirements and validation with the business team

01 · The problem

A car in VR has to move right, run light and be quick to set up.

Each usual way of moving a car met one of these needs and failed another.

Motion Path animation glides A car pushed along a path does not dip when it brakes, lean into a corner or settle on the road. From the driver's seat, that is hard to miss.
Performance Live physics is too heavy for VR A headset needs a steady, high frame rate. Simulating cars while it renders takes frame time it cannot spare, and each extra car adds to the cost.
Authoring Paths carry the road's height A car that follows a path also follows its height. Every point has to sit on the road, or the car floats above it or sinks into it. Each new route has to be fitted to the road in 3D.

02 · The options

Each option solved part of the problem. Only one solved all of it.

Path animation was built and working. Live physics was the obvious upgrade. Baking was the idea that kept the strengths of both and dropped their costs.

Compared on Option APath animation, live Option BPhysics, live in VR Option C · the choicePhysics, baked into USD
Motion Approximated. Lean and dip are added on top. Natural Natural, recorded from the simulation
Cost while VR renders Low Too heavy Low. Stored poses are played back.
Route height Has to be fitted to the road Physics finds the road Physics finds the road
Plays without the tool No No Yes. It is part of the scene.
Verdict Light, but the motion is approximated Natural, but too heavy for a headset Natural, light and quick to set up

03 · The idea

Run the physics once. Replay it as often as needed.

The physics runs once, while the scenario is being built, away from the headset. The run is written into the scene as USD animation: one stored pose per frame for the body, the wheels and the steering. In VR, those poses are only played back. The headset never runs a simulation.

Authoring · once Simulate A physics car drives the route at the target speed and stops at the signs.
The hand-off Bake Body, wheels and steering written into USD, one pose per frame.
In VR · every time Replay Stored poses, played back. No physics while the headset renders.

Why USD

A video of the drive would fix the camera. USD keeps the drive as motion in the 3D scene, so the viewer can sit in the car and look anywhere. USD is also the open scene format Omniverse is built on, so the motion is data in the scene, like a model or a material. That turns one physics run into an asset.

Light Playback reads one stored pose per frame. Nothing is simulated while the headset renders.
The same every time A baked drive does not change between viewings, so a scenario can be shown again and compared.
Portable The motion travels with the scene file and plays without the tool that made it.
Reusable One drive can be referenced in another scene, played slower or faster, reversed, looped, or lined up behind other cars as traffic.

04 · Building a scenario

Draw the route from above. Physics finds the road.

In a physics run, the work is split in two. The scenario decides where the car goes, how fast and where it stops. Physics decides what the road does to it. The route never has to follow the road's height, only its shape seen from above. Nobody fits it to slopes, crests or dips, so a new route is quick to draw.

The scenario decides Where the car goes Its line seen from above, its heading, its speed, and where it stops and for how long.
Physics decides What the road does to it Its height on the road, suspension, pitch, roll and wheel contact.
  1. Input 1 A route, drawn from above A line over the road, captured with one click. Its height does not matter. The car is placed on the road and physics keeps it there.
  2. Input 2 A target speed One cruise speed for the run. The car brakes before corners and crests by itself, then gets back up to speed.
  3. Input 3 Where to stop A stop sign placed by the road. The car slows, stops at the sign, waits and pulls away. The same sign works in every scenario type. The path and recorded scenarios can also read speed limits, yield signs and traffic lights.
Speed along one route Illustrative, not a recorded run

The author sets one speed and places one sign. The braking before the corner and the crest, the stop, the wait and the pull-away all follow from them.

05 · The system

Two extensions that meet in one file

The scenario engine builds and bakes drives. The player turns baked drives into traffic in VR. They meet only in the baked USD, so each can evolve on its own as long as the file holds.

Sources Route in the scene Recorded drive Physics run
Extension 1 Scenario engine speed, curves, signs, convoys, body lean
Extension 1 Bake USD animation, one pose per frame
Extension 2 · in VR Player each car on its own clock, traffic, a seat in the car
Each car on its own clock Play, pause, reverse, loop and change speed per car, without editing the file it came from.
Traffic from recordings Baked cars line up as a leader and followers. A follower waits for a gap before it starts and slows down as it closes in.
A seat in the car A VR camera anchor rides with any baked car, at the driver's eye position.

06 · How I ran it

One problem, owned from framing to handover

I framed the problem, chose the approach, planned the steps, built both extensions and wrote the guides. Each step ended with a version that ran in Omniverse and was checked in the scene. The scope grew only once the previous step held.

  1. S1 One car, inside and outside A car follows a route, with interior and exterior cameras. The cockpit view works in VR.
  2. S2 Believable without physics Body lean calibrated on recorded vehicle data, steering from the road's curvature, routes snapped to the road. Better, but still an approximation.
  3. S3 Traffic and road rules Several cars per route, slowdowns before curves, and signs: stops, speed limits, yield signs and traffic lights.
  4. S4 Physics, baked A physics car follows the route and finds the road itself. The run is baked into USD and replays in VR without physics.
  5. S5 Handover Two user guides, a hint on every control and a walkthrough inside each tool, for the people who use them next.

How I worked

Plan before change Each change started as a written plan with numbered requirements and closed with a check in the scene.
A frozen core Once the timing, speed and bake rules were validated, those modules were locked. Every later change was tested against them.
Checkpoints and a ledger Work stopped at natural checkpoints. Known problems were written down with their cause before any fix.

07 · What came out of it

Natural motion, light playback Suspension, pitch and roll come from a physics simulation. The headset only plays stored poses.
Scenarios from three inputs A route drawn from above, a target speed and where to stop. No heights to fit and no braking to animate by hand.
Two extensions, validated with the team A scenario engine that builds and bakes drives, and a player that turns baked drives into traffic in VR.
A handover built into the tools Two user guides, a hint on every control and a walkthrough in each tool. Where the help and the code disagreed, the guide follows the code.

The scope was mine to propose and the business team's to accept.

This case describes the approach at a general level. The project's code, scenes and internal results belong to Stellantis.

Contact

Product owner and product manager roles in B2B SaaS and AI.

Email [email protected]
CV On request Request by email
Based in France
Lena Lehuby · 2026 Screens from my own prototypes · sample data throughout