I don’t think you can take one primitive and add it to two viewers like that. There’s a lot of assumptions about the state of the primitive that won’t be compatible with this setup.
You might need to keep track of the global state yourself and synchronize the two primitives.
I think a better approach is if CesiumJS could somehow support a multi-camera view mode, that would be in the same viewer, kind of like how the imagery split works:
Can you describe more about your use case? That’ll help us collect information for figuring out if this is a feature that’ll be useful to users/the community.
There is a common need for monitoring system:
Users want to see more then one screen at the same time and each screen show a map in 3D or 2D and display diffrent images.
For example,the first shows satellite images in 3D ,the second shows road map in 2D, …
They expect the multiple screens show the same data and synchronized.
The data maybe come from server or mouse ploting.
If there is a easy way to get full property of whole primitives on one viewer and draw them directly to another viewer the synchronizing will be workable.
Supporting multiple viewports would be the right way to do this because then there would be no need to duplicate any data, and it would just be a matter of defining a second camera.
Multiple viewports would be very useful. For example, when trying to see exactly where something is underground, such as tunnels, you can only get so much info from one vantage point, you don’t know the depth. If you had a camera view from up above and from the side simultaneously you can get a sense of where exactly it is very quickly rather than moving one camera around.
One could link multiple cameras, so when you move one the other one moves along with it, so their viewpoints are always say 90degrees apart.
That’s a good point @Hyper_Sonic - adding multiple cameras to a CesiumJS scene, where each camera can take an optional “canvas” parameter, would be a much easier way to set up these multiple views rather than creating two separate CesiumJS instances and syncing them.
I’m not sure how deep of a refactor this would require - @sean_lilley is this something we’ve considered? I don’t see anything in the CesiumJS GitHub issues on it.
A couple years ago as part of the sampleHeight / clampToHeight work we moved view-specific state into a file called View.js which got us maybe 50% of the way there towards a multi-camera setup. There’s still more work to be done.
OVR_multiview could be a nice extension to make VR faster since it eliminates the need to push separate draw commands for each eye, but it doesn’t help for multi-camera setups where a separate scene traversal and command list is required for each camera. Multi-camera is more of a CesiumJS architectural problem than a WebGL one.
The problem with two separate canvases is you can’t sync GPU resources between them, unfortunately, so you would have to duplicate GPU resources for each primitive, which is a large architectural undertaking in and of itself.
I’m really keen on multi-camera myself, just haven’t had time to devote to it yet.
“-I also want to avoid having 1 canvas with 2 viewports.
-I want to avoid having 2 instances of the same scene, basically doing double the work.”
I was wondering if one could have 2 view-ports on the same canvas sharing GPU resources in Cesium, at least for primitives? (though apparently not possible if view-ports were on separate canvases.)
I suppose sharing the same tile data would be pointless when the cameras are more than a few meters apart from each other, as they’d likely be seeking different LOD levels due to their different vantage points. (perhaps in the case where they both look at the same target from the same distance just from different angles they could, but that would be just for a special case.) I suppose this would apply to other things that have different LOD levels as well, such as 3D tiles.