where the user can specify the endpoint script-run time (the third parameter in the above line) and the other values would be linearly interpolated between the start and end. (An enhancement would be spline interpolation). (At the beginning, I'll limit the tool to work only for both keyframes with the same body in focus).
\nDo you see any unsurmountable problems for making such a tool?
\nIt could perhaps be implemented in javascript and made into an html control page, or I could write a c++ console application using cin/cout. Any preference?
In principle I don't see much of a problem with that. The issue is going to be how to generate the intermediate camera positions and orientations. A straight linear interpolation will go through the planet with your example. While making those transitions nicer, you'll be ultimately reimplementing our automatic camera movement to make it look nice.
\nBefore you start, also have a look at the https://github.com/OpenSpace/OpenSpace/tree/feature/keyframing branch that has some of those functionalities in it, but we haven't had the time to integrate it into the master branch
shall I make a tool for extrapolating from one (camera position and time) to another #3294
-
|
Hi @alexanderbock - after looking at the format of the recording files - osrectxt files in particular, since they are human readable - I thought I would try and make a tool to create osrectxt files to smoothly move the camera + change the time from one keyframe to another. For example, I would save a camera position and time when it is noon over England, zoom out, save one more keyframe, move to Cape Kennedy and advance the time to local noon, zoom in with desired orientation yaw and pitch, save that - and the tool would generate lines like where the user can specify the endpoint script-run time (the third parameter in the above line) and the other values would be linearly interpolated between the start and end. (An enhancement would be spline interpolation). (At the beginning, I'll limit the tool to work only for both keyframes with the same body in focus). Do you see any unsurmountable problems for making such a tool? |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 3 replies
-
|
In principle I don't see much of a problem with that. The issue is going to be how to generate the intermediate camera positions and orientations. A straight linear interpolation will go through the planet with your example. While making those transitions nicer, you'll be ultimately reimplementing our automatic camera movement to make it look nice. Before you start, also have a look at the https://github.com/OpenSpace/OpenSpace/tree/feature/keyframing branch that has some of those functionalities in it, but we haven't had the time to integrate it into the |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @alexanderbock . (I'm planning a simplistic implementation, where the user has to take care of things like not moving through the planet and so on:) |
Beta Was this translation helpful? Give feedback.
-
|
Here is the link to the present version of the "interpolation tool" - https://github.com/hn-88/OSREC-interp |
Beta Was this translation helpful? Give feedback.
-
|
Hi @alexanderbock - as long as I was just concatenating camera keyframes by just changing their timeOs and timeRec values, the OSREC-interp tool worked fine. But when I tried interpolating intermediate keyframes using spherical co-ordinates so that the "moving through the earth" problem would be solved, I get weird behaviour - the entire globe starts getting distorted and jerky. Example test files, I have shared the osrectxt files and the spreadsheet created to test the interpolation (which seems to be fine) at this shared folder. Any insights would be most appreciated. |
Beta Was this translation helpful? Give feedback.
-
|
A video of the jerky motion is at https://drive.google.com/file/d/10Vp0xPLQjSXGtugwkaP2lvsYrHiVTvvF/view?usp=drive_link |
Beta Was this translation helpful? Give feedback.
-
|
I think I see the reason now - my assumption that the quaternion can be simply linearly interpolated was wrong. Probably I should convert to Euler angles and interpolate as suggested here https://www.opengl-tutorial.org/intermediate-tutorials/tutorial-17-quaternions/#how-do-i-create-a-quaternion-in-c- Probably the invalid quaternions (not normalized) were causing the jerking motion. |
Beta Was this translation helpful? Give feedback.
-
|
@hn-88 interpolating the quaternions should be totally fine, and is often preferable over interpolating Euler angles (one of the main benefits of quaternions over Euler angels is that they are much more suitable for interpolation) However, you need to use the method known as SLERP (Spherical Linear Interpolation) when interpolating between quaternions. I'd recommend using a math library like GLM for this computation. And yes, as you're saying, the quaternions have to be normalized :) |
Beta Was this translation helpful? Give feedback.
In principle I don't see much of a problem with that. The issue is going to be how to generate the intermediate camera positions and orientations. A straight linear interpolation will go through the planet with your example. While making those transitions nicer, you'll be ultimately reimplementing our automatic camera movement to make it look nice.
Before you start, also have a look at the https://github.com/OpenSpace/OpenSpace/tree/feature/keyframing branch that has some of those functionalities in it, but we haven't had the time to integrate it into the
masterbranch