Starting the kit app with --no-window or --/app/window/enabled=false disables the main OS window and creates a virtual invisible window that cannot be converted to an OS window.
Starting the kit app with --/app/window/enabled=true enables the OS window. Calling carb.windowing.IWindowing.hide_window or carb.windowing.IWindowing.show_window on omni.appwindow.IAppWindow.get_window() allows the window to be turned off/on on demand. However the window will always be visible during startup and I have not found a way to make it hidden by default (the culprit seems to be omni.kit.renderer.bind.IRenderer.attach_app_window, which automatically shows the window when called).
Therefore my question is, is it possible to start the kit headless and turn the window on/off on demand? If not, can there at least be an option to hide the app window by default?
Hi and thanks for posting. I am not sure why you wish to hide or unhide the GUI. Either you start it headless, or not, because they provide very different, unique conditions. Either you are running the kit app locally, directly on your desktop, or you are not, and you are streaming it to a browser. Those two conditions are very different and require a full app restart. You are either working directly, or working remotely. It is much more complex that simply showing or hiding the window. When you run headless it, is designed to stay headless to save resources for streaming. So then, may I ask, what are you trying to achieve? Why do you need the option to show or hide the GUI?
For toggle-on-demand behavior, the closest thing you can get, is what you are already doing. Start with --/app/window/enabled=true , accept that the window flashes during startup, and then immediately call hide_window on the main app window once your extension’s on_startup runs; from then on, you can toggle via hide_window/show_window
We are creating an interactive, general-purpose simulation app for our robotics application. The API is designed around the idea that the viewer is separated from the scene being simulated such that it can be toggled on/off or disposed of by the user. The API was designed like this because it introduces flexibility into the debugging workflow. Being able to inspect/modify the scene when something goes wrong is extremely valuable.
Implementation wise this is not supposed to be too hard in kit because the “viewer” is just a bunch of UI extensions that can be loaded/unloaded on demand. However there are two main problems that need to be addressed:
Start the kit without any UI extensions: Currently impossible because extensions such as omni.syntheticdata, omni.replicator.core, and isaacsim.asset.importer.urdf, which we rely on, do not cleanly separate UI from their core functionality.
Start the kit with UI extensions, but hide the window: omni.kit.renderer.bind.IRenderer.attach_app_window always flashes the window briefly when called (even without app.update).
I would much prefer to have problem 1 fixed ASAP because the major complaint from our team is the long startup time of our app (~5s, for reference, other robotics simulators often load in less than 1s), and UI extensions do contribute a lot to the long startup time.
If you are starting your app in 5 seconds, then that is INCREDIBLE. I have an extremely fast computer and then best I can do is 20 seconds. I would not consider a 5 second start up slow. That is barely time to take a sip of coffee. :-)
The trick is to reduce the number of extensions enabled to an absolute minimum. Currently we are at around 5 (the setup is similar to omni.app.viewport), whereas Isaac Sim has at least 100 (isaacsim.exp.full). Of course there are dependent extensions. Even then I am fairly sure that the total number of extensions started up is still a lot smaller than Isaac Sim’s.
The problem with 5s of startup time becomes significant when you have frequent debug sessions. And I know it is possible to reduce it because the several of the extensions I previously mentioned can be trimmed down by separating their UI components to separate extensions (in fact, many physics-related extensions already follow this pattern; I am not sure why renderer is not the case).