Tilted 3D view corrections for 2D sync

[klokan]

If the view is tiled substantially, then the center point of screen is not anymore an ideal center of synced 2D view.

This means we may see a completely different things in 2D then we see in 3D. A general perfect solution is not known (to me), but this ticket may try to find one good enough for now.

Related: because the resolution for 2d view is calculated from the center point of screen where interaction happens as well, there may be an (expected) issue with synchronization of the view and resolution calculation without moving the center. The worst case scenario is visible here:

[klokan]

When internally discussing this in Klokan Technologies team, we come up with a possible simple solution by implementing "Quarter Screen Picking Correction".

See this recording: http://youtu.be/cVqFrHJ6EX0 and the red dot which is preserved (in first implementation).

The idea is that instead of synchronizing the 2D map on center we will synchronize it on a lower quarter of the 3D screen where we will move the picking point. To display a correct center in 2D the correction may be made by shifting back in 2D for a quater of height of window in pixels.

See this recording: http://youtu.be/nKWjISp5blg for the above resolution degradation issue and a possible solution with "Quarter Screen Picking Correction".

Comments on this approach and suggestions for alternative corrections algorithm from C2C team would be very welcome.

We need a consensus on this and an approval that this is the right solution which should be implemented (as a time consuming correction of interaction algorightms are required).

[gberaudo]

This solution seems to me a clear improvement over the current state.

I would suggest creating a pull request so that we clone it and test.
A branch on your private repo will not work as I am still getting
404 errors upon access.

[klokan]

@gberaudo there is pending invitation on your github account for getting access to klokantech/ol3-cesium since the last week. The code of the demo is in our private branch "quarter".

The above is a proof-of-concept - not ready to be merged, not ready to be code reviewed really, a fully bidirectional correct 2D-3D sync may need new or improved sync equations.

The approach implemented now in master is exactly as specified in #9 for the initial implementation.
The existing master code is a very straightforward and natural implementation which is always correct (for various map projections in 2D).

This ticket is calling for an improvement - something extra on top of what was promissed.

I think the biggest idea on the "Quarter Screen Picking Correction" above was to try to make the 2D shift by pixels, instead of tring to solve everything directly in geo coordinates and 3D, which would require at least two pickings or more for each frame and more complicated math. This 2D pixel shift approach could be improved further or denied if unsolvable problems appear.

There is a lot of open questions here and no clearly described target we want to reach - and also no budgeted development time (at least on our side).

Is there a 2D-3D side-by-side view reliably and "correctly" implemented somewhere?
A demo with displayed terrain we could reverse engineer? A scientific paper?

It is not always clear what is really "correct" in certain situations with terrain turned on and tilted camera.

[gberaudo]

@klokan there is no trace of the invitation in my mailbox. Please try resending the invitation.

[klokan]

Resent. Check your SPAM folder on the email address you have on GitHub.
It says: invitation sent by email. It can be accepted at https://github.com/klokantech

[gberaudo]

It working now, thanks. It was an issue with my email address.

[laterdude]

Hello, I was curious about the status of this idea, I've got some time and would love to assist on the math of sync'ing up the 2 views. Let me know if this is still on your guys radar. Thanks and take care.

[gberaudo]

Hi @laterdude, thanks for proposing your help. It would be awesome to see experiments on these ideas.
I will probably not have much time to invest on this but I can guide you to understand the current code.

Have you compiled and run the code already? Did you look at the src/camera.js file?

[laterdude]

Actually I've struggled to build the code, I've been working on windows 7 machine on a United States Forest Service computer network, and though I've got ant and the gnu make binaries loaded up, for some reason mingw isn't playing nice with some old installations. I was going to try and build it with cygwin this weekend though. I ended up just using the zipped file for the project I'm working on for the wildland firefighting program. Anyway, yes, I would appreciate any background on the code, is the camera.js file where most of the relevant code lives? I looked deeper into klokan's work on it yesterday evening and was going to check out esri's implementation this week, I'm not sure if their latest arcgis setup provides a similar side-by-side view option, but if so I'd like to see how it compares and try to get a sense of the transformations they might be utilizing.

[gberaudo]

OL3-Cesium compiles on GNU/Linux and has been known to work on Mac. However, it has never been tested on Windows. The quickest option may be to run the compilation and developer server inside an Ubuntu VM.

The camera.js file is where the computations occur. You may want to start with the two high level functions olcs.Camera.prototype.readFromView and olcs.Camera.prototype.updateView.

Don't hesitate to share your findings about how ESRI is hadnling this, if it does.

[laterdude]

Thanks for the tip, I'll give cygwin a try tomorrow am and if it's a no-go
I'll give linux a try by the weekend. I'll keep you abreast regarding
esri's take. True enough, they might not actually have the side-by-side
option, so if there's something obvious and out in the open
I'll definitely take note. They just released their production 3d api not
too long ago, anyway, if the functionality isn't in there, I don't mind,
that just means you guys are way ahead of the curve and makes for a more
interesting problem. Do you happen to know whether the cesiumjs project's
camera code and zoom functionality has been relatively stable since you
guys last touched this? I'm going to take a look at the commit dates and
whatnot, but just curious if you remembered anything off the top of your
head in particular.

in the meantime here's this: can't find the camera tilt yet: https://developers.arcgis.com/javascript/latest/sample-code/views-synchronize/index.html

On Tue, May 24, 2016 at 2:26 PM, gberaudo notifications@github.com wrote:

OL3-Cesium compiles on GNU/Linux and has been known to work on Mac.
However, it has never been tested on Windows. The quickest option may be to
run the compilation and developer server inside an Ubuntu VM.

The camera.js file is where the computations occur. You may want to start
with the two high level functions olcs.Camera.prototype.readFromView and
olcs.Camera.prototype.updateView.

Don't hesitate to share your findings about how ESRI is hadnling this, if
it does.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#24 (comment)

[gberaudo]

Thanks for the information @laterdude. I tried your link, you can tilt using the mouse right button.
It looks like they are also synchronizing the center of the screen.

[laterdude]

It seems to follow the same behavior on zoom out as ol3cesium, ie, when
tilted, if you zoom in on the tilted 3d map, and then zoom out, the target
shifts substantially. Is this the desired behavior? My preference is that
perhaps that you should return to your point of origin, so that if the
mouse pointer remains in a constant position the map should zoom in and out
to the same locations rather than skipping across the face of the 3d globe
with every repeated zoom in/out cycle. Is this idea not in alignment with
what is considered to be ideal?

On Wed, May 25, 2016 at 1:24 AM, gberaudo notifications@github.com wrote:

Thanks for the information @laterdude https://github.com/laterdude. I
tried your link, you can tilt using the mouse right button.
It looks like they are also synchronizing the center of the screen.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#24 (comment)

[gberaudo]

There are several ways to zoom in and out in 3D.

• using the mouse right button;
• using the mouse wheel.

Using the right button, the target is chosen (point clicked of the globe) when you click and thus you should go and come back at the same position. The camera should travel along a line going from the camera position to the target point.

Using the mouse wheel, the target is chosen at each elementary move of the wheel. The target point is probably taken by Cesium to be the center of the screen and the movement is a succession of segments of different directions.

This is a bit complex and should be fixed / improved in Cesium itself. I agree with you it would be a great improvement.

On the other hand, when you zoom in/out in the 2D OpenLayers map then it is only OL3-Cesium code.