Hey, I would be interested in trying this, in case you have time to make an readme.
BR Lasse On Tuesday, 25 September 2012 09:29:03 UTC+3, Toni Alatalo wrote: > > 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
