If so, two questions for you:
- What features are missing in Cesium that you need? As discussed, KML, ground clamping, and 3D buildings are on their way!
- Have you already built something with Cesium? If so, can we promote it like youbeQ, Cycling the Alps, and Cube Cities? Reply here or email me at pcozzi@agi.com.
Thanks,
Patrick
Hi Patrick and Cesium community,
Ad 1) I think it would be beneficial for the Cesium project to continue supporting open geospatial (OGC) standards like currently WMS en TMS and integrations with OSGeo-software like with OpenLayers3 [1].
In that perspective a possibly relevant 3D web service standard, 3DPS, 3D Portrayal Service from OGC has just been out for public comment [2]. IMHO this candidate standard has the potential to support encodings (payloads) with formats already supported by Cesium like CZML and GeoJSON. Even Cesium-terrain tile-encodings (heights, quantized-mesh) may fit, as 3DPS has a tiling service. 3DPS replaces all earlier web service standards (like W3DS) from OGC.
Proposing Cesium-formats for Terrain and CZML to OGC could also be useful, but understood this is already taking place.
At the server-end: there is a preliminary W3DS, a 3DPS predecessor, implementation as community module in GeoServer [3].
Within The Netherlands a national 3D-breakthrough project has started. I will do promotion there for the above. As a first step we need to review 3DPS w.r.t. Cesium and OSGeo software.
I am thinking of some kind of testbed for Cesium, and server components for the above standards.
In recent blog-posts I attempt to provide an overview of 3D Open Standards [4] and 3D FOSS [5].
Links:
[1] http://openlayers.org/ol3-cesium
[2] http://www.opengeospatial.org/standards/requests/130
[3] https://github.com/geoserver/geoserver/tree/master/src/community/w3ds
[4] http://justobjects.nl/3d-geospatial-open-standards-v0/
[5] http://justobjects.nl/3d-geospatial-foss-v0/
best,
Just van den Broecke
The Netherlands
www.justobjects.nl
Idle performance is still a downside for Cesium… as mentioned in this bug:
https://github.com/AnalyticalGraphicsInc/cesium/issues/1865
even when our Cesium app is doing nothing, the users’ computer is noticably slower to minimise/drag windows etc. starting up a GPU monitor shows the GPU at close to 100% as soon as a cesium session starts… and my gpu fan confirms.
ideally cesium shouldn’t be running code when it is capable of knowing that nothing has changed.
oh and clamping geometries to the ground 
-i
Using the google.earth.createInstance function you place a Google Earth instance into a div, a div you can dynamically change. Is this already possible with Cesium?
Within the GE initCB(instance) function you can set a global variable to instance to make GE available outside of the function. Perhaps I initially missed the obvious, as it seems that you can do the same with Cesium.
initCB <-> startup
instance <-> Cesium
So make a global such as CS, then within startup have a line CS=Cesium.
The ability to put cesium in what ever div you want is pretty much the same as GE, I am working on a solution where I am supporting 3 geo api’s (google maps, earth, cesiom ) depending the browser used, webGl support and the ability to load the GE plugin
google.load(“earth”, “1.x”,
{ "other_params": params.googleMapParams,
"callback": function () {
google.earth.createInstance(
GEO_CONTAINER_ID,
createInstanceCallBackSuccess ,
createInstanceCallBackFail);
}
});
viewer = new Cesium.Viewer(
GEO_CONTAINER_ID,
{ scene3DOnly: true,
homeButton: false,
timeline: false,
animation: false,
targetFrameRate: 24
});
The callback function isn’t really needed for cesium as the javascript for cesium is already loaded when you call new Cesium.Viewer. just execute your call back in the next line.
For google earth, the callback is needed as the google.load function loading the code for google earth asynchronously.
Oops, overlooked the GE-question which started in the Subject.
Below thus would not apply (to GE), but is maybe useful at some other place, GSOC maybe?
best,
Just
In the Sandcastle demos there’s this code at the end
if (typeof Cesium !== “undefined”) {
startup(Cesium);
} else if (typeof require === “function”) {
require([“Cesium”], startup);
}
Which seems to always follow the else if branch since Cesium isn’t yet defined/loaded. Even though Cesium is JavaScript it does take time to load and process all of those js files. It seems to act as a callback which calls startup once Cesium is defined. Sort of like window.onLoad.
Also in the SandCastle apps viewer is a local var within the startup function, I suppose within the startup function you could set it equal to a global to access elsewhere.
I suppose viewer.canvas is the HTML canvas that all of the Cesium viewer resides within? So you deal with a HTML canvas element rather than a HTML div element?
I have implemented a clampToGround workaround for myself that works with billboards and polylines. But I haven’t tackled polygons yet as this is a fair bit more involved, so depending on the timeline of the built in Cesium coming solution I may hold off on that.
Some minor things that may be already available just need a few more tutorials perhaps.
in google earth there is a handy parseKml function to load client side generated kml not a biggie, something similar to load czml , however I just started looking at the viewer.entities and it appears to offer some similar funtionality for what i want. need to work with entities a little more.
some of the event listeners, ‘ViewChangeEnd’ in particular. but again a simple setintervel has worked well as an alternative.
again not a biggie but may be nice, timeline range filter, the implementation in earth wasn’t great but handy, from what i can tell the current cesium time line control allows one to select a single point in time.
I’m probably going to implement my own as I want to work across several browser geoRenderers (Earth maps, Cesium … ) and also want it to filter content in other page controls such as lists and tables.
As a side note I will mention that I think Cesium is pretty fantastic from what I have worked with seen so far. This stuff isn’t easy.
Idle performance is still a downside for Cesium
Yes, I agree this is a significant problem. We have an increasingly passable solution to this in National Map. I plan to roll it into Cesium (and hopefully make it slightly more than passable) sometime soon. The NM code is here, in case it helps anyone:
https://github.com/NICTA/nationalmap/blob/master/src/Models/Cesium.js
Kevin
Skimmed the linked code, and seems pretty reasonable. Can you clarify what you mean by “slightly more than passable”?
Well, here are the problems I know about:
It successfully waits for terrain and imagery tile downloads before stopping rendering, but it doesn’t wait for anything else that might be polling-based in the render loop, such as CZML / data sources, model loading, etc.
It requires that applications explicitly restart the render loop when they make changes to the globe.
It only handles mouse input at the moment. Touch events may not restart rendering. I know there’s a bug currently where two-finger zooming on laptop trackpads doesn’t restart rendering.
Kevin
Mobile support - that was one of the reasons for migration
altitudeMode: relativeToGround (not clampToGround)
Camera issues #2271 and #2415
something like camera.copyAsLookAt - a reverse of flyToBoundingSphere (maybe I just need to dig deeper)
At the moment it seems that the only way to obtain terrain height is using the promise-when method, then calculate above ground.
camera_height_above_ground = camera_height_above_elip - terrain_height_above_elip.
If you’re constantly moving the camera and require the latest terrain height you need to constantly use the promise method. However it seems that the number of pending promises could build up if you sample too rapidly, plus there may be some lag.
I believe web workers, which operate on other threads, deal with the terrain rendering. It would be nice if you can setup those web workers to automatically obtain the terrain height at the camera lon/lat every frame. And automatically post this information back to the main thread every frame. Setup the main thread to automatically check web workers messages every frame and place the result into a variable of the main thread.
Then when your app wants updated data it simply checks that variable.
The altitude modes are on our near term schedule. Most of the code to handle it will likely be done at the shader level, so that the visualization adjusts properly as different terrain is loaded or refined. Each primitive is a case by case basis so we won’t know for sure until we implement it.
I haven’t noticed the automated declutter of mouse-billboard(pin) interactions. GE did this automatically. As we are migrating to Cesium, we have missed this. In fact, we have just recently implemented our own mouse event handlers; the examples helped, but the differing ‘movement’ structures were initially puzzling. As far as the actual declutter, we haven’t implemented that yet. Is there a stock function that we’ve overlooked?
-Kirk
Thanks for all the feedback.
@Kirk - we made some progress on declutter for a ESA Summer of Code in Space project. Search the forum and check out #1097. I don’t think you will find useful code, but there are ideas and papers that could be useful. We will address this in core Cesium at some point since I expect it will become increasingly important for KML.
@Kevin - we should sync-up on the idle optimization for issues like shader-based animated water and day lighting, and if the optimization can be handled the command level. If not, I think robustly supporting it in the general case will be hard, but perhaps a 95% solution will be fine for most.
Patrick
Hi Cozzi,
Sounds good. Maybe Skype sometime? It’s been awhile!
Day lighting shouldn’t be a problem in my approach, because it should only change if simulation time is advancing. Currently (though maybe we can do better) the Cesium clock ticking keeps the scene rendering.
Water, and other things that change as a result of wall clock time rather than simulation time, are trickier. The obvious approach is to drop the frame rate, without stopping rendering entirely, when we detect that this sort of thing is the only reason to render.
You’ll have to tell me more about what you mean by handling it at the command level.
Thanks,
Kevin
Maybe Skype sometime?
OK, will email you.
You’ll have to tell me more about what you mean by handling it at the command level.
Basically all Cesium does is issue commands that the renderer interprets and issues WebGL calls for. If a frame generates the same commands (including the same buffer, texture, etc. contents), then the scene didn’t change. We still need to execute update(), but we don’t need to execute commands, which chews up a lot of CPU (including in the browser itself) and all the Cesium-related GPU work. Can we cleanly and efficiently detect changes in commands? I think so. Is it the most robust, centralized, and future-proof place to do detection? I think so. Will some users also want higher-level coarse-grained checks that can fully eliminate the render loop in niche cases? I think so. What exactly do we do? I don’t know yet.
Patrick
Hi Kirk,
I'm working with Patrick Cozzi on collecting showcases for the Cesium website: http://cesiumjs.org/demos.html. As you've migrated to Cesium, has your project gotten to a point that you'd like to share it on our demos page?
-Sarah