On Sun, 2011-07-03 at 15:32 -0700, sellman wrote: > I think hopping between independent server processes by link works > just fine. I'm thinking a developer could even program an object as a > link so that as you travel through the object on one server and then > appear in a matching object in the other server to appear like travel > over a continuous connection.
Yes, that should work. Never considered it like that actually, I've been just thinking of more boring click-image-plate-to-teleport-there, and in TOY there are teleport platforms that work so that you choose the destination by walking to the platform of your choice .. and then get a distruptive logout/relogin / teleport. Having a matching object as the gateway on both sides feels much nicer. > A hyperlink based approach allows for complete flexibility rather than > being locked into a two dimensional grid. With the hyperlink system I > could have "Castles in the Sky" or Underworlds controlled by a > completely different organization. Any topology is possible, even Yep. Also with slviewer LLUDP / Opensim, Christa 'Diva' Lopez has achieved this with Hypergrid (a nice article about it is coming to the same IEEE IC issue where the reX EC paper will be, btw) -- Hypergrid is basically just saying a target teleport destination somewhere in a world, and the target can be any location on any server anywhere. Then there's just a lot of 'extra' hassle to get the assets and inventories etc. working as the Linden model wasn't really made for that. It is interesting though as it strives for being able to have walled gardens, with protected or at least limited asset servers. But if you ignore the walled garden assets biz, and can work with the web model, you can just have tundra://someserver links anywhere in the worlds and call it either a web of worlds or a hypergrid :) . In reX, if you use avatars, the avatar assets are typically http urls .. so others can see you on any server. > Ok, on view-abilty. We don't need to prevent view-ability per se. > We just have to keep people out of places they should not go. Ok. So with separate scenes, which now means separate servers, and authentication, you are indeed good to go. > Tell me if this approach seems viable to you. In the scene there is a > building object with an entryway blocked by a door object. The door > object is owned by the admin or another user. An avatar/user > approaches the door object and attempts to open it. The door object > gets the login ID from the avatar and queries LDAP. The avatar/user > enters their password. If they are authentic the door object moves > out of the way and allows the avatar/user to enter the building object > and of course see content inside. If the avatar/user doesn't auth-out > the door object stays put they are prevented from entering. So do you mean here that the building object would be a separate scene on another server? In that case that works. Hm I think actually here you mean 'keep out of places they shouldn't go' within a single scene, e.g. some sort of large work scene with different student groups working in different parts (that's how TOY is used too, there's actually a library of different templates to divide work spaces etc. and a nice sliding door object :) That doesn't really work, in the sense that it's easily hackable. One can for example always create a new *local only* camera in the client, and also the default free camera is local only, so out of the box there is no way to limit where the camera goes from the server end. Same problem as Peter Quirk reported from corporate use of Second Life. The safe way here would be to not send those entities to the client at all, either using a subscene/room system or per-entity visibility controls. Otherwise it's quite easy to implement and might work enough, as you say it doesn't need to be really secure. The default avatar is moved on the server, you can limit the areas there simply. And physics work, so a physical door would do that for a room in a building automatically. And you could modify the free camera either to do the same checks locally or via server, or even disable it altogether. Would give the desired functionality for the normal end user situation, even if would be trivially hackable (e.g. add a local unrestricted free cam with a js script that put in the client). > Assuming there is security in place for changeability and execute- > ability, and an avatar has some way to be connected with a userid then > I think this would work. It may not be completely un-hackable but we Yep well changeability is there now, executeability is coming (permission hook for entity actions), and you can e.g. put the LDAP userid to the properties of the user connection upon authentication at login. > be writing modules for the overall simulation, just programming object > scripts and adding interactive content. Very simple programs but how > much more captivating to manipulate 3D objects instead of console IO. Yep. Have you seen the Chesapeake bay demo btw? One idea I've been entertaining for it has been exactly teaching programming .. even for small kids (5 year olds :) with something like Scratch, simple behavioral rules, e.g. whether a duck approaches or goes away from people when they come close. Moving nicely modelled, textured & animated (kudos to the French team :) animals is more inspiring as an introduction to programming than just 'hello world' or 1+1, for some at least. There are still many animals there with no AI at all *hint-hint-wink-wink* > and dropping blender. I'd like to use blender again this year and > Python as well, hence the interest in Tundra. Right. The blender2rex guys are working towards integrating logic authoring, so you could even specify behaviours in a custom reX/Tundra Blender UI and see those running on the server then. Some of that is already there, but I haven't gotten to really try it yet. Do have it installed now, after visited the guys and got some info. Is also nice that the same physics engine, Bullet, is on the both sides .. for example the Pong demo/test I made so that first made the whole scene in Blender, made a little game logic there with the Blender game engine GUI to get to test how the physics behaved, and when the collisions seemed fine exported it to reX. > elegant general solution. Can I share it with a couple of folks in our > group? Sure please do, it's public, just not totally publicized yet as is still being edited. > George ~Toni > On Jul 1, 5:50 pm, Toni Alatalo <t...@playsign.net> wrote: > > On Fri, 2011-07-01 at 12:56 -0600, George Sellman wrote: > > > I'm glad my timing is good. A quote from the A-team "I love it when a > > > plan comes together" > > > > :) Just a (quick) reply to a few points now, is getting late here: > > > > > You can see that for classroom type activities we need > > > security/ownership etc. Specifically, it would be great to control > > > > I've come to learn that, yes. For long it was a mystery to me what > > MOODLE is, and what the SLOODLE SL integration for it is, and based on > > some video it seemed that it was basically a way to have groups and > > permissions etc. to manage object ownerships and rights etc. (if someone > > doesn't know, MOODLE is an open source system especially for education > > orgs). So indeed permissions seem to be essential in schools. > > > > > viewability, changeability and interact-ability on an individual > > > user/owner basis or even with groups. Kind of like readable, writable, > > > executable in the Unix/Linux file system. So, we would like to be > > > able to keep avatars from entering/viewing areas that they don't have > > > permission to see. As well as, of course, modifying or interacting > > > with things they don't have permission to play with. > > > > Controlling viewability is not in the current plan, and AFAIK hasn't > > really been in the use cases so far. It is possible, albeit on the > > tricky side. I'm not sure if it's actually a good design, but possibly > > so, and certainly an intriguing idea. > > > > We talked about it a bit with Jonne on IRC now (#realxtend-dev on > > freenode) > > > > 01:53 < Pforce> i was thinking how to do that object hiding for certain > > people > > 01:53 < Pforce> possibly not send the entities at all to those clients > > 01:53 < Pforce> but that would require scenemanager changes afaik > > 01:53 < Pforce> have similar AboutToSend(Endity*) > > 01:53 < antont> i'm gonna reply that the object hiding is simplest to do by > > using different server instances > > 01:53 < Pforce> wouldnt it? > > 01:53 < antont> but yes that'd work too, was thinking about it > > 01:53 < Pforce> i dont think it hurts to add those either > > 01:53 < antont> i'm not sure if we wanna that though > > 01:54 < antont> yah certainly someting to consider > > 01:54 < Pforce> full control for server sec policy :P > > 01:54 < Pforce> i mean if its just signals again > > 01:54 < antont> yah if there is a valid use case and someone sends a patch, > > hard to see why we'd reject it > > 01:55 < antont> but i'm not sure if that dir is a good solution in general, > > having different entities in the same place for diff clients > > .. well can be nice, e.g. in TOY teacher mode you'd have extra things around > > 01:56 < antont> and would make it kind of nice that you only need one > > server, one scene, and can still have groups that don't see each others > > things > > 01:56 < antont> but e.g. a teacher can see them all at once > > > > > It looks like the modifying/interacting on an entity by entity basis > > > is where you're going right now which is a great improvement over > > > regions. Complete view-ability control would be nice for our use case > > > though. > > > > The SL permission system also has modifying on an entity by entity > > basis. Objects have owners, at least, and are there group rights too? > > > > There is actually an on-going discussion on the opensim mailing list > > about controlling viewability -- someone wanted to make it so that > > certain textures show only to certain users. It's not currently > > supported for normal objects in Opensim, Justin estimated implementing > > it would take a lot of hacking around, perhaps not really feasibly > > there. But someone else told that some parcel media settings can already > > be used to control that for some media streams or something. > > > > > Tundra. Not exactly permissions related. I'm just trying to get > > > familiar with the Tundra model and implementation. It looks like > > > > Have you seen the EC article btw, "An Entity-Component Model for > > Extensible Virtual > > Worlds"https://github.com/realXtend/doc/blob/master/arch_article/simple.pdf?... > > > > It's in final editing now (the IEEE magazine editor emailed a restylized > > version that I must review by next Thursday, I think goes to press then > > so finally gets finished for now). > > > > > there are significant performance improvements over opensim and I'm > > > liking the idea of linking to other peoples worlds. We are also > > > planning to run this in the cloud with different folks controlling > > > their own areas. Is it possible for a single Tundra server to run > > > across multiple machines now or in future? At the risk of being > > > Opensim-ish I'm thinking grid mode, but I'm guessing you have another > > > way of approaching this. > > > > We don't have an all encompassing solution to that fixed, and I suspect > > there very well may be all sorts of different configurations. Also with > > Opensim you have various configurations, like normal grids and > > hypergrid, and I guess others would be possible to add. Ah and Intel > > folks finally put the distributed scenegraph thing in now, for load > > sharing / scalability. > > > > So to answer your question, if you replace 'single Tundra server' with a > > 'single Tundra world', and use a bit of imagination to fill the gaps, > > then it's a yes :) > > > > That is: simplest way now to host different areas controlled by > > different people is to run a separate server process for each area. An > > independent scene. Similar to how in SL and Opensim there's a sim > > process for a region. > > > > Then you can teleport between the areas, which is simply logout & login, > > but can do the auth so that there's no re-authentication but single > > sign-on. This is similar to the web, just using the tundra protocol > > instead of http .. sessions instead of document retrieval. So you can > > get something similar to SL / Opensim grid mode, which basically is > > about using the same user/auth server and inventory on several sim/scene > > servers. > > > > We don't currently have 'multiregion' support, handling multiple > > simultaneous server connections in the client, which is what slviewer > > does to give an illusion of a single seamless world on those separate > > servers. It is possible to add, but not always necessary and certainly > > not the simplest thing. Folks at Chiru have been working on multiscene > > support for other reasons, that work may result in some groundwork for > > this too. Actually an early buggy version of that branch there put > > things from several Tundra connections / scenes to a single Ogre scene, > > which sure looked fun enough :) > > > > We've had some talks about supporting multiple scenes in one server, for > > scalability reasons. The current bottleneck for large dynamic worlds > > and/or a lot of users is network bandwidth, so partitioning scenes to > > areas and/or doing so-called interest management to optimize what > > information to send to which client etc. are coming to the table. That > > needs at least a little similar mechanisms than visibility control for > > your usage rights scenario -- new functionality in the Scene and > > SyncManager to control what is sent to whom and when (now everything is > > sent to everyone on the server, always and immediately). > > > > > Hope I haven't over stepped. We've got developers and funding. If > > > you'll have us we would like to contribute anyway we can. > > > > Certainly no overstepping here -- this is exactly the kind of stuff we > > are here for! > > > > Contributions in these areas would be very welcome, I think all the > > current developers have their plates full with other things so far. I > > recall ENNE.es will need scalability improvements at some point, and > > chiru.cie.fi has been looking into the interest management biz for > > bandwidth optimization reasons (they do research / work on enabling > > mobile use of VWs / MMOs), but I don't think there are any concrete > > plans yet. > > > > Perhaps you could get quite far with the current tech too, just using > > different server instances for the different areas and having tundra:// > > hyper(?)links between them .. or some sort of map of area selection > > menu? > > > > I'm sure you'll encounter also other areas in need of improvement when > > put students to implement apps in py over Tundra or something (is that > > the plan, do you use py in teaching programming or something?) .. I > > don't know what, but we can't have all the basics covered perfectly yet. > > So perhaps good to investigate that before dive into fancy visibility > > controls? Or who knows, that might be quite simple to implement and > > quite powerful .. and the Core API and py&js support etc. do provide a > > lot already. > > > > > George > > > > ~Toni > > > > > On Fri, Jul 1, 2011 at 1:17 AM, Toni Alatalo <t...@playsign.net> > > > wrote: > > > On Thu, 2011-06-30 at 16:42 -0700, sellman wrote: > > > > Wondering.... > > > > Will permissions/security be added to Tundra in > > > upcoming > > > > releases? > > > > > Perfect timing! > > > > > If you look on the -dev list, and recent commits, you'll see > > > that we > > > agreed on the design for it a couple of weeks ago, and I have > > > since > > > implemented the first part of it. > > > > > Completed the first step yesterday actually, the signal now > > > has the user > > > connnection as a parameter so you can treat different users > > > differently. > > > > > So that is already in and coming to next release. Would be > > > great if you > > > could start using it straight away, if you can build your own > > > development version. > > > > > > If not, could accounts/permissions be added to Tundra > > > by creating > > > > our own simple Python module? How complicated? External > > > > authentication looks fairly direct. > > > > > We've continued with that same design: the core has qt signals > > > as hooks > > > that 3rd party c++/py/js code can use to implement > > > accounts/permissions > > > how it wants. > > > > > This is how I've tested it while developing, a js func that > > > denies all > > > remote editing: > > > > > > https://github.com/realXtend/naali/blob/tundra/bin/jsmodules/apitest/... > > > > > s.AboutToModifyEntity.connect(function(change, user, entity) > > > > ... > > > > read more ยป > -- http://groups.google.com/group/realxtend http://www.realxtend.org
