The old 'virtual webcam' / screenshot server / server side rendering is
back, now with Tundra2!

Live demo, running the physics2 demo scene from the Tundra repository:
http://www.kadonnutkaupunki.net:8886/client

Clicking on the main image rotates view, so that the point you
click/touch is put to center of the view. Arrowkeys can be used to move.

Clicking on the map works to set the position, the coordinates are
perhaps a bit weird now (the default view direction in that scene is to
south considering the map, so clicking the pos north from the center
shows you the middle part).

Your camera position is stored on the client side (the browser), so any
number of people can move around in the scene without interfering each
other (as if they all had their own cameras).

This is the same old client that we developed already 2-3 years ago,
first browser based view to realXtend worlds, before WebGL or anything
existed. Is the simplest and lightest thing for the client side, as the
client shows just images -- was nice also for phones and tablets back
then. There is no new functionality yet, just a port of the old thing to
current tundra2.

The html+canvas2d client side project is
https://github.com/realXtend/worldwebview

Server side counterpart is
https://github.com/antont/tundra/blob/httpserver/bin/pyplugins/httpserver/tundrahttphandler.py

We've been talking with Adminotech now about integrating this to their
hosting system to get live views to the Tundra scenes there. I imagine
it will be nice to see what's going on in a scene already before logging
in. And it's fun that it is normal Tundra, so whatever is in the service
shows normally (for example avatars).

There are many ideas for improvements, primary one now is to change to
panorama rendering and add support for local camera rotations on the
client side. This way rotating the view becomes nice and smooth, not
needing the slow server roundtrip. This should be quite simple to do.
For movement fading transitions and progressive loading, similar to
Google's streetview, would be nice.

Other direction is using video streams for the display, perhaps similar
to what existing commercial server side rendering + streaming gaming
services do. I wonder if VLC could do that as we have it integrated
already (VLC is originally made for sending videos over LANs).

This area is not a replacement for other clients, e.g. WebGL ones (which
is also being worked on using three.js now, similar to the old
WebNaali), but a parallel track and a differently useful service.

If someone wants to use this now in their setup, you need to pull that
httpserver branch (1 line addition to py api in c++, 2 py files for the
http server lib & service implementation, no deps outside py stdlib) and
the web client. The web client html is served via Tundra's http server
to avoid cross-site scripting limitations in browsers. A separate web
server is used to deliver the actual images (I just use Apache, the
Tundra plugin copies the images to Apache's dir). I can help with
details (write a readme) if someone wants to try.

~Toni

P.S. that 'server' is still the same old EeePC as the previous time,
some dual core Atom processor in a netbook, but with a mobile nvidia
chip that runs light Tundra scenes ok :) Also the upstream from the
server is just some ~5MB DSL, that is the bottleneck for the image
transfers. For the Admino hosting integrated thing it will be some
powerful box in a well connected (hopefully 100MB or so) place, this is
just a simple proof of concept demo setup.

P.P.S. Back 1-2 years ago I also added server side rendering support
with http controls to Opensimulator, and Nebadon and Melanie tested
using this same web client to their Opensim servers. It worked ok and
was sure fun enough, but the Warp3D SW rendering module there had severe
memory leaks (was originally made for one-time map rendering, not many
subsequent calls like with this) -- I didn't go into fixing those. If
someone is interested, is still well possible to use this there too (and
the mem leak in the rendering seemed ease to fix with some restructuring
of the code).

-- 
http://groups.google.com/group/realxtend
http://www.realxtend.org

Reply via email to