OVRTX ovstage asset updates retain stale resource-resolution paths

[ruziniuuuuu]

Summary

OVRTXRenderer.update_scene_attribute(..., is_asset_path=True) encodes runtime
asset updates as a fixed-width uint64x2 token pair. On the ovstage path this
does not correctly replace the authored/resolved state of a USD-populated asset.

For an MDL shader switched from:

/materials/Stone/Devil_Black.mdl :: Devil_Black

to:

/materials/Wood/Wood_Tiles_Poplar.mdl :: Wood_Tiles_Poplar

OVRTX loads the new module content but resolves its relative textures beneath
the old module directory, for example:

/materials/Stone/textures/poplar_diff.jpg

instead of the existing authored path:

/materials/Wood/textures/poplar_diff.jpg

OVRTX then emits Texture upload failed for each texture. Physics and rollout
continue, but the material is incomplete.

Environment

• Isaac Lab: downstream branch based on develop, with runtime scene-attribute updates
• isaaclab-ov: 0.10.4
• ovrtx: 0.4.0.346409
• ovstage: 0.1.0.346039
• OVRTX ovstage path enabled
• CUDA renderer

Reproduction

1. Author a shader or light with an absolute asset-valued attribute.
2. Load and attach the USD stage through OVRTX's ovstage integration.
3. Call RenderContext.update_scene_attribute with a different absolute path
   and is_asset_path=True.
4. Advance the write floor and render.

The source assets and textures exist and are independently decodable. Keeping
the asset path unchanged removes the errors.

The lower-level storage mismatch has a standalone ovstage reproduction in
NVIDIA-Omniverse/ovstage#1: USD population creates a fixed-width uint64x2
column, while the documented runtime asset representation is a ragged UTF-8 row
with AttributeSemantic.ASSET_STRING. A direct ASSET_STRING update fails
because ovstage does not allow changing an existing column's type.

Expected behavior

is_asset_path=True should preserve the USD asset semantic and replace both
the authored path and resource-resolution context, so OVRTX resolves relative
resources from the new asset.

Validated fix

For the ovstage backend:

1. Validate that values are absolute strings.
2. Delete only the target asset attribute at the current ordinal.
3. Recreate it at the same ordinal as UTF-8 byte rows using
   AttributeSemantic.ASSET_STRING.
4. Keep the write floor below that ordinal until the normal render step.

The regression test should assert the delete/recreate sequence, byte-row
payload, and ASSET_STRING semantic.

A real downstream rollout using viewer=rtx, renderer=ovrtx, runtime HDRI
randomization, and runtime MDL module switching then completes successfully with
no Texture upload failed or INVALID_ARGUMENT messages.

[pbarejko]

Hi @ruziniuuuuu,

Would you happen to have a minimal repo case of the problem you are trying to solve? I read the repro steps of the issue but it contains instruction that include your solution? I am trying to understand if we are patching some problem that could be solved upstream. I am talking about textures problem.

Additionally, I find some disconnect between what you describe in this ticket vs what you have in your PR. I conclude from your PR that you'd want to have a hook that allows you to update some attributes on some primitives. You also report a problem related to texture loading. Can you please explain how your approach from PR solves the problem with texture loading? Can you also elaborate about your workflow? How do you use update_scene_attribute? I see you added it on RenderContext as a function, but how is it being used?