[Isaac Sim 6.0.1] Solid-state OmniLidar always renders emitterState:s001 and does not advance additional emitter states

[Egoist0319]

Description

I am trying to model a non-repetitive solid-state LiDAR pattern in Isaac Sim
6.0.1 by authoring multiple
OmniSensorGenericLidarCoreEmitterStateAPI instances on one OmniLidar prim.
The additional states are present and accepted by the sensor checker, but RTX
continues to render only emitterState:s001.

This first appeared in a Livox Avia profile with 40 states. I then reduced the
test to one OmniLidar, two states, 32 emitters, no ROS, no robot, no
articulation, no external scan data, and a closed box around the sensor. The two
states use clearly separated azimuths (-20 degrees and +20 degrees), so the
active state can be identified directly from the spherical GMO output.

Environment

• Isaac Sim 6.0.1 standalone
• isaacsim.sensors.experimental.rtx 1.4.6
• omni.sensors.nv.lidar 3.0.0
• Ubuntu 24.04.4 LTS
• NVIDIA GeForce RTX 3090 24 GB
• NVIDIA driver 595.84
• Single-GPU rendering (/renderer/multiGpu/enabled=false)
• Motion BVH enabled

What I configured and tested

• Created an OmniLidar using the current experimental RTX LiDAR API.
• Applied OmniSensorGenericLidarCoreAPI and two emitter-state API instances,
  s001 and s002, before creating the LidarSensor render product.
• Authored complete, equal-length arrays for azimuthDeg, elevationDeg,
  fireTimeNs, channelId, and bank in both states.
• Used scanType=solidState, stateResolutionStep=1,
  scanRateBaseHz=10, patternFiringRateHz=10, and
  omni:sensor:tickRate=10.
• Used accumulateOutputs=true and automatic Writer scheduling, following the
  current RTX LiDAR and multi-tick documentation.
• Used the IDEALIZED ray type with zero divergence so that every ray has a
  valid geometric return in the closed test scene.
• Confirmed that SensorCheckerUtil.validateParams() returns no error and its
  validated parameters contain both s001 and s002, including all five
  emitter arrays.
• Repeated the same test with the 40-state solid-state profile. All 40 API
  instances were present and accepted.
• Tested custom scalar attributes named
  omni:sensor:Core:emitterStateCount and
  omni:sensor:emitterStateCount, because the LiDAR extension documentation
  describes emitterStateCount; neither changed the behavior.
• Tested a higher legal patternFiringRateHz with matching in-period
  fireTimeNs; it did not activate the second state and is not the documented
  recommendation for solid-state LiDAR anyway.

Actual result

With the two-state profile, eight consecutive complete 10 Hz GMO outputs all
matched the -20 degree directions from s001 (direction RMSE approximately
0.02 to 0.05 degrees). No output used the +20 degree directions from s002.

With the 40-state profile, six consecutive complete outputs also all matched
s001 (approximately 0.07 degree direction RMSE). There were no invalid GMO
buffers and no sensor-checker errors.

Changing the arrays of the active s001 instance at runtime changes the
rendered directions, which confirms that the angle data itself is valid.
However, repeatedly editing those arrays causes RTX profile rebuilds, long
stalls, file-descriptor exhaustion, and native crashes, so runtime rewriting is
not a usable workaround.

Expected result

With two emitter states and stateResolutionStep=1, the sensor should advance
between s001 and s002 according to the documented emitter-state mechanism.
For the full profile, the 40 states should advance without changing USD
attributes during simulation.

Documentation/schema inconsistency found while investigating

The installed omni.sensors.nv.lidar documentation says that
emitterStateCount is the number of different emitter states and must be
changed for multiple states. The public 107.3.1
OmniSensorGenericLidarCoreAPI schema contains stateResolutionStep and the
multi-apply emitter-state API, but it does not define an
emitterStateCount USD attribute.

The Isaac Sim 6.0.1 JSON-to-USDA converter reads emitterStateCount from JSON,
but only copies top-level values that have a matching USD attribute, so the
state count is not authored. Its API-creation loop also skips JSON state indices
0 and 1; the Core schema supplies s001, but not s002, so s002 is absent
unless it is explicitly repaired after conversion.

The schema also exposes emitterStatesFile, but the installed schema and LiDAR
extension documentation both state that this field is not supported yet.

Questions

1. What is the supported way in Isaac Sim 6.0.1 to declare the number of
   emitter states on an OmniLidar USD prim?
2. Is automatic cycling of multiple emitter states supported for
   scanType=solidState in 6.0.1?
3. Is the missing emitterStateCount schema attribute, the converter behavior,
   or the fixed s001 runtime behavior a known defect?
4. If automatic cycling is not currently supported, is there a safe supported
   mechanism for changing solid-state firing patterns without rebuilding the
   RTX sensor profile at runtime?

I can provide the generated USD, full logs, and exact parameter values if the
sensor team needs them, but the same behavior occurs in the reduced 32-emitter,
two-state test.

[zwdoescode]

I reproduced the fixed-first-state behavior with a generated two-state, 32-emitter scene on a local Isaac Sim 6.0.1-rc.7 source build, using isaacsim.sensors.experimental.rtx 1.4.6 and omni.sensors.nv.lidar 3.0.0.

Both states passed SensorCheckerUtil. After the initial partial output, eleven consecutive full scans used only s001. Swapping the two patterns before startup changed the output to the new s001; bypassing LidarSensor and reading GMO through a Replicator writer gave the same result. A generated 40-state case behaved the same way.

There are two separate problems:

• The JSON converter skips creating s002. Changing if i < 2: to if i < 1: preserves that state's arrays; I verified the converted values. This repairs conversion, but does not fix automatic cycling.
• Correctly authored solid-state emitter states still do not advance in the tested runtime. Neither custom emitterStateCount attribute enabled cycling.

The USD authoring mechanism is the multi-apply emitter-state API, as shown in the LiDAR extension documentation. The separate emitterStateCount instruction needs clarification: the schema does not expose that scalar, and adding a custom attribute is not a supported switch for this behavior.

I will create an internal ticket for your issue. I have not verified a supported way to change the live solid-state pattern without rebuilding the profile. emitterStatesFile is documented as unsupported, so I would not suggest it as a workaround.

Internal ticket: 6758724

[Egoist0319]

Thank you for reproducing this and for separating the converter issue from the runtime state-advancement issue.
Your findings confirm that the multi-apply emitter-state API is the correct USD authoring mechanism, while the current solid-state RTX runtime still remains on s001 even when the additional states are authored correctly and accepted by SensorCheckerUtil.
I will keep runtime pattern rewriting disabled for now because rebuilding the active profile during simulation caused stalls and native crashes in my tests.
Could you please confirm whether automatic emitter-state advancement for scanType=solidState is intended to be supported in Isaac Sim 6.0.1? If possible, please also update this issue with the internal ticket reference or the release/version containing the eventual fix.
If the team identifies a supported temporary method for changing solid-state firing patterns without rebuilding the live RTX profile, I would also appreciate that guidance.
Thanks again for investigating this.