[Pilot Of The US]

Just started this thread on someones advice, to get some ideas about cut-scene sexp.
Here are some that might be worthwhile adding.

Rotate-Around Object
Rotates the camera around an object/ship. Basically combines the "camera-rotate" and "set-camera-facing-object" sexps.

Camera-Waypoints
Makes the camera follow a set of waypoints with speed setting. Also should have a variable for setting the camera facing.

[WMCoolmon]

Rotate-Around Object
Rotates the camera around an object/ship. Basically combines the "camera-rotate" and "set-camera-facing-object" sexps.

Doable, though it'll require a lot of math work to get working. What's your intended use for it? I would think that relative movement/rotation SEXPs would be more useful in most situations, although I'm open to ideas.

Camera-Waypoints
Makes the camera follow a set of waypoints with speed setting. Also should have a variable for setting the camera facing.

Evil!

I think Goober made this sound easy in one of the other threads. I'm not so sure. I can have the camera move along a set of waypoints, sure...but having it do so smoothly is another matter entirely. I'm not sure how one would actually go about accomplishing that; doing it directly requires more maths knowledge than I currently have, and doing it via FS physics (Like the AI, more or less) would require rooting around and determining what exactly the functions do, and how to make them work like I want them to. Plus it might end up requiring a separate physics loop, or defining cameras as a type of object, which isn't necessarily bad, but is more work.

So eventually doable, if it's really worth it?

I am not trying to shove these ideas out the airlock, but I do need to be satisfied that there's a genuine use for them. I am willing to spend the time, but I want to spend it well, these two SEXPs are probably some of the most difficult that could reasonably asked for for teh camera code.

In addition, I'm pretty sure that there are other camera SEXP ideas floating around out there that deserve due consideration.

[Goober5000]

I think Goober made this sound easy in one of the other threads. I'm not so sure.

Well, here's what I was thinking.  Make a new type of object, "subclassed" from a waypoint path object, that stores a start and finish time in addition to point locations.  This new type of object will represent a Bezier path, based on parametric equations with time as the parameter.  Plugging in a time value will tell you where the camera is at a given point in time.  Then it's just a matter of evaluating the equations every so often and making sure the camera is at the right place at the right time.

[Pilot Of The US]

Hmmm, I had an idea for the moving camera sexp. Basically you'd just use a cloaked ship which would follow the waypoints, and use that ships camera, but have it facing the target object. Not sure how doable this is, but this sexp is of lower priority (mainly due to its harder implementation).

As for the other sexp (rotate-around-object), it'd be very useful if you had an object (think Arcadia) where you've got of action going on (eg. landing craft, weapons firing). You may have several important events occurring in sequence, but in different locations around the station. Being able to rotate around the station would be a good solution. Although just having multiple camera would solve this, it would be very jerky and may not be a viable solution depending on the type of scene you're trying to create.

If you have a ship in the foreground that's orbiting something (planet, station?) you can set the camera to rotate around the object that the ships' orbiting (setting the rotation with the right speed) you can achieve sucessful tracking. It can even be used if you need a standard rotating shot of a ship.

Can something from the players' rotational camera be used here to help implementation?

Anyone got any more ideas - for my sexp suggestion or any new ones?

[WMCoolmon]

You can already do #1 with SEXPs. It defeats the entire purpose of having a camera system if you use a ship (and invoke the significantly greater memory/processing overhead that it entails).

Anyway bezier paths...these look like the things I was trying to find way back when I was first working on the camera system, but understanding the math in the entry on wikipedia is slightly beyond me ATM.

There is multiple camera support in newer builds, but it's only accessible from scripting.

[WMCoolmon]

I'm going to have to say that there's a very good chance I'm not going to get this done. I'm very sorry; at the time that I encouraged feedback in the previous thread, I truly believed that I would be motivated enough to finish the improvements for the camera code. But the more I think about it, the more I realize that it's a Pandora's box that I really don't want to get back to.

[Bobboau]

were is the camera code, moveing from one point to another should be rediculusly easy.

if you ever get interested in Bezier stuff this is much more understandable than what you probly ran into.

[WMCoolmon]

It's all in camera/camera.*, along with (IIRC) the subtitles. All the SEXP-specific stuff is located in parse/sexp.*, of course.