search

WorldWindEarth / worldwindjs

WorldWindJS is a community maintained fork of the WebWorldWind virtual globe SDK from NASA - an interactive 3D globe library featuring maps, imagery and terrain plus 2D map projections.
https://worldwind.earth/worldwindjs/
38 stars 9 forks source link

Free camera navigation is missing #32

Closed ComBatVision closed 4 years ago

ComBatVision commented 5 years ago

Basic LookAtNavigator implementation allows to change view point based on surface point and view angles of this surface point only. Camera can not view above horizon.

New feature is required to control camera independently. This feature will allow to implement UAV perspective view according to its telemetry or any other solution required free camera angles from eye point specification.

I propose to add this feature via PR.

ComBatVision commented 5 years ago

Hello team, @emxsys @wcmatthysen and others. I need your assistance in discussion of correct solution of current problem.

I have dirty solution to control camera independently of lookAtPosition, but it was made using dirty override of several core worldwindow functions and can not be applied as production solution.

I have researched the correct ways to solve the problem and found following blockers:

1) LookAtNavigator is based on obligatory existence of lookAtPosition attribute. It does not technically support situations, when camera is looking above horizon (when lookAtPosition is undefined and navigator is defined directly by camera position and first person heading, tilt and roll). LookAtPosition is currently required by BaseWorldWondowController to control gestures and WorldWindow.computeViewingTransform to apply modelView.

2) WorldWindow.computeViewingTransform takes navigator.lookAtPosition inside the method and extract EyePoint on the go. It does not allow to read freely defined EyePosition from navigator attribute and draw frame correctly even if lookAtPosition is undefined.

I propose complex refactoring of Navigator to make it looks like Android one and need you confirm: 1) Navigator should be defined by camera position and first person heading, tilt and roll (not by lookAtPostion). 2) Navigator should have functions which export camera position to LookAtPosition and define its state from incoming lookAtPosition, but store its state in terms of camera position inside LookAtNavigator. 3) BaseWorldWondowController should use getAsLookAt and setAsLookAt functions instead of direct lookAtPosition attribute access, which will no more exists. If camera is looking above horizon, then it will return backup point on the horizon to be a start point of possible gesture. 4) WorldWindow.computeViewingTransform should read EyePosition from navigator attributes and will allow to render frame even if camera is looking above horizon. 5) I also propose to fix near clip distance calculation in WorldWindow.computeViewingTransform during this refactoring stage as I have already done in Android version.

Do you accept this refactoring? Can I start to prepare such pull request? It will affect many files, but it is the only way to support freely assigned camera view.

wcmatthysen commented 5 years ago

@Sufaev, sounds good. I'm not too familiar with worldwindjs. But, I'll be happy to assist if we port this to WorldWindJava.

emxsys commented 5 years ago

@Sufaev I support your effort. But first, please see the following branches in the upstream repo for Camera work that was started in WebWorldWind, but not finished/merged. These branches were in support of a larger camera enhancement effort based on this unmerged PR from ESA: https://github.com/NASAWorldWind/WebWorldWind/pull/101.

I suggest you align your efforts to this (stale) work-in-progress. Perhaps we can bring it to fruition.

ComBatVision commented 5 years ago

@emxsys It looks like this branch contains the enhancement which I proposed. I will try to finalize it.

ComBatVision commented 5 years ago

@emxsys Is it possible to have quick discussion of camera_support enhancement with those who start doing this branch or may be you can answer my questions? I have reviewed the code and found some architectural differences between their approach an Android implementation, which I planned to port. I want to understand which approach is more correct one.

1) Android has Camera and LookAt classes as simple models without any transformation logic inside and LookAtNavigator class to convert Camera to LookAt and backward, but Camera_support branch has transformation from Camera to LookAt in the Camera object itself and Navigator object is marked as obsolete. 2) Plus Camera_support has many backward compatibility code, such as LookAtPositionProxy. I want to understand if it is required now in our branch? 3) One minor difference - Camera_support has Position attribute to hold coordinates in LookAt and Camera, but Android for some reasons has direct lat, lon, alt attributes without wrapping it to Position. 4) And the most interesting question - why this branch was not merged? It looks like everything required for refactoring was done: Camera and LookAt objects created, WorldWindow modelview calculation switched to use camera instead of navigator, BaseWorldWindowController and ControlsLayer was updated to use camera, tests are present, even issue was closed. What was wrong?

Which approach to use and why there are such differences? Should we refactor Android to use same approach as web?

ComBatVision commented 5 years ago

Answer to p. 4 - there is a bug with projections other than wgs84, applications are not migrated from navigator to camera, keyboard navigation is not migrated to camera.

I am in process of finalizing this stuff...

ComBatVision commented 5 years ago

Fixed in PR #39

ComBatVision commented 5 years ago

Hello, team. Does anybody tested this refactoring? Do you accept merge?