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 <t...@playsign.net> > 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
