Thank again for the extensive infos Toni In fact, that sounds great about the concurrent user amount, specialy for scenes without avatars, as I think there are many cases where avatars are not really needed.
As for the use with avatars, its a good start with about 30-50 in one place as a for a lot of uses a seperation into different rooms is no problem, maybe even better for load balancing. Thats why I had the idea that maybe Shibboleth and Grouper could be used for federated single sign on to xmpp, web content and tundra and using grouper for group management. Though I still have to read through those docus to see if I didnt misunderstood the concept. So far there are a few things out using this approach (without tundra of course) in some universities. What I liked most in this approach is the way federations between different authentication providers work. But as mentioned - I will have to play around with it first to get a bit familiar with it. About the Tundra version: I was using 1.03 where I experienced the previously mentioned issues. Strangely when I hit the update button it asks about installing to Version 1.0.3 again, which I did once but its still the same. Everytime when I start the viewer, I'm asked if I want to update. Just after I did choose the repair option in the installer it replaced viewer.exe and after that the update message after viewer start didnt show again - but when I try manual update, it still shows that it found an update. (why did I click it ? Just because it was there) I will try a de-/reinstall maybe it gets better. The good news - the tree textures are there now - but not the bark textures and also the fish and osprey demo still behave the same - maybe there is something somewhere cached and a full deinstallation will solve it. Cheers Pedro On Sat, Mar 5, 2011 at 3:53 PM, Toni Alatalo <[email protected]> wrote: > On Sat, 2011-03-05 at 15:19 +0100, Peter Steinlechner wrote: > > thanks for the update, as I was just about to post about the missing > > textures. I have a simlar issue with a group of trees in the chesapeak > > bay demo where the textures dont show. > > Yes there is a known issue, certain ones don't (always) show over http > in viewer. Strangely enough they show on the server when you run that > with the renderer, and on Linux showed for me last night in viewer too > (at last built linux naali with nvidia cg so the shaders work). There is > very little difference in how scene loading happens in server/viewer > mode (when rendering enabled, not headless) so is weird, we'll debug > that next week. > > > The osprey demo i couldn't get to work at all. I wonder if thats maybe > > in connection with the preview version I had installed or did I > > Please use at least 1.0.2 and why not 1.0.3 -- earlier versions had > issues with http assets dependencies from scripts vs. headless server > etc, I'm surprised the December preview works that much. > > > Maybe a too early question: how many concurrent users you estimated > > could connect to a tundra server ? > > Depending on the application, the current bottleneck is easily the > bandwidth of the realtime communication. Again how much bandwidth is > taken depends on the application -- if all just look at a static scene > and fly around with cameras, that doesn't take any bandwidth (cameras > are local only) you can basically have an infinite amount (is basically > like many users having loaded the same web page, which they can scroll, > but nothing is synched among participants). > > If you want avatars for all, the current av app takes quite a lot 'cause > there are no separate movement messages but it all goes with the generic > EC sync. I don't remember the exact figures, Jukka wrote it in some > post, but IIRC he said the bandwidth is already less than with LLUDP .. > and that now you could have 30-40 and with optimizations 60-80 or so. > Doing those optimizations by writing dedicated movement packages is > planned. > > To go above that we've been talking about the usual MMO solutions of > separating the scene to different 'rooms' etc. and other normal > techniques to not communicate everything to everyone all the time. Enne > at least needs this I think, but how and who would develop it is not > known yet (we keep planning it in coming weeks). > > We will certainly also check out the Opensim scalability work being done > at Intel and continue talks with those guys .. they use server side > proxies (client managers) to kind of facade the sim connection by using > several servers, that are all connected to a master server, and Dan Lake > told on IRC early this week that they've had 1,500 avatars in one scene > now with this technique. For those who want this technique, host a > server farm with numerous sim servers all serving the same scene to a > different group of clients (but all clients still see each other, this > is not sharding), it is yet an open question whether is better to use > opensim and Intel's work as is, or whether the same proxy stuff could be > easily adopted to Tundra too (Dan at least was gonna check Tundra demos > out :). The protocol they use to talk between the client managers and > the master server is a custom thing anyway, not LLUDP (just some ad hoc > messaging with tcp). I don't know yet if/when someone actually needs > this with reX. > > > Pedro > > ~Toni > > > On Sat, Mar 5, 2011 at 2:58 PM, Toni Alatalo <[email protected]> > > wrote: > > On Sat, 2011-03-05 at 15:48 +0200, Toni Alatalo wrote: > > > On Sat, 2011-03-05 at 15:25 +0200, Toni Alatalo wrote: > > > > server.exe --file > > > > > > > http://www.realxtend.org/world/BeneathTheWaves/BeneathTheWaves.txml > > > > > are some strange white objects (the texture png they ref to > > seemed white > > > in my browser at least) > > > > > > Ah sorry for another message, forgot to mention the most > > visible known > > issue: some of the textures are assigned with the direct > > use-this-image-as-texture technique which is supported in old > > rexviewer > > and in Naali against Taiga, but not with Tundra. This is by > > design as we > > figured that it's ok to require using material definitions > > like normally > > with Ogre. So many textures there don't show 'cause the > > material ref in > > the mesh is directly to an image. > > > > There's two ways to solve this: > > a) create new plain use-a-texture materials in the converter > > b) add some feature to Tundra to support using images as > > textures > > directly. possibly a script that you can attach, or somehow to > > the > > internals. > > > > Feedback on which approach would seem more useful is welcome, > > if is > > worthwhile I can do either at some point. > > > > > ~Toni > > > > same, but off now. > > > > > > > > -- > > 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 > -- http://groups.google.com/group/realxtend http://www.realxtend.org
