glTF modifier: fixed case of raster overlays

[Julot94]

GltfModifier: made it compatible with raster overlays (the initial revision of Gltf modifier was just ignoring them - so as soon as a modification was re-triggered, any cut-out polygon applied to the model would just be lost)

• raster overlays (computed as post-process) need to be recomputed after the modification step.
• in the case of the re-apply path (see reapplyGltfModifier), we need to restore the initial tile bounding volume, because the post-process can lead to set an empty bounding volume, which would trigger plenty of false positive errors when re-running the post-process on the tile.
• for up-sampled tiles, the re-apply path consists in up-sampling the modified parent (and not run the modifier on the current up-sampled tile...)
• in the the re-apply path, we must take the result of the modification step into account: if the modification step fails (which can now happen in case of up-sampling...), we still keep the current model, but we should notify the next step to avoid a crash when trying to set null resources to the rendered tile
• added a shared-mutex in TileRenderContent to fix a potential crash when the game thread is replacing the parent tile's content (replaceWithModifiedModel) while a worker thread is currently up-sapling it for one of its children

[j9liu]

Thanks @Julot94! @kring would you be able to take a look when you get the chance? I think you'd have a deeper understanding of the sequencing/lifetime implications here

[kring]

Thanks for the PR @Julot94! This is trickier than I originally anticipated.

My initial thought is that we'd really like to treat upsampling as just another way of loading a tile. So, just like with normal loading, we would always upsample first, and then apply the GltfModifer to the upsampled tile.

As you know, one problem with that is we have to be careful to sequence the upsample and the GltfModifier run. Both need the model as input, and the latter destroys and replaces the model, so doing both at the same time will result in undefined behavior. I think this problem is relatively easy to solve, though, and in fact you've done so in this branch. My main suggestion there is that you avoid the use of a mutex. A simple boolean should suffice, because both operations are initiated and complete in the main thread.

Another problem is that we usually don't upsample a tile until later, after the GltfModifier has already run on it. So we'll end up upsampling from a tile that has already been GltfModified, and then GltfModifying the result of that upsample, too. But I think this is only a little worse than the usual GltfModifier situation where each new version starts with the results of the previous one. A GltfModifier implementation just needs to be non-lossy and produce deterministic results on re-application.

So that seems preferable to me over the alternative, which I believe you've implemented here, where GltfModifier only runs on the real tiles, and then the modified tiles are upsampled. But maybe there's some reason the alternative is required or preferred? What do you think?

[Julot94]

Thank you @kring for reviewing this one.

• I will try to get rid of the mutex, indeed (there must be a way to ensure we don't initiate "conflicting" tasks with an appropriate test in the game thread)
• regarding the upsampling, I will try to follow your suggestion as well - I think I ended modifying the reapplyGltfModifier path with way because our specific implementation of glTF modifier is lossy at some point. I should probably fix that and keep things simpler in the Cesium code...

[Julot94]

Hello @kring ,
I updated the PR, following your suggestions