Camera track is not the same in edit and after timeline rendering !?

[Someone_fromjapan (Hale)]

I was trying to position camera by key-points in the timeline.
Because of some kind of track interpolation, it does not move linearly, but always finish in the recorded position at the key frame. It makes possible correcting the track using extra keys in the timeline.

However, I found, that during the rendering, camera never finishes in the recorded position at the key-frame.
Rather, it follows kind of “Least squares” path, floating left,right, and tilting uncontrollably.
So my 2 day renderings all went to crap.

At the moment I use ParaView 5.5.2-476-gbf53b3e nightly (release for windows crashes with my data, so I have no options here)

It looks like camera path interpolation algorithm is different in editor, and in rendering(save animation) modes.
Is there a way to replacing the “smooth” algorithm with linear interpolation between camera configuration parameters at key-frames?

[Someone_fromjapan (Hale)]

So, does anyone know what’s going wrong with camera when saving animations, or what am I doing wrong?

[shawn.waldon]

@Someone_fromjapan

Because of some kind of track interpolation, it does not move linearly, but always finish in the recorded position at the key frame. It makes possible correcting the track using extra keys in the timeline.

This is expected. ParaView uses cubic splines to interpolate the camera positions.

@Someone_fromjapan

However, I found, that during the rendering, camera never finishes in the recorded position at the key-frame.
Rather, it follows kind of “Least squares” path, floating left,right, and tilting uncontrollably.

I’m not 100% sure what you mean, but this may be helpful: The camera position is not the only thing that is interpolated. The camera focal point (where it is looking) is also interpolated along another spline. You may have to edit that one too. If you double click on your camera path in the animation view and then double click on the Path... in the Camera Values column, you can edit both the position and focal point control points.

@Someone_fromjapan

It looks like camera path interpolation algorithm is different in editor, and in rendering(save animation) modes.

I’m not sure… it shouldn’t be.

@Someone_fromjapan

Is there a way to replacing the “smooth” algorithm with linear interpolation between camera configuration parameters at key-frames?

Not as far as I know.

The splines approach we use for the camera has limitations, especially with the rotation of the camera. I’ve fixed the common case of an orbit a few years ago, but there are some strange behaviors in there if your path is weird enough. Basically we only interpolate the camera position and focal point, we don’t handle the “up” direction of the camera right in all cases. This means that the camera can be pointing the right direction, but rotated strangely about the axis it is looking along if your path triggers the corner case.

[Someone_fromjapan (Hale)]

The camera position is not the only thing that is interpolated. The camera focal point (where it is looking) is also interpolated along another spline. You may have to edit that one too.

That’s very sad. Because when I save camera in the timeline, I expect everything to be saved about it.
And in the view-port, it appears like this. But in rendering, it is not.

then double click on the Path… in the Camera Values column, you can edit both the position and focal point control points.

Of course. And I save these as I see them in the viewport. End the configuration is reproduced when the field is called in the editor. But during rendering, camera misses these values; going somewhere else by “inertion”.

I’m not sure… it shouldn’t be.

But it really looks like this. I would say, if the viewport can be 3-point interpolation, the rendering looks like an approximation with the polynomial of 5th order, that “oscillates” +/- Infinity between points on sharp turns.

BTW, Since you mentioned the focal point, I have to say that the mouse control is very hard to use, because it neither controls the distance to focal point not position of that point. And the focal point itself is not obvious.
Only FOV seems to be controlled, but called “ZOOM”, which brings more confusion. ZOOM is neither FOV, nor distance, but just a 2D enhancement of image; not very applicable to 3D editing.
In result, it is very hard to control camera.

Why don’t the dev. team look at the experience of other 3D software, starting from 3Dstudio, till modern products? Talking about simplicity, the simplest 3D control I ever seen was in HFSS editor. And it never failed. Some software offers adaptive focal/rotational point, locking on objects, or at the average distance of the swarm. And mouse rotation is usually made by the intuitive model of the “crystall ball”; reacting according to the side you “touch” with the mouse.
But in Paraview I can not intuitively understand where is the rotation vertex/focus, where should I move mouse to rotate in particular direction.

but rotated strangely about the axis it is looking along if your path triggers the corner case.

Do you mean roll? well, it is common, and at least natural, like the Berry phase. (consider rolling along the surface, defined by camera position and focal point trajectories) slowly rolling away because of coordinate transformations is one thing, but loosing this “surface” is very different.

[shawn.waldon]

@Someone_fromjapan

And in the view-port, it appears like this. But in rendering, it is not.

The viewport playing the animation doesn’t match the resuting rendering? Have you tried with “Preview mode” to get the aspect ratios to match? That should be the only difference. If there is any other difference, it is a bug.

@Someone_fromjapan

But it really looks like this. I would say, if the viewport can be 3-point interpolation, the rendering looks like an approximation with the polynomial of 5th order, that “oscillates” +/- Infinity between points on sharp turns.

It should be a series of 3rd order polynomials that hit all of your points or a cubic spline. They are stitched together at each point with the position and derivative matching at that point (so the camera movement is smooth). If the spline is oscillating rapidly, then something about your path is causing it to decide that is the best way to hit all the points in a smooth way.

@Someone_fromjapan

Why don’t the dev. team look at the experience of other 3D software, starting from 3Dstudio, till modern products?

It hasn’t been a priority. The people who fund ParaView development want other features more. We know the animations need to be reworked, but don’t have the time or funding to do it. You are welcome to contribute fixes yourself if this is a feature you need or you could hire Kitware to do it.

@Someone_fromjapan

Do you mean roll? well, it is common, and at least natural, like the Berry phase. (consider rolling along the surface, defined by camera position and focal point trajectories) slowly rolling away because of coordinate transformations is one thing, but loosing this “surface” is very different.

Yes, I meant roll. I put in some hacky fixes a few years ago to make it better, but I didn’t have time to do a complete overhaul and fix it fully. But it doesn’t sound like that is what you are talking about.

[Someone_fromjapan (Hale)]

The viewport playing the animation doesn’t match the resulting rendering? Have you tried with “Preview mode” to get the aspect ratios to match? That should be the only difference. If there is any other difference, it is a bug.

Yes. That’s what I am telling. I recorded every camera position in the timeline. Then scanned the preview frame by frame.

After rendering the animation, camera was dancing like in tropical storm, especially closer to the end of sequence, where it should stand still, and many camera key frames were duplicated along the timeline.

Moreover. When I found that, I added more keyframes in between. Rendered the last 50 frames in animation, and again, it never fit neither the preview, with defined keyframes, nor previous rendering (probably, because previous rendering started earlier, and there was error accumulation.

You are welcome to contribute fixes

Oh, If I could. I have so many ideas today, but was so lazy learning software programming in my schooldays. Maybe when I change current job (requiring from me a lot of simulations and visualizations btw.)