Skip to content

Home

Jump to bottom
hn-88 edited this page Jul 10, 2024 · 12 revisions

Notes on creating an interpolation tool

The interpolation tool is located at https://github.com/hn-88/OSREC-interp/

  1. We want to interpolate from one camera position and display scene time to another camera position and display scene time.

  2. Checking user/recordings/white cliffs of dover.osrectxt as an example, taking a "camera" line,

camera 1073.7 0.0553776 770081379.966 4002368.0463012 96499.4704563 4966105.2932419 0.4296178 0.6793493 0.5945727 0.0199097 27.81600189208984375 F Earth

which is

(type of entry, camera in this case) (time of OS) (time in the recording) (time of the displayed scene) (8 co-ords) and the Focus, Earth in this case.

Later note: this is explained very well in the documentation, https://docs.openspaceproject.com/en/releases-v0.20.0/content/session-recording.html#ascii-file-format

  1. First step - the time co-ordinates. The time step between lines seems to be unequal. Checking using a csv created by replacing space with comma and opening in Google sheets, we get a slightly jittery 3rd field, but approximately equal to the 2nd field when 1sec = 1sec. (private GSheet) Eg.
-0.04 | -0.041277
-0.04 | -0.039383
-0.04 | -0.040683

Later observation - the time interval between keyframes in the recording seems to be hardware dependent. On a machine without an Nvidia GPU, the interval was 0.2 sec instead of the 0.04 sec seen above for the accelerated machine. So it probably depends on the frame rate of playback, so for good smooth playback, we can probably aim for 0.04 or 0.016 for 60 fps etc. Or, since Openspace will anyway render the intermediate frames, can try with not interpolating at all! Actually, we do need to put some extra keyframes, or do interpolating with cylindrical co-ords, otherwise Openspace will "move the camera through the Earth" due to linear interpolation.

  1. BTW, the internal time field in OpenSpace seems to be the number of seconds since the year 2000.

  2. The recording data starts here in the code. Reading the code, the first three time fields seem to be timeOS, timeRec and timeSim. And timeSim is in the number of seconds since the year 2000 as noted above. timeRec is in number of seconds of "playback time." timeOS seems to be time since OpenSpace was started, in seconds.

  3. The keyframe recording code, for the other fields, seems to be here and further, the overloaded addkeyframe functions here.

  4. For camera keyframes, the next fields are likely to be position as glm::dvec3 (3D vector of doubles) and then orientation as a 4D vector, etc. As seen in struct CameraKeyframe. It is this dvec3 which seems to be overflowing?! in the lines following line 1410 at the zoom out recording. - Apparently it is the Scale which was losing precision and going to zero - https://github.com/OpenSpace/OpenSpace/issues/3050#issuecomment-2143479126

  5. The position glm::dvec3 seems to be in metres, cartesian coords (from the centre of the Earth, if Earth is the object in focus.)

  6. The angle glm::dquat is a quaternion - q=[s,xi+yj+zk]

  7. But we can simply create enough keyframes along our path so that we can just allow Openspace to interpolate all the values.

Clone this wiki locally