I’m going to start this thread because my issue has been going on for a week, in case I’m not the only one having an issue
I am about to test v1.28, hoping my hardware bug has been fixed in this release. Hannah, please wait to respond until I test the v1.29 update.
I have been developing a WordPress plugin to support an online Google map of daily avalanche forecasts since October 2013, and was excited to discover the initial release(s) of Cesium in the Fall of 2014. For three years plus, I have been developing the Cesium map as a replacement for the Google map; the inability to clamp-to-ground geoJSON polygons in Cesium has forced me to use the 2D Google map for 3 Winters… NOW, I finally have the functionality in Cesium to use it for my avalanche forecast map, but my hardware is aging (and I’m an unpaid volunteer…).
My Cesium development and initial testing are on localhost using a Windows7 laptop with Intel HD graphics chipset, for which the newest available driver is 8/31/2011, which may limit this hardware’s support for the latest WebGL 1.0.3 standards published 10/27/2014, but I haven’t had any problems on this laptop yet…
As soon as I have a stable version on the laptop/localhost, I upload the code to a GoDaddy server, running WordPress on IIS, and test the online Cesium map using several additional devices & browsers. My wife usually gets an email from me, when my latest Cesium map is ready to test in Safari browser an her iPhone, iPad, and Mac laptop…
I test Cesium in Chrome on Android using my Samsung S5 phone, which was new when I started this project 3-4 years ago; its also the mobile device that the snow rangers use(d), who post the daily advisories. I’ve never had a problem running Cesium on the S5, including initial 1.27 clampToGround implementation, which was rendering polygons on terrain during some brief tests before I updated Cesium to 1.28
Since updating Cesium to 1.28, I’ve had inconsistent results reproducing this bug in Chrome on my Samsung S5 device; maybe its my hardware, maybe its my code, maybe its the Cesium core…?
Cesium map occasionally initializes okay, but geoJSON polygons render on the WGS84 spheroid, underneath the STK terrain, only visible in 2D, and briefly in 3D before view renders image provider tiles over the terrain (these same polygons render correctly clamped-to-ground in Chrome on Windows7); eventually, in this state the map fails with a FragmentShaderFailedToCompile error
Cesium map will not initialize at all, renderer fails with error message regarding FragmentShaderFailedToCompile
Briefly today, the map initialized okay; the geojsondatasource polygons rendered underneath terrain; geoJSON point billboard and markers displayed okay on terrain, but the map crashed with an array index, when removing datasources from the viewer - maybe this one is caused by my code…?
Late yesterday, the Chrome browser crashed with a FragmentShaderFailedToCompile error initializing the home-page demo on Cesiumjs.org, failing several tries; this demo/test has never failed on the Samsung S5 before; it’s had a few knocks, maybe this phone is having a unique issue; I was not sure if the cesiumjs.org demo is still running 1.28 or 1.29… the demo still crashes today, after restarting the phone…
It should look like this:
That looks like a really neat app! Glad Cesium is working out for you. Would you be interested in writing a showcase for our demos page? http://cesiumjs.org/demos.html
We like to feature the kind of cool things people are doing with Cesium. Let me know and I’ll put you in touch with our editor to talk about putting something together.
We did have a Samsung bug that was fixed recently, so yes, please let me know what you find out after updating to 1.29 =)
Hannah-
The good news first: After updating to v1.29, I haven’t reproduced the FragmentShaderFailedToCompile error, the map viewer seems to initialize and remain stable; the demo on cesiumjs.org home page runs wo the shader error.
The bad news: geoJSON polygons still render underneath STK terrain on this Samsung S5 android device. I have heard, but haven’t confirmed, that a similar issue occurs when my online Cesium map is viewed on my wife’s iPhone 6.
I’m not happy about the new year yet, as the whole point of my development effort is an online map that can be viewed on mobile devices, so I can get out of my cubicle and take my Cesium map with me!!! I’ve tested the same map simultaneously on a Windows desktop browser in Chrome, and the clampToGround geoJSON datasource polygons render correctly on top of STK terrain.
Cesium map always (?) initializes okay, but after v1.29 update, geoJSON polygons render on the WGS84 spheroid, underneath the STK terrain, only visible in 2D, and briefly in 3D before view renders image provider tiles over the terrain (these same polygons render correctly clamped-to-ground in Chrome on Windows7); the map seems stable toggling back & forth between 2D & 3D with scenepicker and toggling terrain back & forth between wgs84 ellipsoid and STK terrain;
"Range Error: Invalid Array Length" occurs inconsistently when removing datasources from the viewer - and I have reproduced this on the Samsung S5 Android phone after v1.29 update… but I have not completely reviewed my code, which loops through an array of datasources and removes one, though the code runs fine in the desktop Chrome browser. I will look harder at my code, if mine is an isolated occurrence.
Glad to hear you are no longer seeing that error! If your geometry is still rendering under terrain on the Samsung phone, it’s possible the phone doesn’t have support for geometry on terrain. In order to achieve this feature, we use the EXT_frag_depth WebGL extension and unfortunately not all devices have support for this extension. You can see if your device has support by going to http://webglreport.com/ and seeing if EXT_frag_depth is listed.
You can check GroundPrimitive.isSupported(scene) when your app launches and disable terrain if that function returns false so you can still see the polygons.
Regarding the ‘Range Error: Invalid Array Length’ error, I have seen that before but I have yet to find a reliable way to reproduce the crash so it’s been difficult for us to figure out what the problem is. If you have a way to reproduce this please let me know!
‘FragmentShaderFailedToCompile’ WebGL renderer crashes are not a hardware incompatibility issue, per se.
Rendering 3D polygons underneath terrain MAY BE a hardware incompatibility issue.
‘Range Error: Invalid Array Length’ WebGL error appears to be specific to my code and data, not the hardware
FragmentShaderFailedToCompile error is continuing to plague my Cesium map initialization and stability on mobile phones, but I determined the cause is the initial flyTo Heading, Pitch, and Roll parameters, when I go from Cesium’s default view to custom coordinates. I’ve observed flyTo results in the camera swinging out into space before coming back to Earth, and in a few cases, I observed the GL crash while rendering this flyTo. Apparently my desktop hardware is more resilient handling the results than small-screen devices. This flyTo occurs when the geoJSON datasource is done loading, so the timing is coincidental.There are many things I have yet to try to resolve that, although the flyTo animation is cool, including suspend events
Thanks, those maybe very helpful references. I had read about the EXT_frag_depth WebGL extension last month, forgotten the details, and was going to look up whatever I had read about how cesium implemented the clampToGround
From a public safety standpoint, an avalanche hazard map that loads everything except the hazards is unacceptable. If I am going to promote a 3D Cesium alternative, maintaining the old 2D Google map maybe required for backward-compatibility with older browsers & hardware. I had just begun a little research into querying the browser/device WebGL support, and how to remotely diagnose/debug the mobile device Chrome browser without logging messages to the java console. I got as far as digging up an old function I wrote to debug another issue years ago, which may be helpful to others:
function canvasGetContextWebGlContextGetParameterMaxTextureSize(CesiumMapViewer){
//troubleshooting error loading very large JPG:
// “WebGL: INVALID_VALUE: texImage2D: width or height out of range…”
// "[WebGLRenderingContext]RENDER WARNING: texture bound to texture unit 2 is not renderable.
// That message means the texture is larger than the GPU supports safely. You can check the maximum size allowed by calling gl.getParameter(gl.MAX_TEXTURE_SIZE)
var gl = null;
console.log(“CesiumMapViewer.scene.canvas.getContext begin…”);
try{
gl = CesiumMapViewer.scene.canvas.getContext(‘experimental-webgl’);
if(gl == null){
gl = CesiumMapViewer.scene.canvas.getContext(‘webgl’);
}
}
catch(error){
console.log(“a .getContext error occurred getting WebGL” + error.message);
}
finally{
console.log(“CesiumMapViewer.scene.canvas.getContext done…”, gl);
};
if(gl != null){
// WebGL is supported
console.log("WebGL is supported, but the maximum size the GPU supports safely is: " + gl.getParameter(gl.MAX_TEXTURE_SIZE));
}
else{
// WebGL is not supported
console.log(“WebGL is not supported”);
};
}
