Fix quadratic startup scaling in NewtonSiteFrameView for body-mounted frames

[r-schmitt]

Description

Summary
Camera-heavy Newton scenes exhibited a severe environment-initialization time spike that scaled quadratically with num_envs. On an RTX PRO 6000 (Blackwell), the Isaac-Lift-KukaAllegro-Camera benchmark at 8192 envs spent ~29 minutes in "Simulation Start" alone.

The root cause is an O(num_envs²) regex loop in NewtonSiteFrameView._initialize_from_specs: for a frame that resolves to a per-environment body path (e.g. a body-mounted camera), the view issued one resolve_matching_names call per environment, and each call regex-scans the entire Newton body_label list (which itself grows with num_envs).

This PR fast-paths literal body paths through an exact dict lookup built once, keeping the common per-environment case linear while preserving the regex fallback for genuine patterns (e.g. the cloned .* pattern).

How the slow path is reached
The spike only appears when a frame/sensor is anchored to a physics body that is replicated per environment. The duo_camera preset for Isaac-Lift-KukaAllegro-Camera includes exactly such a camera, mounted on the robot hand:

• /World/envs/env_.*/Camera — anchored at the env root (a static frame)

• /World/envs/env_.*/Robot/ee_link/palm_link/Camera — anchored to the palm_link rigid body

Call chain during env creation:

gym.make(...)
└─ sim.reset() # Timer: "simulation_start"
└─ NewtonManager.start_simulation()
└─ dispatch_event(PhysicsEvent.PHYSICS_READY)
└─ Camera._initialize_impl() # one per camera sensor
└─ FrameView(cfg.prim_path) # == NewtonSiteFrameView
└─ _initialize_from_specs(model)
└─ for each of num_envs specs:
resolve_matching_names(, body_labels) # scans ALL labels

The env-root camera resolves to body_patterns is None and takes the cheap branch (~174 ms at 2048 envs).

The body-mounted camera expands to one concrete body path per environment. Each is regex-matched against all body labels:

At 2048 envs: resolve_matching_names called 2048 times, each scanning 65,536 body labels → 70,136 ms.

Because both the number of calls and the label-list length grow with num_envs, cost is O(num_envs²).

Fixes

In _initialize_from_specs:

• Build label_to_index = {label: idx for idx, label in enumerate(body_labels)} once (O(num_bodies)).

• For each body pattern, if it contains no regex metacharacters, resolve it with an O(1) dict lookup; otherwise fall back to resolve_matching_names.

This is behavior-preserving: literal paths previously matched exactly one label via regex full-match, which the dict lookup reproduces; patterns with metacharacters (.*+?|^$) still use the regex scan.

using benchmark_non_rl, Isaac-Lift-KukaAllegro-Camera, preset cube,duo_camera,newton,newton_renderer,rgb64 (matching the benchmark runs that identified the issue) the fix produced the following results:

Simulation Start Time: before 1729 seconds, after 19 seconds
Task Creation and Start Time: before 1763 seconds, after 59 seconds

note the cost is CPU-bound (python regex) so it is not GPU specific

Type of change

• Bug fix (non-breaking change which fixes an issue)

Checklist

• I have read and understood the contribution guidelines
• I have run the pre-commit checks with ./isaaclab.sh --format
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• I have updated the changelog and the corresponding version in the extension's config/extension.toml file
• I have added my name to the CONTRIBUTORS.md or my name already exists there

[greptile-apps]

Greptile Summary

This PR fixes an O(num_envs²) startup-time bottleneck in NewtonSiteFrameView._initialize_from_specs. When a sensor is anchored to a per-environment physics body (e.g. a hand-mounted camera), the original code called resolve_matching_names once per environment, each call doing a regex scan across all body labels, making both the call count and the scan length grow with num_envs.

• Introduces a label_to_index dict built once from all Newton body labels; literal body patterns (no regex metacharacters) are resolved in O(1) via dict lookup, while genuine regex patterns (containing ., *, [, etc.) still fall back to the existing resolve_matching_names path.
• Adds a module-level _REGEX_TOKENS frozenset and _has_regex_tokens helper to distinguish literal USD paths from regex expressions.
• Adds two changelog fragments: one for the Newton frame-view fix and one for a CameraCfg default-renderer change whose code already exists in the repository (not introduced by this PR's diff).

Confidence Score: 4/5

The Newton frame-view change is safe to merge; the logic is correct and behavior-preserving for all pattern types.

The core fix is well-reasoned and correctly implemented: the is not None guard handles index 0, the fallback to resolve_matching_names fires whenever the dict lookup yields nothing, and genuine regex patterns are routed to the existing scan unchanged. The only open question is the rschmitt_default_cameracfg_renderer.rst changelog entry, which documents code not present in this PR's diff.

source/isaaclab/changelog.d/rschmitt_default_cameracfg_renderer.rst — documents CameraCfg/renderer changes already in the codebase, not introduced by this PR.

Important Files Changed

Filename	Overview
source/isaaclab_newton/isaaclab_newton/sim/views/newton_site_frame_view.py	Core performance fix: builds a label→index dict once and uses O(1) exact lookup for literal body patterns, falling back to the existing regex scan only when needed. Logic is correct, index-0 is handled safely via is not None, and non-literal patterns fall back properly.
source/isaaclab_newton/changelog.d/rschmitt-frameview-site-init-scaling.rst	Changelog entry accurately describes the O(num_envs²) → O(num_envs) fix for the Newton site frame view.
source/isaaclab/changelog.d/rschmitt_default_cameracfg_renderer.rst	Changelog entry for CameraCfg/renderer changes not present in this PR's code diff — the documented API already exists in the codebase. May be a missing-changelog backfill or accidental leftover.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["_initialize_from_specs(model)"] --> B["Build label_to_index dict once O(num_bodies)"]
    B --> C["For each body_pattern"]
    C --> D{"_has_regex_tokens?"}
    D -- No --> E["label_to_index.get(body_pattern)"]
    E -- Found --> F["matched_indices = [exact_index]"]
    E -- None --> G["resolve_matching_names() O(num_bodies)"]
    D -- Yes --> G
    F --> H["Append body_idx, xform, scale"]
    G --> H
    H --> I{"matched_indices empty?"}
    I -- Yes --> J["raise ValueError"]
    I -- No --> C

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A["_initialize_from_specs(model)"] --> B["Build label_to_index dict once O(num_bodies)"]
    B --> C["For each body_pattern"]
    C --> D{"_has_regex_tokens?"}
    D -- No --> E["label_to_index.get(body_pattern)"]
    E -- Found --> F["matched_indices = [exact_index]"]
    E -- None --> G["resolve_matching_names() O(num_bodies)"]
    D -- Yes --> G
    F --> H["Append body_idx, xform, scale"]
    G --> H
    H --> I{"matched_indices empty?"}
    I -- Yes --> J["raise ValueError"]
    I -- No --> C

Loading

_{Reviews (1): Last reviewed commit: "fix initialize from spec scaling issues" | Re-trigger Greptile}