Architecture

[ahocevar]

This integration is developed in an open source layer built ontop of ol3js as ol3js is not bound to a specific 3D globe. This layer should allow to provide a common and efficient way to have ol3js and cesium working closely together.

Technical issues

• How to keep both ol3js and cesium synchronized?

  • Apply vector transformations (diff from current state) each time a context change?
  • Compute from scratch a new state from the new context?

• Save computing resources

  • disable rendering of the underlying map or globe if it's hidden by the overlayed one
  • still preserve context synchronization

• Smooth transition needs to know the elevation of the destination point of the camera

  • cesium provides an asynchronous method, synchronous planned for August
  • cesium provides in a dev branch a specific method. TDB: WHERE?

• Cesium camera entering the terrain

  In regards to the camera falling through the terrain, you will want to upgrade to Cesium 1.0 in August, which will include Camera/terrain interaction (see Camera-Terrain interaction CesiumGS/cesium#1817 and Geocoder flights should take into account terrain CesiumGS/cesium#1670).

[klokan]

Based on experiences from http://www.webglearth.com/ available at https://github.com/webglearth/webglearth2 and based on what has been done before at https://github.com/openlayers/ol3/tree/cesium we are reviewing the possibilities for ideal integration of Cesium with OL3. @petrsloup will comment soon.

[petrsloup]

In order to keep the integration easy to maintain, it is indeed a good idea to keep the integration code separate from the ol3 itself.

Although it makes sense to consider cesium to be just another renderer, it would require a lot of new code inside ol3 itself (namely ol.View3D), plus the ol3 is not ready to change renderer on-the-fly.

I think the best approach is to create "ol3 cesium plugin" and (if possible) completely avoid any ol3 or cesium modifications:

• All the operations would be performed on the standard ol3 objects using standard ol3 methods.
• If cesium 3D globe is needed, it can be "enabled" via the additional "plugin" interface.
  • This takes care of properly setting up the cesium
  • and also registers various event listeners (layer collections, controls, view properties, ...) to keep it synchronized (both ways).
• In 3D mode, the cesium interactions would be used (with settings as similar as possible -- hotkeys, sensitivity, ...).
• Both single-canvas (2D/3D switching) and double-canvas (side-by-side) scenarios can be supported.

This way, any 2D ol3 application could be switched to 3D by creating the additional 3D interface object:

  var map = new ol.Map(..);
  // setup...

  var ol3d = new ol.CesiumIntegration({map: map, ...});
  ol3d.setEnable(true);

But there are still some new methods needed to be able to utilize the 3D features (setting tilt, roll, altitude in meters, animations, ...) -- these could all be part of the integration object (.setAltitude(..), .setTilt(..), ...).

I think, however, some minor changes might be required to the ol3 itself in order to ensure optimal integration without any "hacks" -- particular requirements will become more clear after initial implementation.

[ahocevar]

Thanks @petrsloup!

+1 on implementing this as a plugin. This is also in line with my initial thinking and with what we had discussed in past ol3 dev meetings.

I think, however, that we should avoid using the ol namespace for the plugin. What namespace to use is a matter of taste. Personally, I would like something like this (i.e. factory instead of constructor):

  var map = new ol.Map(..);
  // setup...

  var ol3d = ol3cesium({map: map, ...});
  ol3d.setEnabled(true);

Minimal changes to ol3 are fine - also something we have a general agreement on.

[tschaub]

I agree this direction sounds good. My only suggestion is in line with @ahocevar's I think.

In my opinion, nobody should ever use the ol namespace unless they are working on code in the ol3 repository. I know jQuery has made hugely popular the idea of "plugging" everything into the same namespace (and Leaflet "plugins" do the same). But there is no benefit in using the same namespace and good reasons not to (the ol3 repo reserves the right to add new names to the ol namespace in the future, "plugins" of this nature don't lend themselves to naturally to module loaders, it only makes it harder for people to determine code origin when reading application code, etc.).

So +1 on an adapter.

[vpicavet]

Hello,

I will not comment on the renderer vs plugin design choice, but I'd like to stress that we would probably be interested in the future to have a ol3js / Three.js integration too.

Keeping this in mind would be great, just in order not to make technical decisions hindering that.

[klokan]

Suggested ol3cesium factory design is at: #8