Right now there is no public, turnkey tool that will take a NuRec/3DGRUT‑generated USDZ scene from NCORE and synthesize a CARLA‑ready map.xodr; CARLA‑NuRec still fundamentally expects an OpenDRIVE map (or a CARLA map that already has one) for road semantics, and USDZ‑only scenes are not yet a first‑class alternative in that pipeline. docs.nvidia
Below is what this means and what you can realistically do.
1. Why you’re blocked
- NuRec’s output is a 3D reconstruction: a USDZ package with a USD scene graph, reconstruction checkpoint, and trajectory JSON. docs.nvidia
- The docs explicitly say: “An OpenDrive (XODR) map might also be included in the USDZ package for use in simulation tasks like traffic modeling and scenario editing, but it is not required to run NuRec.” docs.nvidia
- CARLA (and thus CARLA‑NuRec) uses OpenDRIVE as its authoritative road network and lane topology representation;
map.xodr tells CARLA where lanes are, how junctions connect, speeds, etc. carla.readthedocs
- If your particular NCORE→NuRec→3DGRUT flow produced a USDZ without an embedded XODR, CARLA‑NuRec has no way to infer lanes, so it can’t do road‑aware rendering or traffic‑aware simulation.
So your observation—“geometry but no map semantics, thus CARLA‑NuRec won’t run correctly”—is exactly how the current stack behaves.
2. Is there a tool to generate map.xodr from NCORE/USDZ?
Short answer: no direct, supported pipeline from NuRec USDZ to OpenDRIVE exists today.
The common, supported OpenDRIVE generation flows are:
- Author map in RoadRunner, then export
.xodr + meshes (FBX) and import into CARLA. carla.readthedocs
- Convert OpenStreetMap (OSM) → OpenDRIVE with tools like
osm-to-xodr (SUMO netconvert wrapper) or similar OSM→XODR converters. github
Those workflows start from structured map data (RoadRunner scene or OSM), not from an arbitrary reconstructed USD scene. There’s no official NuRec→XODR generator documented.
You could, in principle, build your own:
- Take the USDZ scene from NuRec / 3DGRUT.
- Detect road surfaces and lane markings (semantic segmentation on the mesh / textures).
- Fit lane centerlines and road geometries.
- Export those as OpenDRIVE primitives (lines, arcs, clothoids) and connectivity. gdal
But that is a substantial research/engineering project, not a “foundational tool” that exists today.
3. Is USDZ‑only support planned in CARLA‑NuRec?
From the public CARLA 0.9.16 pre‑release note:
- CARLA advertises “experimental support for NVIDIA NuRec 25.07” and “digital twins” workflows. carla
- However, the CARLA ecosystem overall is still built around OpenDRIVE maps; they even show a mode where you can run a world from only an XODR file, with mesh auto‑generated from the road network. youtube
Nothing published so far indicates that CARLA‑NuRec will drop or sidestep OpenDRIVE; the experimental NuRec support still assumes XODR when you want traffic, routing, or lane‑level semantics. carla
So unless the CARLA team explicitly announces a “pure USD/mesh NuRec mode with no OpenDRIVE requirement,” you should assume:
- USDZ is for geometry/appearance.
- XODR is still required for any road‑aware behavior in CARLA. gdal
4. Practical workarounds you can use now
Given what exists today, you have three realistic paths:
4.1. Use a separate map authoring pipeline to create XODR
Treat NuRec/3DGRUT’s USDZ as visual reference and create a CARLA‑compliant map in one of the supported tools:
- Reconstruct or approximate the same road network in RoadRunner, export
.xodr + FBX, then integrate that as a CARLA map, layering your NuRec‑derived assets (buildings, props) on top. carla.readthedocs
- If your NCORE scenes correspond to real‑world locations with OSM coverage, use OSM→XODR pipelines (
osm-to-xodr, netconvert, or Apollo OpenDRIVE converters) to produce a map.xodr and bring it into CARLA, while using the USDZ only for rendering detail aligned to that road network. libraries
This is more manual, but it lets you keep the CARLA‑NuRec flow unchanged and only “patch in” the missing map.
4.2. Use OpenDRIVE‑only CARLA mode and treat USDZ as a visual overlay
CARLA has an “OpenDRIVE‑only” mode where it creates the road mesh and driving environment directly from XODR. You could: youtube
- Pick or author an XODR map that closely matches your NCORE scene footprint.
- Use NuRec’s USDZ simply as extra geometry (e.g., buildings, foliage) aligned with that road network, rather than trying to treat NuRec as the primary map source.
You still need an XODR map, but it becomes less critical for photographic alignment and more for semantics plus traffic behavior.
4.3. Experimental: build your own USD→XODR extractor
If you’re willing to experiment and your research calls for end‑to‑end automation:
-
Use the USDZ’s semantic or material info to detect road surfaces and lane markings. docs.nvidia
-
Extract centerlines (e.g., via skeletonization of the road surface or line detection on textures) and fit them with:
- Lines (zero curvature),
- Arcs (constant curvature), and
- Clothoids (linearly changing curvature), as recommended in OpenDRIVE conversion discussions. community.safe
-
Convert those into OpenDRIVE <geometry> and <laneSection> elements, respecting continuity and junction connectivity. community.safe
This is doable but non‑trivial and will require careful validation in CARLA.
5. Direct answers
- Is there an existing pipeline or tool to generate map.xodr from NCORE or USDZ data?
Not at this time. Public docs and community discussions show no official or widely used pipeline that converts NuRec/3DGRUT USDZ or NCORE scenes directly into OpenDRIVE. Existing XODR generation tools work from RoadRunner or OSM/other GIS sources, not from USDZ. github
- Is support for USDZ‑only scenes (without OpenDRIVE) planned in the CARLA‑NuRec pipeline?
CARLA 0.9.16’s “experimental NuRec support” still assumes OpenDRIVE for driving‑related tasks; USDZ is for geometry, with XODR “possibly included” for traffic modeling. There is no public statement that CARLA‑NuRec will support fully road‑semantic simulation from USDZ alone, without XODR. carla
If you can share whether your NCORE scenes correspond to real cities (so we might use OSM) or are synthetic, I can sketch a concrete step‑by‑step path—either RoadRunner‑based authoring or an OSM→XODR + alignment workflow—that will give you a usable map.xodr for this pipeline.