doxel / doxel-viewer

GNU Affero General Public License v3.0
7 stars 2 forks source link

Define new camera paths #19

Open bugdanov opened 7 years ago

bugdanov commented 7 years ago

It would be nice to have to allow the user to define camera paths or to define automatically camera paths.

For example between the nearest poses instead of sequential poses, or rotating around the "center"(s) of the cloud (where the density is higher)

The potree viewer we use is using three.js and three.js controls, and if we where moving the scene camera, it would jump back where it was set by the three.js controls when using the associated input device.

Thats why new camera position/rotation must be reflected in three.js controls internal variables (we had to study the three.js controls code for this - we do not support every three.js controls yet)

You can look at how it's done today for doxel-viewer, where we interpolate the camera position/rotation between poses while scrolling the images list or when selecting a given thumbnail, or when using the play button.

From here and below https://github.com/doxel/doxel-viewer/blob/96c91c05cade1f448df63a0f666e1ea9d14cdc37/js/doxel-viewer.js#L656

In the viewer there is always a pose selected (thumbnail). It is the current integer pose. We interpolate the camera pose between the integer poses, call it the interpolated pose.

The user is always able to move or rotate the camera using the three.js controls while we move the camera.

To allow this we compute the relative translation/rotation between the current pose position/rotation and the current camera position/rotation, then we apply this relative translation/rotation when moving the camera on the path (which in our case is the path between poses - for the play and scroll modes)

However it would also be possible (but less nice) to simply disable the three.js controls while moving the camera

bugdanov commented 7 years ago

Maybe there should be two vectors: the flight path vector and the view vector

bugdanov commented 7 years ago

Maybe we should first use keys / mouse / inputs or whatever to define waypoints:

With waypoint I mean "a set of states with optional transition functions"

Then define transition functions to change from the previous states to the current ones (linear by default, only the number of steps and the frequency (if not maximal) would have to be specified)

For example there could be

bugdanov commented 7 years ago

Transition functions could be curves drawn with the mouse or the touch screen, or png images of curves the user could select. The frequency of changes and the duration of the transition would have to be specified

bugdanov commented 7 years ago

During the Hackday 2017 event organized this year in february by the national swiss TV channel, I made a quick proof of concept, you can try in branch camera-path-demo

I did replace brainlessly (hacked) the camera pose list and the thumbnail bar used for navigation, in order to re-use the existing camera pose interpolation and relative movement support used for the play mode as-is, instead of refactoring it and implement yet a clean solution usable both for the virtual camera paths and the real camera path.

Also functions for transitions mentionned in comments above are not yet implemented.

If you open the sidebar in the Potree viewer you can clear the thumbnails list, then add virtual poses after moving the camera in the cloud using threejs controls, then switch back to orbit or earth control and press the play button.

Depending on the current navigation control type enabled and orther unhandled conditions (aka bugs) you will have to reload the page and try again... (pull requests welcome)

To be continued...