Back to Work & Blog
3DGSIsaac SimLiDARGuide 2026-08-165 min read

Setting Up a 3DGS Simulation
Environment for Isaac Sim

This is Nakamura from LOCAHUN 3D. This is a working guide to turning a LiDAR-fusion 3DGS scan into a simulation environment robots can drive under physics in NVIDIA Isaac Sim. The policy is radical simplicity: use the scanner's 3DGS and mesh untouched, and patch only the ground holes in the mesh. No deletion passes. Our scan of Tokyo's Shibuya scramble crossing serves as the running example.

Aerial render of the Shibuya scramble crossing 3DGS scan
The Shibuya crossing 3DGS after post-processing.Underneath this appearance layer sits an invisible collider (raw mesh + ground patches) — stacking the two is what lets a robot drive here under physics.
3DGS scan (untouched) load patch ground holes only drive on two layers
What this article gives youThe inputs are the three standard outputs of a LiDAR-fusion scanner — the 3DGS, the scanner mesh, and the dense LiDAR point cloud (the procedure does not apply to camera-only 3DGS). With only ground-hole patching as post-processing you hold a two-layer environment — the visible 3DGS stacked on an invisible collider — ready for robot driving, collision, and sensor tests in Isaac Sim. Dependencies: Python, a point-cloud library, and Isaac Sim.

01 The big picture — why a collider at all

3DGS is unbeatable at looking right. But that is the result of optimising to match photographs, not of getting the shape correct — and used raw in simulation, two failures follow.

First, floaters: gaussians left where nothing exists land in the robot's camera as view noise. Under this article's policy we accept them rather than delete them — deletion passes keep destroying real content (see the optional section). Second, the real wall, holes in collision: 3DGS has no surfaces, so collision comes from the scanner mesh, whose boundary-edge holes run to 4.86% indoors and 9.01% in Shibuya. Put a robot on a hole and this happens.

The failure case.There is visibly a floor here, but the collision mesh has a hole — the robot kept accelerating down below the floor without stopping.

The architecture that fixes both is two layers: a floater-cleaned 3DGS for appearance, an invisible watertight collider for physics. NVIDIA×Niantic's pipeline of the same shape constrains geometry with AI-estimated depth — but that is what you do when a 360° camera is all you have. Holding measured LiDAR depth, you need neither the estimator nor any retraining: the five steps below build the same thing (quantitative comparison against learned methods is in the benchmark section).

02 STEP 1: Load the 3DGS into Isaac Sim

Convert the 3DGS PLY to USD (ParticleField) and load it — the basic conversion workflow is covered in a separate article. For a working setup, defuse two traps first.

The unit trap when placing robotsReference assets authored in centimetres (Isaac's stock forklift among them) get an automatic correction scale from Kit. Rebuild the transform and that correction disappears — a giant forklift appears. Set the scale explicitly if you rebuild.

03 STEP 2: Patch only the ground holes in the mesh

Use the raw scanner mesh untouched as the collider. A voxel-healed watertight shell melts the geometry into wax, and patches cut from such a shell leave spiky fragments — both approaches lost. For thin poles and bollards alike, the raw mesh is the most accurate shape you have.

The only addition is ground patches: build a smooth ground field from the measured LiDAR surface and lay grid faces at field height only in cells where the raw mesh has no ground at all. Wall and facade holes never affect driving, so they stay. In Shibuya, nothing falls through anywhere in the drivable area. The holes a robot could fall through are sealed; not a single other triangle changes.

Three layers, same camera.Top: the untouched 3DGS. Middle: the untouched raw scanner mesh (holed). Bottom: the collider (raw + ground patches only). Middle and bottom are identical except for the ground holes — every bollard and pole matches one-for-one.

04 STEP 3: Stack the two layers and drive

Assemble one USD: define a physicsScene on a Z-up stage, reference the 3DGS file as-is and stand it up with a -90° X rotation (no baked re-export needed), embed the collider as a Mesh with CollisionAPI (approximation=none), and call MakeInvisible() on it. That completes the two-layer environment: untouched 3DGS for appearance, raw mesh + ground patches for physics.

For the vehicle, use PhysX Vehicle (omni.physx.vehicle). The wizard API (VehicleData + create_vehicle) generates a 4-wheel car with sprung suspension and Ackermann steering in a few lines, driven by accelerator (0–1) and steer (-1–1). The suspension absorbs the raw scan road's small bumps, so the ride is smooth without smoothing the data. Two traps: set rootVehiclePath and rootSharedPath on VehicleData explicitly, and register your collider in the generated GroundSurfaceCollisionGroup.

A PhysX Vehicle driving the finished environment (video runs at ~2× sim time). It runs straight through the south side of the scramble, takes a sidewalk step on the suspension, and finally collides with the corner structure and stops dead — no clipping, no penetration. Under the untouched policy, scanned-in pedestrians act as real obstacles too.
The same run from an onboard camera.The camera is parented to the vehicle body, so you experience "Shibuya as the robot's camera sees it" complete with suspension motion — across the crosswalk and into the corner by MAGNET, all the way to the stop.

05 Optional: clean up with care

Deleting floaters and scanned-in pedestrians is possible, but deletion passes readily take real content — poles, signs, bollards — with them, so this procedure does not use any. If you must clean up: merge the raw LiDAR cloud into the reference surface, delete by silhouette rather than rectangles, and after every pass compare before/after renders from the same viewpoint and account for everything that disappeared. For collision and path-planning work, not deleting is the safest option.

06 Summary

Turning a LiDAR-fusion 3DGS scan into an Isaac Sim environment fits in three lines.

Only two limits worth remembering: no surface exists where the LiDAR never looked, so keep routes inside the observed region; and under the untouched policy, scanned-in pedestrians and parked vehicles remain as real obstacles.

The basics of loading 3DGS into Isaac Sim are covered in a separate article.

SCAN / 3DGS

LOCAHUN 3D scans real spaces
in a form you can simulate with

Because we capture LiDAR and photographs together, you get both the appearance and the measured geometry. We deliver in the format your work needs — robotics validation, digital twins, or film and VFX.

Talk to us about a scan →
Credits

Production credit

Kou Nakamura
Kou Nakamura
Founder, Locahun 3D / Testing & writing

Founder of Locahun 3D (LOCAHUN 3D). Researches and validates capture workflows that combine 3DGS scans with game engines and AI.

Follow @Kou45388803 →