@Svetoslav would love to see shadows too, especially with the upcoming 3D buildings support. What is your use case?
I just want some artistic effects on the planet - to be able to do different lighting over the whole planet - for example point light, and shadows on the edges, to get perception of more depth, more 3d look. My project only uses imagery and not 3d tiles, and the planet looks too “flat”. So As I’m thinking now, besides shadows I would like lighting as well. If it’s on the project schedule at all.
I would love to see improvements on the water mask (aliasing of the terrain/water boundary).
Working on a tighter/foul-proof integration with GLTF standards: conversion results are still a bit random in terms of model quality: lighting/normals are off, tools are a bit clumsy, etc. Better implementation of material/shaders for models (specular, alpha blending, reflection)
In general, I would say that the real plus from using webGL compared to Gocoughle Plugin is that you can pull out nice visual effects/shaders:
improve billboards (z-sorting/blending and scaling) in order to make clouds/particles/lights
Improve water shader: tiling is visible, not very realistic
I think 3D tiles should be the top priority. Something else that would help speed up adoption is the creation of tools and/or libraries to help create 3d tiles.
for the orthometric elevation, the wish is a terrain data set that has/uses orthometric elevation for the terrain rather than ellipsoid elevations.
I have data that has orthometrc elevations (relative to sea level) and I am plotting this, and often scaling vertically. To get things to be positioned properly in cesium I need to apply a geoid offset to elevations.
The orthometric elevation is also needed to display properly KML content that has an altitudeMode = absolute. At the moment, this isn’t rendered properly in cesium as far as I know.
Also when performing terrain picking , the geoid needs to be applied.
For example if a widget is displaying terrain information for a location that a user is mousing over, and the user is mousing along the ocean shoreline, the terrain elevation values should be at or near zero.
Currently sea level is at different elevations, depending on where one picks terrain on the globe, large lakes will have shorelines at different elevations, and rivers can flow uphill.
I posted a few questions about it earlier in 2015, Matt mentioned it was somewhere on the todo list, but I imagine its a long list
- 3D Tiles
- WebGL 2
- Shadows
- Subsea terrain and water surface
Let me explain a bit more about the last one. It would be nice to have a surface for water (lakes, seas and rivers) and at the same time be able to have subsea terrain below. That is, two terrain surfaces where one of them would act a bit like water mask does today.
I am thinking that the Quantized Mesh format could get another extension where actual water polygons are listed. With water lines as break lines (which seems to be the case for AGI's terrain model), I imagine this could work well for high resolution terrain data - at high zoom levels. This would only require extra nodes for the tile edges that are subsea. A simpler solution would be to simply add the local tile lake/sea height as one variable and reuse that for edge nodes - but that would take away the possibilities for visualizing rivers which would have a sloping surface.
Being able to turn on and off the water surface would make for a whole new set of applications.
Most important for me would be to reduce unnecessary rendering calls. We do not need rendering of universe and no other rendering, so it is not necessary to repaint scene as long as we have no user interaction or any asynchronous loaded data are ready. Because of this it is currently a bad idea to let Cesium open if you run on battery.
One last question: I haven’t seen a lot of discussion on developer docs and examples, CZML, or support for other formats (except, of course, 3D Tiles). What does everyone think about these?
The actual Cesium API docs are great. The CZML docs, though, feel rather neglected. Last I checked, it was one giant Markdown file in a wiki, and I got the impression it hadn’t been updated in a while. Could probably use some attention.
Improving the CZML docs would be great. Also providing some complex examples of CZML would be great. I had trouble finding anything other than toy examples.
I'd love to figure out how to effectively use CZML to solve problems like one
Cancelling a flyTo() would be very helpful. Our use case: an interactive system with a touch screen, where we run autonomous animations (flyTo’s) but these should stop if the user interacts with the screen.
@Willem - for your suggested tutorial, we want to write a general introduction to 3D geospatial to help ramp-up new contributors so this would align nicely!
Once again thanks for the great input! We appreciate your help in shaping the future direction of Cesium. It is amazing how far you are pushing Cesium with your apps!
To summarize a few takeaways from this discussion, here’s the most popular items:
Improved ground clamping. ~7 mentions
3D Tiles / buildings. ~7 mentions
Shadows. ~7 mentions
Subsurface terrain. ~3 mentions
WebGL 2. ~3 mentions
Here’s a few related updates:
Ground clamping: We are already working on improving Entity API support in #3406 and adding optimizations in #3429. We have a huge interest in ground clamping for KML, the Cesium API, and vector tiles for 3D Tiles, so expect to see a lot of work in this area.
3D Tiles: The spec and implementation are progressing nicely, and the latest resources are always at the top of the spec. Adoption of 3D Tiles is also pretty amazing, especially considering that it is still in progress. As I’ve said in a few talks, I believe 3D Tiles has the potential to be bigger than Cesium itself.
Shadows: The recent VR work (#3330, #3394) laid some internal foundations for shadows. There’s still a lot more work to be done and some unique problems to solve for massive geospatial datasets, but we are excited for it.
Subsurface terrain: We’re super interested, but no firm plans yet.
WebGL 2: There is already some prototype WebGL 2 support in Cesium, but it needs to stabilize as the browser’s implementations stabilize. Given the potential performance improvements and that I believe part of Cesium’s success is due to being an early and prominent adopter of WebGL 1, expect to see official WebGL 2 support as the spec and implementations stabilize.
This year, also expect to see improvements to KML, CZML, performance (not drawing when stationary), label declutter, and perhaps the form factor (#2524) as we are using Cesium more and more in Node.js.
Thanks again for the input. This is going to be a big year for Cesium and geospatial 3D!
