|
|
Hey all, millimetering ever-closer to a squeak plugin to SL. The pattern
is quite simple:
start second life.
add a texture to a prim in SL that points to a localhost server with
appropriate mime type.
have a plugin available for SL that can share a memory buffer with a
cobalt instance.
Tell Cobalt to render into that instance with appropriate channels for
mouse/keyboard I/O.
Tada: Croquet/Cobalt on a prim.
The Teatime architecture appears to be the ultimate P2P plugin tester,
but its only being used for the rather huge Croquet/Cobalt use-case.
Now, this is going to be fun, and possibly useful, but for most users of
SL, Croquet isn't going to be all that attractive, at least at first. In
order to get a foot in the door, I want to establish a TObject which
renders to SL, accepts I/O from SL and broadcasts it to other TObjects
connected to OTHER SL clients.
This turns squeak into a media plugin prototyper for SL AND opens the
door for more interesting plugins, such as ones that generate 3D data
(not necessarily in Croquet format) for injection into SL.
The same pattern could be added to any kind of chatroom. The ultimate
form would be having a Croquet/Cobalt window embedded in an IRC or
Google Wave window, but more limited object sharing should be quite
useful (often more useful given the overhead of a complete Croquet world).
So, my question is: how do I strip TObjects/Teatime away from the rather
huge Croquet context, so that I could do a hello world example of a
simple TObject rendering to a SL media plugin and sending updates to
other TObjects connected to other SL clients via the media plugin?
The sky is the limit for this functionality, IMHO. Croquet is only the
sexiest example, but in fact, I don't think its the most practical. The
hello world TObject is much easier to grasp the implications of, because
"rendering" can be replaced with ANY object-state transfer to the target
application (which could be anything, not just the Second Life client).
Lawson
|
Locked
