Thanks for the reply.
Ok, I now fully understood the technical part of this httpserver. The fact
still is though that im not able to access even the 127.0.0.1:8886 without
worldwebview, or with it. I placed all my files as you said was preferred
and launched my apache web server. The server seems to work flawlessly but
still no connection when using port 8886. Im now starting to wonder if the
tundrahttphandler or asynchttp have something wrong. I haven't changed
asynchttp.py at all, but in tundrahttphandler i tried to determine the
worldwebview by hand with a static path(with no luck). My config.py has the
127.0.0.1/tundra as umgurlbase and imgdir is a random directory in my
filesystem. I also tried to have the imgdir inside xampp htdocs to have
them hosted but no luck this way either. As i launch my Tundra.exe with
--server --headless as a localhost default port being 2345 i think, it runs
the code cos i get the print inside init() in tundrahttphandler. I will
continue with this tomorrow as i have more time, but since now the problem
seems to be that Tundra won't take and move the files anywhere when queried
through inet. Also my tundra console tells me that httpserver.py is loaded
succesfully in startup.
Lasse
On Monday, 15 October 2012 13:27:54 UTC+3, Toni Alatalo wrote:
>
> On Oct 14, 2012, at 11:59 AM, Lasse Annola wrote:
>
> Ive got my worldwebview cloned with tundra and the screenshot_server
> variable is my local ip: 127.0.0.1:8886/renderimg. I don't know should i
> change that renderimg to something else but i
>
>
> That 'renderimg' should stay, it is the URL / http get command that the
> Tundra server has for rendering images (it gets the camera position &
> orientation as parameters, and returns the URL of the resulting image). You
> can see the tundrahttphandler.py to see how it's implemented if want.
>
> figured its part of the servers functionality so didn't touch anything
> regarding that. I then copied that file into my apache htdocs folder to
> have it on my server. Then i changed from tundrahttphandler.py the
> clienthtml = open("xampp/htdocs/worldwebview.html"), for it to find it. Now
> as i run http://127.0.0.1/worldwebview.html via chrome, it opens the file
> but ERROR + some placement variables come to the "console" on the left. I
> tried opening my firewall but it did not have any effect (trying this
> locally so it shouldnt anyway). I'm really running out of options here, ill
> continue by setting everything to default.
>
>
> Ah there seems to be a little confusion here: you don't need to copy any
> html to the Apache folder. The system works so that it is *Tundra* itself
> that replies to the first http requests, not Apache. This is why you access
> http://127.0.0.1:8886/client and not the default port -- that Tundra http
> handler listens to port 8886 by default. What you say above works if you
> have the 'xampp' folder inside your Tundra bin directory (which I suppose
> you don't). That is, the open() command is executed inside Tundra and it
> searches relative to the dir where you run Tundra.exe
>
> So you should do it like in the readme: "So to make the default config
> work, just have your Tundra git clone and WorldWebView git clone side by
> side in the same directory. (so from tundra/bin/, ../../worldwebview/ is
> found)". If you wan't to put worldwebview.html to some other place, you
> can just change that open() command use that absolute filepath. I see now
> that using the url '/client' can be confusing to access a file named
> worldwebview.html (that's what the code does: when Tundra is asked for
> 'client', it reads that html from the filesystem and returns it in the http
> reply). You can also test with http://127.0.0.1:8886/ -- that one does
> not need worldwebview.html (the smart client where you can move etc), but
> simply returns the current view from Tundra (creates a html which has img
> with src set to the apache-served image that it created).
>
> Apache (or any other web server for static files) is only used to transfer
> the images, after the call to Tundra has generated them (that 'renderimg'
> http handler does that). It would be also possible to have Tundra itself
> return the actual image data too, and the tundra1 version of this thing had
> that option too, but in practice it seemed that using a normal separate web
> server is better for that in actual production setups so I skipped that
> option now.
>
> Lasse
>
>
> ~Toni
>
>
> On Thursday, 4 October 2012 11:22:31 UTC+3, Toni Alatalo wrote:
>>
>> On Wed, 2012-10-03 at 08:13 -0700, Lasse Annola wrote:
>> > I would be interested in trying this, in case you have time to make an
>> > readme.
>>
>> Sure! There's first take:
>> https://github.com/realXtend/worldwebview/#readme
>>
>> I think all the required steps for installation and configuration are
>> covered there -- do ask if/when there's probs, and feel free to improve
>> the docs too if want.
>>
>> You have been using the websocket support also, so hopefully already
>> have a Tundra2 build with Python support, so all should be easy. Admino
>> is interested in getting this to use in their hosting system, and they
>> use windows servers, so we may need to update the windows deps for py
>> too (also websocket support may be required by Admino hosting soon and
>> that may also still require py support as well).
>>
>> > Lasse
>>
>> ~Toni
>>
>> > 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
>>
>>
>>
> --
> http://groups.google.com/group/realxtend
> http://www.realxtend.org
>
>
>
--
http://groups.google.com/group/realxtend
http://www.realxtend.org
