Force Globe to "re-tile" an ImageryLayer without hiding/showing the layer?

CesiumJS
1

I'm working with a SingleTileImageProvider to render an image within a specified Rectangle, and I'd like to have the Scene update the rendering if the Rectangle changes.

At the moment, I see I can effect this by toggling the ImageryLayer's show property, which as far as I can tell is only causing the ImageryLayerCollection's layerShownOrHidden Event to be raised. Subsequently, the GlobeSurfaceTileProvider (private class of Globe, used in conjunction with the QuadtreePrimitive for rendering by the engine) is listening to this event and either removes or adds tiles accordingly.

Manually raising the layerShownOrHidden Event for the layer in question doesn't quite work; it appears the Globe (GlobeSurfaceTileProvider) expects a layer's visibility to always toggle from this event (not stay the same) and produces strange behavior otherwise.

Manually raising the Event twice (toggling forth and then back) does work, and is the solution I'm moving forward with for the time being. I've attached a Sandcastle export of a simple demo of this (forgive any Knockout abuse; I'm not familiar with the framework specifics) if anyone wants to play.

Is this approach kosher (manually raising these events at "random" during a render loop)? Further, does it make sense for an ImageryProvider to be "dynamic" in this sense (its content)? I see no API supporting this idea, which makes me believe it's going "against the grain" so to speak. The idea seems reasonable for the SingleTileImageryProvider (where the entire provider is "defined by the client"); thinking about e.g. WMS/ArcGIS ImageryProviders (or other providers that adapt a web/remote service), this may make sense if they support HTTP caching headers. I'm unsure of a good approach to signal this automatically without much network overhead. Maybe a periodic level 0 request, depending on what type of HTTP caching support is in use?

Thoughts?

Thanks!

Image Overlay.html (4.03 KB)

2

Hello Nate,

I think it would be better for you to use a Rectangle entity instead of a tile imagery provider for what you’re trying to accomplish. This will automatically update the coordinates by using a CallbackProperty. Here is an example on how to do this:

var viewer = new Cesium.Viewer(‘cesiumContainer’);

var imageryLayers = viewer.imageryLayers;

var viewModel = {

west: -115,

south: 38,

east: -107,

north: 40,

show: true

};

Cesium.knockout.track(viewModel);

var toolbar = document.getElementById(‘toolbar’);

Cesium.knockout.applyBindings(viewModel, toolbar);

function rectangleCoordinates(){

return Cesium.Rectangle.fromDegrees(viewModel.west, viewModel.south, viewModel.east, viewModel.north);

}

var rectangle = viewer.entities.add({

rectangle : {

coordinates : new Cesium.CallbackProperty(rectangleCoordinates, false),

material : new Cesium.ImageMaterialProperty({

image: ‘…/images/Cesium_Logo_overlay.png’

})

}

});

``

Right now this will crash if the north value is less than the south, but you could add an if statement in the callback function to swap the values if they’re flipped.

Hope this helps,

-Hannah

3

Hi Hannah,

Using the Primitive API (or Entity API) is another solution I'm evaluating, so thanks for the example. I decided to try the ImageryLayer approach mainly due to the accuracy it provides with respect to rendering the Globe with perturbed terrain (that is, a non-uniform/non-zero TerrainProvider: anything but the default EllipsoidTerrainProvider with the same ellipsoid as the Globe). As well, the ability to change how this object is visualized with respect to other layers is a win.

As it turns out, the ImageryLayer approach won't work for my needs as I'd like to be parameterize the rotation of the image, and supporting this via the SingleTimeImageProvider (or really, any of the ImageryProviders, as they're all based around the tiled abstraction) would be an uphill battle. It's simply not meant for this.

Beyond supporting my needs, I'm still curious what anyone makes of the ideas proposed regarding the static nature of ImageryProvider/ImageryLayer. Further, given my comments above, I'm curious about non-tiled ImageryProvider adaptations and how far down the rendering stack the ImageryProviders-are-tiled assumption is baked.

I'd like to keep this thread focused on those two ideas, but I do have a question about the Primitive API and zero-altitude primitives. I know that the current implementation doesn't support perturbed terrain very well / at all, but what about uniform/zero terrain? From my experiments, even this visualization breaks down when you get up close. Is this due to e.g. Globe.maximumScreenSpaceError configurations or multiple frustum rendering (where the engine is intentionally being inaccurate, due to cognizant trade-offs, configurable or otherwise)?

I know Dan Bagnell and others on the team are currently working on the `ground-primitive` branch, but I believe that is more to support the case where terrain is perturbed, not uniform/zero. I find it interesting that this will be provided by an entirely separate primitive, but I haven't been involved in the development and understand that it's a work in progress. As well, I may have the wrong understanding of what this is supporting entirely. From the sounds of it, the hard part is applicable both to "zero altitude primitive/terrain rendering" and the ability to play with 2D zero-altitude geometry as a "vector layer."

The whole height vs altitude vs elevation issue given Cesiums data model (Globe: datum == altitude, perturbed by TerrianProvider (geoid), with Geometry referenced against the Globe/Ellipsoid) is a complex one. I think I'm making heads/tails of it, but it's hard to keep straight at times. Thanks to everyone for supporting this, both past and future.

4

Nathan, I know it’s been a while since you posted this, but just to respond to a few of your comments/questions

  1. We definitely plan on supporting dynamic imagery (and maybe even dynamic terrain) in the future, but it’s on the long-term roadmap and not something we are actively working on (though we have hacked up some proof of concepts in very old version of Cesium but they are no longer relevant).

  2. We may also add rotation to SingleTileImagery provider in the future, but that’s also a long-term issue.

  3. The idea of tiling is completely baked into the imagery/terrain rendering and has to be because of the nature of the problem. I’m not sure what you meant by “un-tiled” imagery (perhaps GeoTIFF and JP2?) The nature of WebGL and JavaScript makes supporting these formats directly almost impossible (until JavaScript/WebGL/bandwidth improve) and server-side pre-processing is the only solution (though maybe you were talking about something else?)

  4. Accurate polygon on terrain rendering (with proper texture coordinate/imagery handling) is something that’s really close to happening at the primitive and entity level. It’s been a long uphill battle because of both the limitations of WebGL as well as the fact that many techniques for doing it are patent encumbered. I expect everything you want to be handled in the next 2-3 months.

  5. I’m not sure what you mean by “even this visualization breaks down when you get up close” can you explain this in more detail and/or provide a sample polygon?

  6. It’s also possible to use video materials in Cesium, though we don’t have brain-dead out of of the box support yet (though there is an out of date video branch that has 99% of the work done). In the short term, if you have dynamic imagery you want on a polygon on terrain, a video material is probably the most efficient route.

Hope that helps fill in some of the blanks. If you are still running into problems or have any questions, just let us know.

5

I have some interest in this thread as well and in particular question #1. I've been poking around the API docs to see if there's any sort of "tile invalidation" or "rect invalidation" to interact with internal caching infrastructure. Assuming that I have control over the tile map back end and would like to update a small area of the map say twice a second, what kind of options do I have?
I'm not afraid to implement either an alternate backend or a new imagery provider implementation/decorator that handles tile/rect invalidation updates from the tile server through an alternate back channel. If something like this opens up new options, that sounds easier to me than video materials.
From another angle, I'm a little worried that http cache header invalidation may not be consistent/robust enough across browser implementations to be reliable (but I'm assuming that's an option here?).

Am I missing anything in the API that addresses tile updates?

6

Interested in #1 as well. In my case, I need to clear an existing tile set for an ImageryProvider and make requests for new tiles whenever a user clicks a refresh button. I do not have control over the tile server or any server-side caching mechanisms.

Should I consider writing a custom TileDiscardPolicy, or are there other options to consider?

Thanks,
Chad