[sldev] Machinima and recording movies/demos in SL

[Kiwi Alfa]

Hi,

I've been meaning for a while to start my own discussion here about a
specific way of recording movies in SL, and as there's now a
discussion going on about it, it seems like the perfect time to bring
this up. It's a separate discussion, though, so I'm starting a new
thread.

Firstly, let me introduce myself since I haven't really posted much
here. I'm Kiwi Alfa in-world, and I do machinima in SL. Recently I've
been thinking of making code changes to allow the client to record
something similar to demos in other games, but with a bit more
freedom.

I'm going to copy and paste from something I've been writing on the
subject (which isn't yet complete, hence no link):

=====
The Problem

Machinima in Second Life is currently limited in ways that machinima
on game platforms isn't; namely, the ability to record 'demos', which,
rather than recording the view from the camera, will record the actual
events that happened during the recording. As such, when recording in
SL, if two different camera views of the same scene are required,
either two 'camera' avatars are needed, both recording their output to
a file (which would also necessitate communication between the two
avatars to make sure they both start at appropriate times, use
appropriate settings, etc) or the same scene will need to be
re-enacted and recorded twice by one person. In addition, if, during a
recording, the camera isn't pointing at the right place or any other
camera error, the scene needs to be re-enacted and recorded again.
This leads to a largely inefficient means of producing machinima in a
world that is arguably more suited to it than most game engines, which
are inevitably biased towards their style of gameplay.

The Proposal

As Second Life uses a client/server architecture, I propose to create
a recording facility that would capture events sent by the server and
store them in a potentially redistributable archive, which could also
optionally contain textures. The recorder would be built into a custom
viewer and would record the initial state of the world as seen by the
client when the recording starts, and from then on would record
messages received from the server with timestamps.

To play back the recorded demo, a separate server would be used,
probably based on OpenSim. However, this would not be as advanced as
OpenSim; none of the traditional sim interaction methods would need to
work (the client would not be able to move themselves, for example).
Basically, the server would be simply used for relaying the messages
from the saved archive to the client.

(The client may have a built-in facility for camera movements,
although this would probably come later.)

Using this technique, the client would be able to play back exactly
the same scene as was recorded, but would be able to use different
camera views each time, meaning that the original problems described
are eliminated.
=====

Obviously, the above is just an overview; I have ideas for how best to
implement them which are not discussed above. For example, should the
saved archive include the textures themselves, or just UUIDs? My gut
feeling is that it should include the textures too, which would mean
that after a successful cache hit or texture download by the client,
it would need to temporarily store it and flag it along with a
timestamp; after the recording finishes, the textures collected in
this way can be analysed to work out what needs to be stored in the
archive. (This is assuming that the texture referred to by a specific
UUID can change or be removed after being stored; if not then it
should be easy enough just to store each texture that was hit one or
more times into the archive.)

I just wanted to ask others on this list what they think of the
feasibility of this idea. I'm a coder, though Perl is my main language
so I would need to learn C++ and C# a bit more to work properly with
the client code and OpenSim code. I've already started on this,
though.

Thanks for reading!

 - Kiwi.