[sldev] Request for help with modifying client camera behavior

Vector Hastings vector at leafpile.com
Tue Aug 26 16:13:27 PDT 2008


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



More information about the SLDev mailing list