I work remotely and I use MS Remote Desktop to connect to my development computer. I have found that when I try to debug my Cesium app within the remote connection it fails. If I go back to my computer and access it (while I am still connected via VPN) it works. I would really prefer not to have to go back and forth to debug my application.
Is there any way or settings that I can use to make this work? I know there are issues with graphics capabilities (like my app won't work in IE on one of my other computers), but I think the display issues are almost a deal-breaker for us when trying to convert our apps into Cesium.
Are there plans to correct the graphics limitations of Cesium? Or am I missing the fixes for them?
What exactly happens? Does Cesium run at all over webgl for you? Or does it just crash when you open the debugger? Which browser/version?
Can you give this a try in Sandcastle over VPN, and let me know if it solves the problem?
var viewer = new Cesium.Viewer(‘cesiumContainer’, {
contextOptions: {
webgl: {
failIfMajorPerformanceCaveat: false
}
}
});
Ed.
I experienced similar problem with applications that extensively use
hardware accelerated OpenGL.
AFAIK, when you connect with MS Remote Desktop Windows creates
something like new virtual desktop that doesn't support hardware
acceleration.
To solve this issue I used VNC server and client (e.g. UltraVNC),
instead of Remote Desktop.
One more note: after you connected with Remote Desktop, your desktop
acceleration is screwed until you interactively login to computer,
so starting VNC server in Remote Desktop session will not work.
The errors I get are "Error constructing CesiumWidget" and "RuntimeError: The browser supports WebGL, but initialization failed." along with others.
I am currently running in Firefox 40.0.3, but it also fails in the other browsers as well.
I will check into using VNC.
There are many possible causes of that error, but the involvement of VPN makes me suspicious of one cause in particular, and I’d be interested to know if you can confirm it on your system. Cesium sets a WebGL option called “failIfMajorPerformanceCaveat” to true, when the WebGL default is false. What this means is, the browser will refuse to construct a software-only rendering context, because the performance will likely be low. But you can manually tell Cesium to take WebGL’s normal setting, like so:
var viewer = new Cesium.Viewer(‘cesiumContainer’, {
contextOptions: {
webgl: {
failIfMajorPerformanceCaveat: false
}
}
});
Then, the browser might be willing to construct a software-only rendering context, such as inside a VPN with no available GPU. Likely performance won’t be good, but if it works at all you’ll know that this is indeed what has caused the problem.
The alternate solution using VNC should give better performance. VNC lets you remotely take control of a desktop that’s still available locally, so someone looking at the local monitor can see what the remote person is doing. But critically, this approach allows the remote session to use the local graphics card and GPU to render locally in hardware-accelerated mode, and then just live-streams the results to the remote user. So, Cesium continues to work normally, without tweaking any WebGL settings, assuming the local machine has a good graphics card. But that assumption doesn’t hold if the “local machine” is just a virtual instance in a rack of servers, there may not be a graphics card there for Cesium to access. In that setting, VNC won’t solve the problem, and software rendering could be your only choice.
The best remote solution is likely to be a VNC connection into a server with a good graphics card on it.
Ed.
I opened Firefox on the remote computer and went into Sandcastle, pasted in the suggested code, but I got the same error.
I know that my remote connection issue may be resolved using VPN (trying to find out if our company has any purchased already). But as far as it working on other computers (not remote) where the graphics card isn't working right, can I use that code to make it work? I have customers around the world that use different browsers and obviously different computers and it would be nice to get it working no matter what.
Using that code improves compatibility, but nothing guarantees WebGL works on all browsers around the world. Some don’t support it, and many allow you to explicitly disable it.
Ed.
If you need compatibility with older browsers, older computers, and remote desktop, may I suggest you check out TerriaJS?
https://github.com/TerriaJS/terriajs
It uses Cesium for 3D rendering but has a 2D fallback (using Leaflet) on systems that can’t run Cesium for whatever reason.
Here’s a live app built using it:
http://nationalmap.gov.au
All the UI stuff you see in NationalMap is an (optional) feature in TerriaJS, too.
Kevin