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
Copy file name to clipboardExpand all lines: DESIGN.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -852,8 +852,8 @@ Downstream tools can parse these catalogs to:
852
852
853
853
**Kinematic trees.***(Resolved)* The `Asset` struct now contains an optional `std::unique_ptr<KinematicTree> kinematic_tree` field. `KinematicTree` holds links, joints, actuators, and sensors with name-based indexing. Option (b) was chosen for type safety. URDF and MJCF importers parse articulated files directly into this representation, and the `ArticulationStage` merges data from source files, sidecar metadata, and YAML config.
854
854
855
-
**Material library.** The physics stage uses a single `default_material` from config. Real pipelines need a material lookup table (wood, steel, plastic, rubber, ceramic) that maps to density + frictionvalues. Should this be a separate YAML file, embedded in the main config, or an adapter that reads from a database?
855
+
**Material library.***(Resolved)*The `PhysicsStage` supports a `lookup` mode backed by `MaterialLibrary::from_file()`, which loads a YAML material database (`data/materials.yaml`). Materials map names to density, friction, and restitution values. The library is a separate YAML file installed to `${CMAKE_INSTALL_DATADIR}/simforge`.
856
856
857
-
**Incremental processing.**Currently the pipeline processes all discovered assets every run. Should we support only processing assets newer than their catalog entry? This is essentially `make`-style dependency tracking. Important for large asset libraries but adds complexity.
857
+
**Incremental processing.***(Resolved)* The pipeline computes SHA-256 content hashes (source file + stage config) and writes them to `.catalog.json` files. On subsequent runs, `should_skip_asset()` compares hashes and skips unchanged assets unless `--force`is set. This provides `make`-style dependency tracking with minimal overhead.
858
858
859
859
**Plugin loading.** Currently adapters are compiled in via CMake flags. Should we support dynamic plugin loading (`dlopen` / shared libraries) so users can add adapters without recompiling simforge? This enables a richer ecosystem but complicates distribution.
0 commit comments