We would love input from everyone on what Cesium features, bug fixes, doc improvements, etc. are most important to you. Please reply with any and all feedback. Even a simple +1 for a particular feature is valuable.
I’m pretty confidence we will see the following features in 2018 since someone is already working on them or has kindly committed to work on them:
For 3DTiles , i would like to see changing color palette and color legend option for "Color by Height" , like the one in this link: https://cesiumjs.org/NewYork/
It would be amazing if you add that showcase to Sandcastle.
I see you previously asked about drawing flow fields here. It’s probably best to try starting with the suggestions there, and keep discussion about how to accomplish that within that thread.
If you have a specific feature request related to how we could tackle a feature in cesium that would help you accomplish this goal, please let us know!
Thanks for the suggestion! We have definitely been looking at incorporating TypeScript definitions for a while, see this GitHub issue, as well as this one. In those issues, you’ll see that others have also created some typings files, if you would like to contribute to those projects or collaborate in other ways. Moving entirely over to supporting type script would require some changes in Cesium, like with how we use getter/setters.
We would love input from everyone on what Cesium features, bug fixes, doc improvements, etc. are most important to you. Please reply with any and all feedback. Even a simple +1 for a particular feature is valuable.
I'm pretty confidence we will see the following features in 2018 since someone is already working on them or has kindly committed to work on them:
Subsurface/undersea visualization, #6047Decreased CPU usage, especially on mobile and when not animating, #1865Post processing framework for improved visual quality, silhouette highlighting, etc., #5808Polylines on terrain and textured polygons on terrain, #2172Improved label quality, #5022Improved point cloud visual quality, #6069Cloud visualization, #5962Improved rendering performance, e.g., #5851Entity z-ordering, #4108
Other potentials for 2018 and beyond include:3D Tiles. What specifically?glTF. Draco mesh compression, keeping up with new extensions, etc.VR / AR / MR. What specifically?TypeScript definitions. Volunteers?
ES6 modulesIntegration with three.js/BabylonJS/A-Frame. What are your use cases?
KML improvements and bug fixes. What specifically?Doc and code example improvements. What specifically?Commercial tools for 3D content and 3D tiling from the Cesium team through cesium.com
All input is valuable and deeply appreciated so please chime in!
We'll keep this thread going all year, but would love to see a critical mass of input in January.
Thanks,
Patrick
--
twitter.com/pjcozzi
Underground mode(Make the terrain transparent to see the entity which underground) and Create Hole(Polygon or circle) on Terrain
For code examples using different frameworks, do you mean something similar to cesium-webpack-example which you reviewed? If you are interesting in creating your own or any tutorials, we could definitely review and feature them on the site!
We definitely want to make subsurface support more cohesive, but some of this is already possible with the current API. If you want to make the terrain translucent using globe materials, look at this thread, and keep an eye on this pull request for underwater rendering. You can also clip out terrain with multiple clipping planes.
Definitly a +1 to "Polylines on terrain and textured polygons on terrain".
It's frustrating how ground clamping is inconsistently implemented amongst all the basic geometry types, and this'll really help with things like ol-cesium, and projects using that.
support for local/multiple terrains. I mean support for precise local DTM(s) over a more global one like the STK terrain
This will fall under “Commercial tools for 3D content and 3D tiling from the Cesium team through cesium.com”. We plan on allowing user to be able to upload terrain data sets for use in Cesium.
Mechanism allowing to clamp 3DBM tiles to the ground. Currently coordinates in 3DBM/GLTB/GLTF files are absolute ECEF 3D coordinates
Τη Τετάρτη, 3 Ιανουαρίου 2018 - 9:14:31 μ.μ. UTC+2, ο χρήστης Gabby Getz έγραψε:
Thanks bampakoa!
For ES6 modules in particular, keep an eye on this GitHub issue.
For code examples using different frameworks, do you mean something similar to cesium-webpack-example which you reviewed? If you are interesting in creating your own or any tutorials, we could definitely review and feature them on the site!
Thanks,
Gabby
On Wednesday, January 3, 2018 at 6:40:34 AM UTC-5, bamp...@gmail.com wrote:+1 for Typescript definitions and ES6 modules.
Code examples on how to use Cesium on different JavaScript frameworks would be awesome!
Hello Gabby,
Thanks for your response. When I refer to frameworks, I mean Angular, React, Vue etc. If you think it fits in your context, I am interested in creating an example on Angular!
We display hundreds of aircraft in Cesium. In the Java version of our software we have the ability to update the texture on a model. So we load aircraft models and then apply textures according to the airline for the given flight. This keeps us from having to create a unique model with a baked on texture for every aircraft type / airline combination. And we would LOVE to be able to do this using Cesium.
If there is a method of accomplishing this already I would be very grateful for an explanation or code example. At one point last year there were some suggestions for how to do this, but none of them worked.
My wish list item is always bathymetry - not sure how that relates to
the above.
Is there a GitHub issue or similar tracking bathymetry support? I can
see how the clipping plane support could enable some workarounds in
some contexts, but not sure about integration with terrestrial data,
the join between dry land and in lake elevation data.
Gabby, I’m not sure that’s what’s being asked for.
As I understand it right now, Cesium supports a single TerrainProvider definition at a time. That provider looks at the metadata returned for the specified terrain dataset from the server, and determines the min/max levels available. Those levels are then applied to the entire globe, with the assumption that the max zoom level is available worldwide. I know that the Cesium terrain file formats have a flag in each terrain tile that indicate whether there’s supposed to be another zoom level available underneath the current tile, which also plays into this.
From what I’ve read, I think the STK Terrain server supports generating a single combined dataset based on multiple sources with varying resolutions, but I think the request here is for client-side support for multiple distinct terrain providers at once.
Here’s an example of what I’m picturing:
Two different terrain dataset URLs / providers are set up. Let’s say Dataset 1 has worldwide coverage with zoom levels 0-5. Dataset 2 only covers a specific area, say, 2x2 degrees, at zoom levels 6-12.
As the camera moves around most of the globe, the Cesium client requests terrain tiles from Dataset 1 for the lower zoom levels
As the camera nears the area covered by Dataset 2, the Cesium client determines that it’s reached the limit of the zoom levels provided by Dataset 1, and begins requesting tiles from Dataset 2 instead to handle the higher zoom levels.
