Build script for non-WebGL parts of Cesium

Hi guys,

I wonder if there might be benefit to having a build script capable of combining all the non-WebGL parts of Cesium, like JulianDate, the Timeline widget, and maybe most or all of the CZML processing. It might be useful as a single JavaScript include to add CZML capability to existing 3rd party JavaScript products, like Bing maps or Three.js etc. (Three.js has Canvas- and SVG-based rendering in addition to WebGL).

Of course everyone will eventually have WebGL-enabled hardware, but they won’t always be looking at 3D displays. Lots of AGI customers need to look at web-based graphs and grids and such, and it would be good for both customers and Cesium if those 2D products were also powered by JulianDates and CZML. They want to be certain the dates and data are handled the same, be it in a simple flat list or on the 3D globe.

Can you estimate level of effort for this? Does it seem like a good idea?

     --Ed.

Ed,

I second this; looking at the D3.js stuff (and derivative products like NVD3.js) I realized that there would have to be a conversion layer for at least the date objects to make sure everything syncs up. Being able to put CZML in to a grid or graph without having to write per-property or per-type converters would be a huge plus. I’d be willing to help where I can.

-TJK

Ed,

As you know, Matt looked at Bing Maps a bit so he’ll have some good input. IMO a czml build sounds pretty useful for having a single file like Cesium.js for convenience, but in practice, will we use AMD for our czml visualizers?

Regards,

Patrick

Long story short, I'm perfectly fine with us producing a second
combined file. Where I think there's some discussion that's left to
be had is what exactly this other file would contain and what would
the minimum requirements be?

For example, we could do a "CZML.js" that includes all non-WebGL code
and is meant to be used to add CZML support to other visualization
solutions. We could also do a "CesiumRenderer.js" that includes
everything except Scene/DynamicScene and is meant to be used as a
low-level WebGL framework, similar to THREE.js. In this case I assume
we are only talking about the former.

In the future, we plan on making use of TypedArrays throughout the
codebase, for example, Cartesian and Matrix types may ultimately be
backed by them. Are Typed Arrays a minimum requirement for Cesium in
all use cases? I would think so.

So, once again, I'm all for this proposal; I just want us to be clear
about what the proposal is and what it does and does not do. In my
mind, it's simply "Cesium without WebGL, suitable for adding CZML
support to other JavaScript based applications." It has the same
requirements as Cesium (minus WebGL) and is source compatible.

Matt

Personally, I’d rather de-emphasize the combined file in favor of the modularity we already have. If a separate application needs JulianDate processing, great, just use JulianDate, that’s why we did the work of separating out all these modules in the first place. If that means we need to rewrap the modules in other module systems that haven’t gotten on board the AMD train yet (e.g. Google Closure with their goog.require thing), I’d rather do that.

Anything we can do to try and encourage JavaScript projects to move into the “modern” world of modular software development seems worthwhile to me. It’s already at the point where I think the combined Cesium.js is not really a good idea for any application that makes it beyond the first few hours of getting started prototyping.

If we have specific needs in mind, though, I’m not opposed to hearing out the use cases. So far, a CZML parsing pack, that is, only DynamicScene and dependencies, is the the best use case I’ve thought of that wouldn’t end up with 90% of the included classes being unused dead weight.

I agree with Scott that serious apps would use AMD, but czml.js (or whatever we would call it) lowers the barrier to entry, helping us get our foot in the door
Correct me if I’m wrong, but I suspect it is not very much work.

Also to more precisely define “Cesium without WebGL” and “DynamicScene and dependencies”, I think it can be stated as:

  • DynamicScene and dependencies - without Cesium visualizers, or perhaps
  • Cesium without Renderer, Scene, and Visualizers.
    The ambiguity is what do we include in Core. For example, since we are not including the Polygon primitive, we could also not include the triangulation code in Core, but couldn’t that be useful for CZML visualization? Perhaps we should include all of Core and DynamicScene except for visualizers. Or perhaps we should delay the decision until we have more experience with the Bing Maps visualizer.

Patrick

I would say we include everything that doesn't depend on
Scene/Renderer. Let's keep it coarse grained for easy maintenance.
The triangulation code is in Core because it's generally useful, if
something isn't generally useful, the nit shouldn't be in Core (and
therefore not part of this second combined file).

I'll also point out that we might eventually want better separation of
CZML processing versus Visualizer implementation. There's a pretty
clear line there that is blurred simply because everything is one
directory (DynamicScene). There's also some additional refactoring I
would like to do to just improve code architecture all around and make
DynamicScene more useful even if you're not using CZML.

I recently got introduced to Typed Array - Do you have any working examples of Cesium or any other JS example that demonstrates TypedArray use along with WebGL? Thanks!