Another beginner's questions


I stumbled upon Cesium after taking a loot at Three.js and SpiderGL. We are a stealth startup in The Bay Area, working on a web+mobile product which is map-oriented and absolutely needs 3D terrain rendering (albeit for the web component only). I am trying to decide if Cesium might be the right framework for us. I would greatly appreciate short answers to these questions. I’ll be very specific and brief:

  1. We already have our own 2D Mapnik tiles and they include hillshading, so we don’t need any kind of shading – just an ambient light source. We can also generate arbitrary heightmaps at any zoom level. The question is, can these two be combined to render an extensive map, spanning something like 3600 square miles (60x60) at a close enough zoom level to judge terrain ruggedness? (think OSM zoom level 13-14). If the answer is yes, what would be some good examples to ingest and digest?
  2. We have a requirement to create a scripted animation of a map with accompanying audio and photo popups. For the early release, we will be scripting those ourselves, but in the long run we want our users to be able to build and publish these “guided tours”. Is CZML sufficient for this task (as the low-level scripting language, not the UI)? It seems to be, but I’d rather know of any gotchas upfront :slight_smile:
    Thanks in advance,


Hi Peter,

For (1), Cesium supports worldwide terrain and multiple imagery layers at very high resolutions. We currently have 90 meter terrain, and imagery from Bing, which I believe is 1 meter or better in areas. We can do higher resolution terrain, but haven’t integrated those datasets yet.

Here’s an example for imagery. Terrain support is not in master yet, but that is not stopping us from shipping on Christmas Eve to millions of users :). Checkout the terrain branch, specifically the terrain example (local link, drag with middle mouse button to tilt). There’s some tech details in this write-up and this wiki page talks about the terrain format (subject to change). We only use ambient light to shade terrain, but allow users to dynamically adjust the brightness, contrast, and gamma (example).

For (2), this is the exact kind of thing we want to do with CZML. For example, we want to give presentations on Cesium using Cesium. Popups are not implemented yet, but I imagine they are not that far out. Someone who works more closely with CZML can answer that. Also, we haven’t given much thought to audio. Given that CZML is extensive, you can certainty do it, but I’m not sure that we would put it in the core spec (perhaps an optional one) because it would require that all clients support it, which could be hard for say a C++ client that doesn’t have access to a similar audio API.

Also, there is some info in our FAQ for comparing Cesium to a general 3D engine like Three.js.



Thanks Patrick. I was able to get things to display, albeit kind of slowly. One thing I did notice is that the sky turns black at close zooming, and it happens with all the demos for me. For now, I took the liberty of hacking the widget to change the tile provider until I figure out the right way to do it from the “outside”. I also had to write a custom Proxy. Thanks for the previous post on CORS, I would have been stuck with it too, but I fixed it on the Apache side.

The terrain code seems to break if I try to use CesiumWidget; I have to use CesiumViewerWidget instead. I can probably live with this as soon as I figure out how to get rid of all the controls.

Also, I’m suspecting that your terrain server will get slammed during the Santa season, so is it OK if I set up a Squid instance on my server to cache some of the heightmaps?

Many thanks,

Hi Peter,

Regarding the sky turning black, can you share a screen shot? I don’t think I’ve seen that.

You can take a look at the Terrain example in Sandcastle to see how to change the terrain provider from outside the widget. That isn’t the “final” way it will be done, probably, but it will work now.

Can you tell me more about what breaks in the terrain code when you try to use CesiumWidget?

We don’t mind if you set up a Squid cache of the terrain data, but the Santa app will not us the terrain server - it will have its own with a CDN in front of it.


Here is what happens when I use CesiumWidget:

[16:17:10.229] TypeError: buffers is undefined @ http://localhost:8080/Source/Scene/TerrainProvider.js:114

This probably needs further debugging.

I have attached a screenshot showing what happens to the sky when I zoom in. This happened to all demos for me (using terrain branch), before I started making code changes.



What kind of video card do you have? We haven’t seen that artifact with the atmosphere before and earlier you mentioned that performance was only so-so. I’m wondering if you have an old card (or old drivers, but drivers are tied to the OS release on Mac).



It’s a 1-year old Macbook Air.

I figured out the problem with CesiumWidget. For some reason, changing its CentralBody’s terrain provider after construction didn’t work. I changed the implementation to instantiate CesiumTerrainProvider instead.

The slow speed ended up being incorrect image caching by Firefox which is a known issue (it ignores Expires and Cache-Control for content generated by HTTP “queries” which is what our tile service does). Chrome is much faster but it exhibits a high CPU utilization even when no rendering is taking place, forcing the CPU fan to turn up and make a lot of noise.

Also, I tried to disable both SkyBox (which incidentally never rendered for me) and SkyAtmosphere, and used a plain color for clearing the scene instead of black. I got constant flicker in the sky during tile rendering, so something else must be clearing it. When it settles to static it looks good but it’s not a viable solution at this point.


Is the graphics chip the Intel HD 3000? I believe we've seen other
problems on Intel graphics. I have a 2010 MacBook Pro and last I checked,
WebGL doesn't initialize at all if I lock it onto the integrated GPU.

Yes, it’s an Intel HD 3000 indeed.

I can confirm things work well in Chrome Win7 on a 2-year old VAIO with nVidia, but the CPU utilization at idle remains high.

Well, the good news is that WebGL does work on the integrated Intel HD chip on my MacBook Pro (I have to set it to force integrated before launching Chrome, not after), the bad news is that I don’t see the same problem with the atmosphere as you do. Performance is not very good (15-20 fps on a blank CesiumViewer), and the stars skybox is missing for me too, but the atmosphere looks normal in both Chrome 23 and Firefox 17.

It looks like the chip in my MacBook Pro is listed in the system info panel as “Intel HD Graphics” which as far as I can tell from Wikipedia means it’s the original chip in the Intel HD line, and older than the 3000, which probably explains why I get different results. Are you on the latest OS X (10.8.2)?

It may be that someone else at the office has a laptop with the HD 3000. It looks like most of the 2011 Macs have one (Air, Pro, Mini) so hopefully we can keep investigating and work on getting this fixed.

I’m still on Lion (10.7.5). Let’s see what happens when I upgrade …

… no change. 10.8.2 behaves the same.

My lowly 2008 Mac Mini running Lion has an Intel GMA 950 and it doesn’t exhibit this problem (of course it’s too slow to be usable).