Enbeddable Tweak again

In my continuing, but lately not so active, quest (see:
https://lists.duke.edu/sympa/arc/croquet-dev/2008-01/msg00056.html  and
https://lists.duke.edu/sympa/arc/croquet-dev/2008-02/msg00000.html  )
I had an odd thought (not the first time for that!):

The Tweak world containing the menu that is overlaid on the Croquet
window in several of the Croquet demos and Cobalt is already locally
rendered as a texture by OpenGL.  Shouldn't it be relatively easy to
add that texture to the formManager for replication and then map that
texture into a TWindow's contents in-island to create a view-only
"show" of one's own Tweak world?  This could be an easier, lower
overhead, and maybe more solid way to share activities, could it not?

Of course the more difficult extension to this would be to allow
others to interact with the image in-island and conditionally "event"
them back to one's own original Tweak world, but that could be an
entirely different thing.

I think that this whole approach differs from Qwaq's current one in
that they use a separate otherwise non-rendered Tweak world to provide
the in-island image rather than one that is already rendered on
someone's screen.  True?

Does this idea have merit as a useful but different way to go about things?

Dave

Hi David -

David Faught wrote:
> The Tweak world containing the menu that is overlaid on the Croquet
> window in several of the Croquet demos and Cobalt is already locally
> rendered as a texture by OpenGL.  Shouldn't it be relatively easy to
> add that texture to the formManager for replication and then map that
> texture into a TWindow's contents in-island to create a view-only
> "show" of one's own Tweak world?  This could be an easier, lower
> overhead, and maybe more solid way to share activities, could it not?

This largely depends on how you are going to deal with the updates of
those textures. It is correct that this would be a fine way to share
your screen with someone else but you still need to update the textures
for the other participants as you interact with the UI. This can be
quite expensive if you simply send the bitmaps around (the VNC approach).

> Of course the more difficult extension to this would be to allow
> others to interact with the image in-island and conditionally "event"
> them back to one's own original Tweak world, but that could be an
> entirely different thing.

Yes, indeed. If your goal is to share your own screen with someone else,
then this proposal is a very good way of achieving this (for example for
training purposes etc). However, if it is to create a self-sustained 2d
app inside the space it may not be appropriate. That's because when your
client goes away so would the application.

> I think that this whole approach differs from Qwaq's current one in
> that they use a separate otherwise non-rendered Tweak world to provide
> the in-island image rather than one that is already rendered on
> someone's screen.  True?

Correct. With the advantage being that the initiator of the 2D world can
go away and the world will continue to exist and be active. That's the
basic tradeoff: You are either running replicated worlds or you are
running client-server. Both approaches have different tradeoffs and
depending on what you are trying to do either one may be appropriate.

> Does this idea have merit as a useful but different way to go about things?

Absolutely.

Cheers,
   - Andreas

On 3/13/08, Andreas Raab <[hidden email]> wrote:
Currently, this texture is generated every render cycle, so ideally
something like H.264/MPEG-4 AVC would be nice, but I'm thinking that a
quick-and-dirty approach would be to send the bitmap at some manually
adjustable interval, like every 5 seconds, every 2 seconds, etc.  As
you said, it seems like this idea could be a simple and useful thing
for training or presentations.

In Qwaq's current approach, the actual Tweak world is still instanced
outside of the replicated island, is it not?  Maybe on a "persistent
participant?"  And just an image is replicated?  Just curious.

Dave