The kitchen lighter: contact-rich physics built from 90 photographs

The fastest way to explain what NTL produces is to walk three objects through it. We picked a kitchen lighter, a drawer, and a game controller: three families with different geometry, different articulation, different failure modes, and different proof we cared about. Each took an afternoon to produce and replays in seconds. Each ships as a single neural object bundle that any robotics team can pick up and run.

This post is the demo. The lighter is the headline.

Lighter — the headline result

The kitchen lighter is the harder problem. It is small. It has a trigger that requires real force from a real gripper. It has a flame state that depends on contact, not on a joint command. And it is a place where the previous-generation depth-shell reconstruction simply did not work.

The pipeline we shipped uses an SF3D body shape prior, a procedural family-builder overlay for the trigger and the safety lock, and GA2.5 physics authoring for the joint and the contact mesh. Input: roughly 90 photographs, a phone, a dark background, and a coin for scale.

Kitchen lighter photographed on black fabric with coin for scale — One of ~90 input photographs. A phone, a dark background, and a coin for scale reference.

Neural reconstruction of the kitchen lighter rendered in Isaac Sim — The reconstructed lighter loaded in Isaac Sim. Body shape from SF3D; trigger and safety lock from the family builder.

Lighter neural object in the assembly editor with body, trigger, and safety lock parts color-coded — The assembly editor view. Body (red), trigger (grey), and safety lock (blue) are separate collision groups with independent physics.

The proof we cared about was the press test. A ram rig drives a vertical actuator down onto the trigger; the lighter is held by its body; physics decides whether the trigger depresses. A bbox-based state machine watches the trigger position. When the trigger crosses the threshold, FLAME ON. When the actuator retracts, FLAME OFF.

The press test in Isaac Sim. Contact physics drives the trigger; a state machine watches the joint position.

Franka robot arm holding the lighter in the Isaac Sim environment — The Franka grips the lighter body in a simulated kitchen environment. Same calibrated asset, same physics.

The press test passes deterministically. Mass, friction, joint static friction, and surface friction combine mode are all calibrated values, not placeholders. The value the lighter demonstrates: the bundle format scales down to small, contact-rich, articulated objects without giving up on validated physics.

The lighter is the object that breaks pipelines that use placeholder physics. Contact-rich means every parameter matters. None of ours are guessed.

Drawer — bulk translation, three stacks

We started with a phone video of a person pulling a kitchen cabinet drawer open. From that video plus reference photos, the pipeline produced a USD asset, calibrated its physics, and shipped the bundle to qualification. Then we ran three stacks at it.

Stack one: joint actuate. The robot follows a kinematic plan; the drawer joint is driven directly. Not honest physics, but useful as an authoring baseline. Labelled as such on the task DNA record.

Stack two: real-grip PPO. Trained on 1024 environments in Isaac Lab, 24,000 timesteps × 16 rollouts = 1500 iterations. Total wall-clock: seven minutes on an RTX 5080. Result: 100% success, 12 of 12 rollouts, mean pull 159 mm. Real friction grip, no actuation cheat.

Stack three: human demo replay. The phone video retargeted to the Franka end-effector frame and replayed against the calibrated asset. Result: 23.3 mm of drawer travel out of a 50 mm threshold. Partial success. Honest physics caught the gap.

The value the drawer demonstrates: one capture, multiple stacks, all of them traceable. Every rollout produces a task DNA record. The transfer report compares the records against a robot panel.

Controller — articulated rows and family priors

The game controller pushes the procedural builder hardest. Every panel has its own mechanism: face buttons, a directional pad, two analog sticks, two shoulder triggers, two bumpers. We use a family builder, a procedural generator that overlays mechanisms from the family template onto the SF3D body. The pipeline catches recurring failures and emits structured failure signals; an evaluator loop corrects them.

The proof we cared about was the affordance evaluation pass. Grasps on the analog sticks, the trigger row, or the cooling vents are functionally wrong even when they are geometrically stable. The affordance gate caught the dangerous grasp deterministically on the first run.

The value the controller demonstrates: family priors do real work when encoded as procedural builders rather than learned features. We can write them, audit them, and ship them per family without retraining anything.

What the three examples have in common

One capture, many stacks. Every object goes through the same pipeline regardless of family.
Calibrated physics, not placeholders. Mass, friction, and joint friction are validated values. We document where each came from.
Honest task DNA. Every rollout’s flavor is labelled: joint_actuate, real_grip_rl, human_demo, magnetic_grasp. The flavor changes how a downstream consumer should interpret the rollout.
Reproducible. Every bundle ships with a reproduction/run_task.py that replays it. We run it on every release.

We chose these three because they are the smallest set that proves the format generalizes. The lighter is contact-rich press. The drawer is bulk translation. The controller is articulated-row geometry. Together, they cover the failure modes we have seen most often.

What deterministic contact doesn’t tell you

The press test passes because the trigger friction, the joint limits, and the contact geometry are calibrated against a real lighter. A different lighter from the same family will have different spring tension, different surface finish, different wear on the safety lock. The policy generalizes inside the calibrated asset’s physics; outside it, only as far as the calibration is honest.

We treat the deterministic press result as evidence that the physics layer is correct, not evidence that manipulation is solved. The harder problem (whether the policy survives transfer to a real lighter, held by a real gripper, in a real kitchen) lives downstream of the bundle. The bundle is what makes that downstream evaluation possible.

Deterministic in simulation means the physics is correct. It does not mean the real world matches. That gap is exactly what the real-world loop in Veron is built to close.

What you can pick up today

The lighter bundle is the most complete for contact-rich proof. The drawer and controller bundles ship with the same format and qualification record but smaller task DNA sets.

If you want one bundle to read end-to-end, start with the lighter. The schema, the qualification report, the press test task DNA, and the assembly editor breakdown are all populated. It is the worked example we most often hand to reviewers who ask “show me the physics.”

Next: The 16-test gauntlet every asset has to pass. What T1 through T16 actually check, and which of them have already saved us from shipping a broken bundle.