[sldev] Machinima and recording movies/demos in SL

[Kiwi Alfa]

On 1/17/08, Lawson English <lenglish5 at cox.net> wrote:
> What you're looking for is more complicated: the playback of scene
> information, but in principle everything you see could be reconstructed
> from what the client got over a period of time.

Right. For example, the playback server wouldn't need to have any
concept of physics as the information needed will already have been
calculated and will be evident in the information recorded.

There is one thing I don't know, however. Does the server actually
send events of its own accord or does it wait until the client asks
for them? I'd suspect the latter, in which case it may need to be a
bit more complex, depending on the time of the queries and how complex
the server needs to be. It may be that some interpolation is needed in
the saved values to keep the demo going at the same rate, which could
be a bit of a pain. On the other hand, if the server just relays all
the events as they happen without being asked, it would be easy to do
just that with the saved events.

> One flat in your plan (and its relatively minor, I think): the server
> DOES have some idea of where your camera is and does do some culling of
> the objects sent to the client. This means the range of positions where
> your camera position will show a valid picture is reduced, but I think
> you'll still have SOME mobility of the camera, even if its not sim-wide.
> I might be wrong, of course.

I guess the way to tell for sure would be to use GLInterceptor or
similar while testing to see what could be seen. I know SL uses OpenGL
on Linux (as I've used OpenGL-intercepting libraries before on the
Linux version) - I assume it's the same on Windows.

> The trick will be to mod the viewer to accept the canned data as current
> and not get upset when certain messages to the server are not responded
> to. Not a clue how to do those mods. I'd talk to the libsl people and
> see if they have any ideas.Maybe there's already a way for SLProxy to
> record that data and play it back from a file. That would be the srart.

In my ideas, the recorder was originally conceived as a proxy,
actually, but after thinking about it I realised that it would be a
lot easier if it was implemented directly in the client; after all, it
knows exactly what its own internal structure is. In addition, doing
it in the client would make it less of a memory hog, as that state
wouldn't need to be duplicated in two apps. Heck, I believe that
there's already an option in the debug menus to dump the current state
of the world as the client sees it, so if nothing else it shouldn't be
too hard to piggyback on that and then record deltas. (It's not the
way I would do it and it would probably be likely to slow the client
down a great deal, but it shows how easy the main part of this could
potentially be.)

As for the server not responding to messages, see the point above this
one. I would want this to be compliant with the protocol, so anything
that needs a response should get a response. Some interpolation may be
needed for full accuracy.

 - Kiwi.