Technology — How Simvera Works

Path A · Open-vocabulary perception

Reason first. Segment second.

A scene model looks at the frame and says what matters in words. A promptable segmenter turns those words into pixel masks. Geometry turns masks into zones a machine can act on. No dataset, no training, and a hazard you have never mentioned is a sentence away. Run it on the demo →

1 · Reason

The scene model inventories the frame, judges risk, and writes the prompts for the next stage

2 · Segment

Each prompt becomes a pixel-accurate mask with a confidence score

3 · Geometry

Hulls close a cordon, dilation grows a danger zone, clipping drops what is off the road

4 · Output

Masks, boxes and a JSON record per finding, with the reasoning attached

Workshop floor with an oil spill grounded as a hazard and the worker beside it masked red and flagged for missing PPE

Fixed cameraspill · exposure check

[ reason → segment → danger zone → ppe pass/fail ]

Dashcam view of a rockfall on a mountain road with the road masked blue and each boulder masked separately

Moving camerarockfall · 5 obstructions

[ road first → sweep vocabulary → clip to surface ]

Where it runs. No-go zone mapping, hazard and PPE auditing, and road debris detection, all live on ordinary cameras.

See Track 01 deployed →

Path B · Synthetic-data training

Your object. Rendered, then learned.

When the thing you need to detect is not in any vocabulary, or has to run in a few milliseconds on an edge box, we build it a detector. The object is digitised, dropped into a simulator, rendered under every condition with its labels written by the renderer, and a model is trained and benchmarked on that set. Four stages, every one automated.

Step 01 · Digitize

Indoor factory Road debris

Real Objects Become Digital Assets.

We create high-fidelity 3D models, reconstructed from sources like camera imagery, 3D modeling software, and point-cloud scans. These aren't just meshes. They carry physically accurate materials, textures, and reflectance properties, packaged as OpenUSD assets. That means any object can drop straight into a simulator like CARLA or Omniverse and be rendered under any lighting condition to generate synthetic data.

Photoreal 3D-rendered traffic cone asset with PBR materials

asset · cone_001.usdtris 47,318

[ scanned asset · pbr materials ]

Step 02 · Simulate

Indoor factory Road debris

Photorealistic Environments at Scale.

Once in CARLA and NVIDIA Omniverse, those assets are placed in varied scanrios like indoor factory, road, or tunnel environments with randomized lighting, camera angles, occlusions, and backgrounds. That includes rare road events like falling cargo that no fleet could ever film. Every frame is auto-labeled at render time, giving pixel-perfect segmentation masks for every object and surface, with bounding boxes derived for free.

CARLA scene with a Simvera cone asset placed in the road and automatically boxed by the simulator at render time

Objects in simcarla · cone_001 placed

[ randomised lighting · pose · occlusion ]

Synthetic CARLA street scene with auto-generated ground truth: drivable surface segmented in blue, two traffic cones segmented as separate instances

Segmentation in simcarla · frame_00621

[ rendered frame · per-pixel ground truth ]

Step 03 · Train

Indoor factory Road debris

The Training Loop

The rendered frames feed a single pipeline that adapts to whatever a customer needs, whether that's detecting objects and locating them, or reading a whole scene at the pixel level to map drivable space and flag anything that does not belong. The same synthetic ground truth trains both. And because the models learn entirely from synthetic data, they carry straight over to real cameras. No annotation teams. No labeling bias.

train · multi-gpumAP50 0.918

[ synthetic frames → model → checkpoint ]

Step 04 · Deploy

Indoor factory Road debris

Real-Time Detection on Real Cameras.

The trained model runs against live camera feeds, whether the camera is fixed or moving. Every detection is placed in a real-world frame of reference, so a hazard is not just recognized but located, then passed to the safety systems already in place. One pipeline, one model family, adaptable to very different deployments.

Live factory camera feed with world-coordinate grid overlay — a detected cone mapped to real-world floor coordinates

Indoor factory● LIVE · cam-04 · 16 ms

[ rtsp feed · world coords · 5G/UWB fusion ]

Real motorway dashcam frame: drivable surface segmented in blue and a crate falling from a truck flagged as debris, with smaller fragments caught individually

Road debris● LIVE · dashcam · M25

[ free space + open-set anomaly · ego frame ]

Where it runs. The cone pilot on a live factory camera. The four published checkpoints behind it are on the Benchmarks page.

See Track 02 deployed →

For cloud partners

Why We Need GPU Compute.

Synthetic-data pipelines are GPU-heavy at every stage. The numbers below are the order of magnitude we're working at today, and where 2026 is heading.

01 · RENDERING

Photoreal generation

Rendering photoreal training frames in Omniverse. Every object class needs broad coverage across lighting, weather, and angle.

10k+ scenes / class

02 · TRAINING

Multi-GPU model training

Training detectors and segmentors on the rendered datasets. Multi-GPU runs to converge on each new hazard class and condition mix.

100k+ synthetic frames

03 · SCALING

Class library expansion

We're scaling from cones (live) and road debris (prototype) toward a hazard library covering factory safety, road infrastructure, etc.

N+ classes planned ’26

How Simvera Works.

Reason first. Segment second.

Your object. Rendered, then learned.

Real Objects Become Digital Assets.

Photorealistic Environments at Scale.

The Training Loop

Real-Time Detection on Real Cameras.

Industrial-grade open infrastructure.

Why We Need GPU Compute.

Photoreal generation

Multi-GPU model training

Class library expansion