You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
usdGeospatial: shrinkwrap the C++ Hydra plugin into build_usd.py (--usdGeospatial), cross-platform
Make the usdGeospatialSceneIndex example an opt-in, cross-platform build like
hdParticleField -- one build_usd.py flag builds PROJ and the plugin, replacing
the Linux-only shell scripts. Validated on Linux and Windows (MSVC).
Build:
- build_usd.py: --usdGeospatial builds PROJ (+ its SQLite3 dependency) as opt-in
third-party deps, then passes -DPXR_ENABLE_GEOSPATIAL_SUPPORT to the USD build.
- cmake/defaults: PXR_ENABLE_GEOSPATIAL_SUPPORT option + find_package(PROJ).
- Register the example under extras/usd/examples (gated on the flag + imaging);
fix its CMakeLists: add the missing geospatialAPISchemaAdapter/geospatialSchema
sources, define USDGEOSPATIAL_SI_EXPORTS, DISABLE_PRECOMPILED_HEADERS, link
PROJ::proj.
Parity as a ctest:
- run_parity.py + pxr_register_test(testUsdGeospatialParity): CRS engine 9/9,
stage resolver 30/30, Hydra scene index 30/30, stage-free auto-insert 30/30 --
all 0.0 mm. dumpHydraXforms built for the runtime_parity figure.
- dump_oracle.py auto-converts the committed railway asset so the oracle is the
full 30-row set.
Cross-platform figure/doc tooling:
- fig_runtime_parity.py / render_figures.py: portable dumper + tsv paths
(GEO_HYDRA_TSV / GEO_HYDRA_DUMPER, system temp, os.pathsep) -- no /tmp or
/usr/share/proj hardcodes.
- docs/build_deck.py: read the README as UTF-8 (Windows).
- probe_autoinsert.py: drop dead Hd/HdGp imports.
Docs (README is the base artifact; deck derives from it):
- README build sections -> the cross-platform build + ctest; add a
reproducibility slide; regenerate the deck PDF.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
option(PXR_ENABLE_GEOSPATIAL_SUPPORT"Enable geospatial (PROJ) support, used by the usdGeospatialSceneIndex example"OFF)
38
39
option(PXR_ENABLE_NAMESPACES"Enable C++ namespaces."ON)
39
40
option(PXR_PREFER_SAFETY_OVER_SPEED
40
41
"Enable certain checks designed to avoid crashes or out-of-bounds memory reads with malformed input files. These checks may negatively impact performance."
Copy file name to clipboardExpand all lines: extras/usd/examples/usdGeospatial/README.md
+24-11Lines changed: 24 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -426,6 +426,14 @@ The takeaway is the schema claim itself: **the schema is the contract; the behav
426
426
third runtime (OpenExec, a GPU / cuProj engine, an Omniverse runtime) plugs into the same seam and
427
427
is held to the same oracle.
428
428
429
+
<!-- slide:text eyebrow="Reproducible · cross-platform" title="The second runtime builds like any USD example" body="`build_usd.py --usdGeospatial` fetches and builds PROJ, then the C++ Hydra plugin, behind one opt-in flag — the `hdParticleField` pattern, no bespoke setup. | Parity is a `ctest` (`testUsdGeospatialParity`): CRS engine + stage resolver + Hydra scene index + stage-free auto-insert, all 0.0 mm. | Validated on Linux **and** Windows — the contract builds twice, the same way, on two platforms." -->
430
+
431
+
And it builds like any other OpenUSD example: `build_usd.py --usdGeospatial --examples` fetches and
432
+
builds PROJ and the C++ Hydra plugin behind one opt-in flag — the same shape as `hdParticleField`,
433
+
on Linux and Windows alike — and `ctest -R testUsdGeospatialParity` runs the whole parity proof
434
+
(CRS engine, stage resolver, Hydra scene index, and the stage-free auto-insert path). The second
435
+
runtime isn't a Linux-only lab artifact; it's a normal, opt-in part of the build.
436
+
429
437
### Where the Python reference runtime sits (no exact precedent — by design)
430
438
431
439
<!-- slide:text eyebrow="No exact precedent — by design" title="Where the Python reference runtime sits" body="It's the codeless schema's **conformance oracle** — 'given this stage, where does each prim end up?' — pinned to closed-form geodesy, that compliant implementations should match. | NOT the specification: the normative behavior belongs in **prose** (proposed into the Esri proposal); the Python is the oracle that expresses it, not the source of truth. | NOT proposed for USD core, NOT a runtime dependency, NOT Python-in-the-render-loop, NOT the prescribed consumer. | Precedent: AOUSD's core-spec-supplemental — Python sample impls + a compliance framework, spec normative and impl illustrative — is exactly this shape." -->
@@ -474,17 +482,18 @@ Every test is openable and runnable; each has a real negative control or an inde
474
482
neutral scene has zero xformOps).
475
483
-`render_figures.py` — the coherence figure self-asserts sub-mm co-registration; `fig_runtime_parity`
476
484
fails the build if Python-vs-Hydra disagreement exceeds 1 mm.
477
-
-`../usdGeospatialSceneIndex/run_parity.sh` — the compiled C++ scene index: CRS engine 9/9, stage
478
-
resolver 30/30, Hydra SI via `HdXformSchema` 30/30 — all 0.0 mm; negative control: stock Hydra
479
-
puts georef prims at the origin. `testHydraAutoParity` adds the stage-free auto-insert path (30/30).
485
+
-`ctest -R testUsdGeospatialParity` (cross-platform; also `run_parity.sh`) — the compiled C++ scene
486
+
index: CRS engine 9/9, stage resolver 30/30, Hydra SI via `HdXformSchema` 30/30 — all 0.0 mm;
487
+
negative control: stock Hydra puts georef prims at the origin. `testHydraAutoParity` adds the
488
+
stage-free auto-insert path (30/30).
480
489
-`pxr/usd/usdGeospatial/regen-schema.sh --check` — schema resources are in sync.
481
490
482
491
### Running — two paths
483
492
484
-
**The codeless Python path (no external renderer):**
493
+
**The codeless Python path (no external renderer)** — any Python with `pxr` (a usd-core wheel or a
0 commit comments