Omni.ui.phython is throwing an error when loading many of the Demo Physic Scenes

Hello. I am experiencing an issue where omni.ui.phython is throwing an error when loading many of the Demo Physic Scenes.

Steps to reproduce:

  1. Open Code 2023.1.1
  2. Open the Physics Demo Scenes extension
  3. Load the Cloth Deck Chair scene

(this happens to many other Demo Physic Scenes too)

Notice the following error:

2024-04-05 17:57:47 [Error] [omni.ui.python] AssertionError: Empty string in setting /physics/demoAssetsPath!
2024-04-05 17:57:47 [Error] [omni.ui.python]
2024-04-05 17:57:47 [Error] [omni.ui.python] At:
2024-04-05 17:57:47 [Error] [omni.ui.python] d:/ getdemoassetpath
2024-04-05 17:57:47 [Error] [omni.ui.python] d:/ _init
2024-04-05 17:57:47 [Error] [omni.ui.python] d:/ new_stage
2024-04-05 17:57:47 [Error] [omni.ui.python] d:/
2024-04-05 17:57:47 [Error] [omni.ui.python] d:/

Can you tell me exactly where you loaded the deck chair scene from ? Was it from your LOCALHOST Nucleus mount or from our Examples Browser, or from the Physics Demo pack ? Some of them may be out of date. Does it work fine inside of USD Composer ?

hi @und_miller, can you please check if this file



physics.demoAssetsPath = “

in it? Since it seems like if the path to external demo assets is for some reason reset to a blank string.

Sorry for the delay. I was out on vacation.

This is what I have:

# physics demo asset path setting
physics.demoAssetsPath = ""

This works in 2022.3.3

So, this is probably related to the beta release of CODE.

The things is that I downloaded 2023.1.1 from the Launcher and it seemed to run fine for me locally, hmm. Can you try redownloading 2023.1.1?

demoAssetsPath is not a persistent setting, so the issue shouldn’t be in your local setting, but you can also try overriding the path from the command line, that should at least take precedence over any hidden overrides:

.\omni.code.bat --/physics/demoAssetsPath=“

Can you also try running the following script from the Script Editor from the Window menu to see what the setting is actually set to?:

from carb.settings import get_settings

what does it output?

I switched to a new computer since the original post, so everything is freshly installed. However, I am still experiencing the same issue.

I ran the command you provided and opened the Cloth Deck Chair scene without any issues. See the output of the snippet below.

Interestingly, after running the command above, when I attempted to open the same scene via the Omni Launcher it loaded seamlessly this time.

Can I ask two questions just to understand your workflow. Why Code and Not USD Composer? Why this particular demo ? Are you just trying to prove Physics is broken (which it is not) ? Some of the older demo files may have issues. There are so many great demos listed in the USD Composer Examples tab.

I am asking so we can help. If you are interested in learning and testing physics, I would encourage you to try your own physics test from scratch and let us know how it is going and if you need help. I know that Cloth Deck Chair works great for me in the Latest USD Composer 2023.2.5.


I’m new to Omniverse and have a background in software engineering which is why I chose CODE over Composer. Second, I randomly chose this demo when selecting different physic scenes to view in CODE. With that said, I am not trying to prove physics is broken, I am sampling different physics examples to learn how others have implemented physics in the Omniverse.

Should I not be using CODE? Let me know if I Composer is a better choice.


Great thanks. Code is a great place for you to start. Especially if you are a software Engineer. You should also download USD Composer, just to see how we handle the USD scene structure there as well. They should work seemlessly together. Welcome to Omniverse !

The best place for you to learn with examples is in the EXAMPLES tab which you can turn on under “Window > Browsers > Examples”

1 Like

Interesting, unfortunately I am still not able to reproduce this locally :( Well, at least it seems you have a fix for your case now. The part of the code handling the external assets path has changed in later versions, so I hope you will not run into this again after we release an update.

Seems like this might be an elusive edge case. In any case, thank you for checking.