Cesium fails to load on GFN ( GeForce)

Cesium for Omniverse
1

I am trying to run an omniverse application with Cisium on NVIDIA GFN (GeForce Now) .

The application runs perfectly on local machines and can transfer from one machine to another and runs. Cesium loads and found with textures.

However, when I upload the application to run in GFN (GeForce ). the loading fails, either it gets killed when loading the cesium extension or gives a white screen without loading anything. If I disable cesium dependencies, the application runs well on GFN .

To troubleshoot, I took the Vinila Kit template project ( provided by omniverse ) and included the Cesium add-on ( as per Cusium for Omniverse tutorials ). It’s the same behavior ( runs well on local → fails on GFN → Runs well on GFN without Cesium ). - This test was even without a USD loading

Are there different settings to enable cesium compatibility for GFN ? or any manual? in addition any tips on getting this up an running. Much appreciate a solution.

2

Hi @kwicki, we have not deployed on GFN so I don’t have any settings to provide at this stage.

Are you able to access the Omniverse logs from your GFN session? This would be the first step in investigating what might be going on.

Can you also explain how you are including the Cesium add-on with the Vanilla Kit template? Are you bundling the extension with the package that you’re uploading to GFN? And are you activating it by manually adding it to your kit file as shown here

3

Thanks for your response .

Its as shown in the tutorial . inside kit dependencies . “cesium.omniverse” = {} and i have also made
/app.useFabricSceneDelegate = true …

Everything runs fine locally can even run without any prior installation on a fresh machine . If you can refer to anyone who has done any cesium related GFN deployment, would be a huge favor ?

4

Unfortunately we’re not aware of others that have used GFN with Cesium + Omniverse, most deployments we’ve seen have been using other streaming platforms.

Its as shown in the tutorial . inside kit dependencies . “cesium.omniverse” = {} and i have also made
/app.useFabricSceneDelegate = true …

Could you try turning Fabric off with app.useFabricSceneDelegate = false. Fabric is still experimental and we have seen it have issues in other parts of Omniverse. It could be that it has problems with GFN. With fabric disabled, Cesium for Omniverse won’t actually work, but I’d be curious to see if that at least lets your basic app load.

Also, are you able to access the logs on GFN? On desktop, they are typically located here (for USD Composer, your app may differ)

C:\Users<username>.nvidia-omniverse\logs\Kit\USD.Composer\2023.2

This will certainly be the next step in troubleshooting, otherwise without logs and specific warnings or error messages it’s very hard for us to pinpoint what the issue may be.

5

Thanks for the tips , let me try these and also try to get the logs . Ill revert .

6

image
image1920×593 143 KB

does this help . This is where the application hungs as a white screen or crashes . and i tried switching off fabric data with no help .

7

The last message, while not an error, is related to the caching system introduced in Cesium for Omniverse 0.18.0

You could try rolling back to 0.17.0 which does not have this caching system included, to see if that makes a difference?

9

image
image1920×1139 108 KB

I switched to 0.17.0 via the kit dependancies : “cesium.omniverse” = {version = “1.17.0”}. | no Fabric set on .

again same symptoms i am afraid , it runs and load successfully locally , when uploaded to GDN now i belive hangs at the point of installing the cesium extensions … I have also put " app.extentions. InstallUntrstedExtentions = true "

10

Looking at this log and the previous log, the extension install process is potentially getting hung up on the installation of the LXML Python libraries. Cesium for Omniverse ships with Python wheels of LXML which are installed on the first run, and cached thereafter. If you are able to, try checking to see if the LXML is actually installing to the target location that is in your log message.

On my system, I receive the following messages in the log after yours:

2024-04-01 08:53:11 [24,767ms] [Info] [omni.kit.pipapi.pipapi] pip install returned 0, output:
Looking in links: c:\users\ryan\appdata\local\ov\pkg\create-2023.2.3\extscache\omni.services.pip_archive-0.13.1+wx64\pip_archive
Processing c:\users\ryan\documents\kit\shared\exts\cesium.omniverse\vendor\lxml-4.9.2-cp310-cp310-win_amd64.whl
Installing collected packages: lxml
Successfully installed lxml-4.9.2

2024-04-01 08:53:11 [24,789ms] [Info] [omni.kit.pipapi.pipapi] [omni.kit.pipapi] 'c:\users\ryan\documents\kit\shared\exts\cesium.omniverse\vendor\lxml-4.9.2-cp310-cp310-win_amd64.whl' was installed successfully.

My installation of LXML takes approx 8 seconds, it may take different amounts of time on other systems. I’d make sure you’re giving the system enough time to get the install done.

Other things to check might be:

  • Write access to the target location
  • Try installing LXML or another Python Wheel from your custom extension, do you get a similar issue?
    • We’re using omni.kit.pipapi.install to facilitate the installation
  • Investigate to see if LXML can be pre-installed to your GFN instance?
11

Thanks , that makes sense .

The observation is it Hangs for hours … with no progress afterwards …Since it is GFN i do not have much access to the dynamic environment which gets spun at the time of clicking the PLAY button . But let me check . I shall try installing LXML …

Any possibility of Cesium team testing it out on GFN on your end in parallel as this might be a common use case coming in future ?

12

HI , i have updates : The 0.19.0 ( same was 0.17.0) version provided addressing LXML also fails to load on GDN .

I’ve done some additional tests using lxml , where i tried out a simple applications with , omni.kit.pipapi installing lxml . it hangs and fails .

I reached out to GDN partner support and as per them, NVDIA GDN do not allow custom installations due to security concerns using pipapi , where this limitation can be a roadblock , requesting for a fix which avoid pipapi installations or any workable alternatives ?

basically NVDIA GDN deeplink users will not have privileges to perform custom installations. I am discussing the same with NVDIA GDN support team as well ,will keep you posted.

13

Hi any luck or an update on this ? kindly acknowledge .