[Fractux]

Edit: Sorry the title isn't really appropriate.

I was working out camera movements in Fred for some ingame cutscene planning I was doing, and I was experimenting a bit. This method does not cut it for the cutscenes, as it is too"jittery", but I'll ask anyways.

I have the following loop setup so that I can have the camera fly from one position to another:



However, this loop will run through (and hence the camera move much faster) on a faster system (say 3GHZ), and slower on a sub par (say 1GHZ) system.

I'm just not sure how much faster this movement would occurr.

While I'm at this, does anone have any better camera movement techniques that won't cause jitteryness?

[Fractux]

Well, I was doing a few more tests, and if you're far enough away from a ship, you dont notice the jagged movements, but I'd have to test on systems of varying speeds to check that the movement is alright.

I realize that there is a problem in this current list with setiing start positions, but I'm working around that right now.

[Goober5000]

One thing you could do, as a short-term fix, is to calibrate the speed counter at the beginning of the mission with a known benchmark.  Say, count how many loops it takes for a 50 m/s transport to fly 50 meters (or 500 and divide by 10).    The answer is the number of loops per second.

(Special thanks to whoever posted this previously; it wasn't my idea. )

The better, long-term solution is to ask WMC to add dollying support to his camera code.

[Fractux]

Yeah, I saw that last thread about calculating speeds as well.

I think the main problem is the shaky movement when you're close up. I'll try the other method to see it's results, but a feature request might be the only solution.

[Fractux]

OK well, here are two methods.

The first method is the one I had at first. Now, with this method, you can really slow the camera down, but it has a some problems.

You have to make sure that the counter, when divided comes out to the exact start position, or else the camera will jump back, and there will be a delay before the camera moves. This makes it a real pain, but this was the only way that let you slow down the camera enough. At the same time, it's really jittery, unless you are far away from objects.



The second method is much clearer, but you can't slow the camera more than the given example, because FRED/FS2 can't deal with fractions this way. It seems it only accepts them in methods as posted above.

This method doesn't have the problem with setting the starting location, and the fast camera movement makes it hard to discern the jitteriness. The only thing to remember is that when you increase the speed, you need to decrease the counter to cover the same distance.



[I know the division to set speed is not needed, but you can see what I was trying to do - so you could just set speed(0) to the unit you want (1,2,3... and then divided the counter distance)]

Anyways, as was metioned above, we really just need a camera-dolly SEXP.

[WMCoolmon]

Originally posted by Goober5000
One thing you could do, as a short-term fix, is to calibrate the speed counter at the beginning of the mission with a known benchmark.  Say, count how many loops it takes for a 50 m/s transport to fly 50 meters (or 500 and divide by 10).    The answer is the number of loops per second.

(Special thanks to whoever posted this previously; it wasn't my idea. )

The better, long-term solution is to ask WMC to add dollying support to his camera code.

I've been looking into that...I'm not sure if I committed this to CVS, but I started adding some code to try and use the vm_matrix_interpolate for the camera movement function.

set-camera-position should work the same as set-camera-rotation, and be able to accept an acceleration time and total movement time, unfortunately it just moves the camera instantly.

I'm focusing on Tables work for now though...I'd like to get that done before I start anything else.