[sldev] Request for help with modifying client camera behavior

Candide LeMay candide.lemay at gmail.com
Sun Aug 31 01:58:32 PDT 2008

I've faced a similar problem months ago, but instead of trying to
implement a full animation toolset inside of SL, I took a different
approach. Which was to use Maya (or any other 3D package you know well
enough) to animate the camera movement. Then I exported the final
frames from Maya to a file and had SL replay them. This gives you
robust tools, ability to save and edit the animation, and most
importantly, doesn't require massive changes to the SL client itself.
I just made it react to few keyboard shortcuts, basically one to read
the file with frames, and two for play/stop.

And you don't have to stop at camera movement either, you can keyframe
any of the windlight settings for visual effects. This short video is
the only remaining artifact from my machinima making career - I didn't
finish it due to a series of unfortunate events (lost data, sim closed
etc) but it demonstrates what you can do (the last few seconds). The
footage is straight from SL, no postprocessing was done beyond the
conversion to qt.



On Wed, Aug 27, 2008 at 1:13 AM, Vector Hastings <vector at leafpile.com> wrote:
> Hello all, I'm new to this list, never learned C++, but was once a pretty
> competent programmer on the IBM midrange platform.
> Please forgive a long first posting, but I've been trying other avenues (as
> this will make clear) and find myself needing to escalate to client hacking.
> A full treatment of what I'm seeking involves a certain amount of detail,
> which now follows:
> I'm trying to launch an ambitious filmmaking project inside Second Life
> (machinima). One of the critical keys to getting a more cinematic look to
> machinima in Second Life is better camera control.
> The ultimate goal is an in-world camera that can follow a fully
> reproducible, smooth, and non-colliding path.
> There's been a lot of work on that already: the 3dNavigator flycam gives us
> beautiful smooth paths, non-colliding behavior, focal-length control, but
> there is zero reproducibility. There are a number of waypoint systems that
> use a vehicle to move the avatar around, allowing for a somewhat
> reproducible path, but at the cost of collisions which are unacceptable in
> interior spaces, and the effect is often choppy and fine control of camera
> angles is not achieved with current systems (even though I suspect that last
> item is theoretically possible).
> I've experimented with making a system of waypoints trying to use the
> llSetCameraParams option to move just the av's camera. I believe this is the
> best middle-ground approach, and will achieve a major step forward in
> machinima cameras, but...
> The inherent desire of the camera to return to the filming avatar's default
> camera position means my filming results are so choppy that they're only
> useful for simulating an earthquake. :-\
> I know that viewer code is in flux right now, so anything done now is at
> risk of having to be re-developed later. But I am also on deadlines, so I'm
> reaching out for guidance in how to do this. Ending up with an older client
> is workable for me. Hopefully the feature could be ultimately re-engineered
> for the more stable 1.21. (I'm also happy to use an RC 1.21 viewer, if it
> becomes usable on the main grid in the next two to three weeks. I was a
> long-time user of the last two RC candidates, doing a lot of our
> pre-production filming with them.)
> What I think I need is a hack of the client to solve the problem with my
> rig, and there's probably multiple approaches:
>        1. Create a debug setting that tells the camera to apply its native,
>        manual-mode Cam Transition time and Cam Smoothing to changes in scripted
> camera location.
>        This sounds relatively simple, since the initial entry and exit into
> scripted camera control obeys those parameters,
>        but the movement from one location to another does not, which implies to me
> that the camera routines know whether
>        they are under scripted control or not and have been set to behave in this
> instantaneous relocation mode when switching
>        from one camera position and/or focus to the next.
>        2. Create a debug setting that turns off av camera target drift altogether.
> There are lag parameters in
>        llSetCameraParams, but they only seem to be effective when position_locked
> = FALSE -- those lag parameters would
>        give excellent speed control in the camera -- but right now,
> position_locked = FALSE means the camera pulls toward
>        the owning avatar like it's attached with a giant rubber band, and the
> effect is a seesawing nightmare.
>        3. Create a flycam recorder. This might be a very general and powerful
> solution, but authoring a camera path with it
>        would probably be unwieldy. One would want the ability to store a camera
> path log file to disk in a human readable format
>        so that it could be tweaked into shape. That tweaking could perhaps be done
> with some sort of statistical analysis program,
>        but I think it would take one dramatically outside the world of SL to do
> it.
>        4. Create a waypoint recorder in the client, that simply lets you hit a
> button to add a camera position/angle to
>        the list of spots to hit, then reposition, add another point. It would be
> nice to have a speed control, and vital to be
>        able to save it, and helpful to be able to edit it. This is the basics of
> the scripted waypoint systems in-world,
>        including the one I'm working on.
> I downloaded the code last night, and went to the library to check out
> "teach yourself c++" today.
> Somebody have mercy on me, please!
> While I will initially use the camera system I develop on my project, as
> soon as we begin releasing episodes, I will also release the camera as a way
> of building good-will and buzz in the project.
> If you want to see a little about the project I'm cooking, you can visit
> www.vectorpicturestudios.com.
> All the best to you all,
> Vector Hastings
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges

More information about the SLDev mailing list