Except instead of multiple viewers (canvasses, thus contexts) I would like multiple views per context. This greatly simplifies things by allowing for a simple reinvocation of the main draw loop with a different camera, projection, and stencil.
Otherwise trying to mirror data between viewers gets absurdly complicated when operating off of nondeterministic data.
Another solution would be to cache all draw commands per frame and copy them to the other viewers, but I doubt culling would allow that.
So in a fork, at where in scene (or elsewhere) would be best to insert this?
This is non-trivial to implement but is on the long term roadmap. We laid some of the groundwork with our VR support, but a lot more work needs to be done before true multi-camera support is available. Because of the amount of work involved, there’s no straightforward answer to your question.
there’s no straightforward answer to your question.
Yeah I know. I’m asking for generalities.
How coupled is scene._camera, and its getter? Will I be fine replacing _camera with _cameras (array) and changing any getters to _cameras[0] and relying on syntax errors to finish it? Just in general what needs done.
I’m not sure I’ll have time to contribute any changes myself due to seething hatred of js and writing tests, but I’ll at least dump my modded czm classes
Or! I could approach this entirely differently. As I can reissue commands, but if cameras are distant, theres strong issue with keeping geometry loading which would need dealt with, which would be a whole separate ordeal in itself.
So I’m now thinking, have multiple viewers, instantiated onto a single context. I’ll need to create a ViewerGroup which somehow wraps several viewers with options for their canvas-space transformation and stencil, and schedules their updates as synchronous and ordered.
Unfortunately I’m not really familiar with czm’s internals, other than it being based on commands which are culled and sorted (I’m strongly opinionated towards statically sorted queues, since misc state like culling order and blend mode realistically never vary per object per frame)
I realize this is a not small task no matter how its approached, but the project I’m assigned to unevitably requires it.
If I can get verbal help with generalties I should be able to at least get some worthwhile progress.
Sorry, I don’t know the answer to your questions, but I’ve asked my coworker if he can give you some info. He’s out of the office right now, so it may be a little before he can get back to you.
This is on the road map and we’ve made a lot of incremental progress with first the support for Cardboard and then the PR in progress for infinite horizontal scrolling in 2D. However, Matt is right, there is still a lot of work to be done and would be a huge undertaking for someone unfamiliar with Cesium internals. If you just want to show it can be done, I can show you where to hack it in. The main thing that would be still be broken is the default mouse handlers, which is the biggest problem. And that’s just if you only need 3D working, otherwise, you need to make it play nice with multiple scene modes, Cardboard/VR and the new 2D scrolling.