[Isaac Sim 6.0.1] RTX-Real-Time viewport black after scene load, and some MDL materials never render (regression from 5.1.0)

[MohammadrezaFar]

Isaac Sim Version

[x] 6.0.1
[ ] 6.0.0
[ ] 5.1.0
[ ] 5.0.0
[ ] 4.5.0
[ ] 4.2.0
[ ] 4.1.0
[ ] 4.0.0
[ ] 4.5.0
[ ] 2023.1.1
[ ] 2023.1.0-hotfix.1
[ ] Other (please specify):

Operating System

[x] Ubuntu 24.04
[ ] Ubuntu 22.04
[ ] Ubuntu 20.04
[ ] Windows 11
[ ] Windows 10
[ ] Other (please specify):

GPU Information

• GPU 1Model: NVIDIA GeForce RTX 4070 (AD104)Driver Version: nvidia (Generic kernel driver name)
• GPU 2Model: NVIDIA GeForce RTX 3080 Lite Hash Rate (GA102)Driver Version: nvidia (Generic kernel driver name)
• Integrated Server VideoModel: ASPEED Graphics FamilyDriver Version: ast

Topic Description

Summary

On Isaac Sim 6.0.1, running headless in Docker with the WebRTC streaming client, I'm seeing two related rendering issues that did not occur on 5.1.0 with the identical hardware/driver/Docker setup:

1. After loading a scene, the viewport is sometimes completely black in RTX-Real-Time 2.0. Switching to RTX-Minimal or RTX-Interactive (Path Tracing) and back to RTX-Real-Time usually — but not always — resolves it.
2. Some MDL materials load into the stage and are assigned to a mesh (visible/correct in the property panel), but never actually render — the mesh stays visually unaffected regardless of which render mode I'm in. This happens with both local .mdl files and materials pulled from the online vMaterials library (tested specifically with Water_Murky_Perlinwaves.mdl and Water_Blue_Ocean_Perlinwaves.mdl), and regardless of where the asset is physically located.

System / Environment

Same setup as my other 6.0.1 report on the Stop-button segfault issue — repeating the key details:

• Isaac Sim: 6.0.1, container image nvcr.io/nvidia/isaac-sim:6.0.1, headless, launched via isaacsim.exp.full.streaming.kit
• Client: Isaac Sim WebRTC Streaming Client
• OS: Ubuntu 24.04.3 LTS, kernel 6.8.0-124-generic
• CPU: AMD EPYC 7401P 24-Core (48 logical cores), 128 GB RAM
• GPU: dual GPU, driver 580.82.07, CUDA 13.0, Vulkan, --/renderer/multiGpu/enabled=true

|---------------------------------------------------------------------------------------------|
| Driver Version: 580.82.07     | Graphics API: Vulkan
|=============================================================================================|
| GPU | Name                             | Active | LDA | GPU Memory | Vendor-ID | LUID       |
|     |                                  |        |     |            | Device-ID | UUID       |
|     |                                  |        |     |            | Bus-ID    |            |
|---------------------------------------------------------------------------------------------|
| 0   | NVIDIA GeForce RTX 4070          | Yes: 0 |     | 12528   MB | 10de      | 0          |
|     |                                  |        |     |            | 2786      | 32c05a89.. |
|     |                                  |        |     |            | 21        |            |
|---------------------------------------------------------------------------------------------|
| 1   | NVIDIA GeForce RTX 3080          | Yes: 1 |     | 10486   MB | 10de      | 0          |
|     |                                  |        |     |            | 2216      | bb59c536.. |
|     |                                  |        |     |            | 42        |            |
|=============================================================================================|

This exact dual-GPU configuration ran fine on Isaac Sim 5.1.0 for a long time on the same server before I upgraded.

What I've observed so far

• The black-viewport-after-load issue is intermittent in exactly when it appears, but the renderer-switch workaround is consistent when it does.
• The invisible-material issue does not get fixed by the renderer-switch workaround — I've tried all three render modes with the same material bound and it stays invisible regardless.
• In one captured log, right around the point where I switched render modes to un-black the viewport, I saw repeated warnings of the form:

  HydraEngineManager::findEngineUidImpl - can't find hydra engine for name: 'rtx'
  

  fired several times in a row. I haven't yet confirmed whether this is the actual cause or just a coincidentally-timed symptom, but it's the only anomaly I've found in the logs around these events so far.
• My container currently does not persist the Kit/shader/material caches (~/.local/share/ov/data, ~/.cache/ov, ~/.cache/nvidia/GLCache, ~/.nv/ComputeCache are not volume-mounted), so every container restart starts with a fully cold cache. I haven't yet tested whether a warm cache changes either symptom.
• This is a separate issue from a Stop-button segfault I've also hit on 6.0.1 (reported separately) — disabling GPU Dynamics, which fixes that crash, does not appear related to this rendering issue (not yet fully cross-tested, but the two symptoms don't correlate in my logs).

What I haven't isolated yet

Unlike the Stop-button crash, I haven't yet narrowed this down to a minimal, reliable repro — it's less deterministic in exactly when it triggers. Before/while this is being looked at, I plan to test:

• Whether a persistent/warm shader and material cache changes the frequency of the black-screen-on-load issue.
• Whether disabling multi-GPU rendering (--/renderer/multiGpu/enabled=false) has any effect on either symptom.
• Whether the invisible-material issue reproduces with a purely local, offline .mdl file with no network dependency at all, to rule out any asset-fetch timing issue.

Question for NVIDIA / the community

• Has anyone seen HydraEngineManager::findEngineUidImpl - can't find hydra engine for name: 'rtx' in connection with a black RTX-Real-Time viewport after scene load, in a headless/streaming Docker setup?
• Is there a known issue in 6.0.1 with MDL materials failing to bind to the RTX render delegate in some cases, independent of which render mode is active?
• Any pointers on what to check next, or additional logging/settings to enable, would be very welcome. Happy to run further tests and share logs — I have a reliable Docker-based environment I can iterate in quickly.

[PeterL-NV]

Hi, here's what would suggest to narrow down the issue:

1. Disabling multi-GPU rendering (--/renderer/multiGpu/enabled=false) as you listed
2. Update your driver to 595 as suggested here

[PeterL-NV]

Hi, we haven't heard back since our suggestions to disable multi-GPU rendering (--/renderer/multiGpu/enabled=false) and update your driver to 595. We'll close this for now, but if you're still hitting this, you can reopen it directly using the 'Reopen issue' button on GitHub. If someone else is affected, please open a new issue and reference this one.