Re: [Opensim-dev] Rate Limit DOS Protection
On Oct 16, 2013, at 8:39 PM, Justin Clark-Casey jjusti...@googlemail.com wrote: In fact, I would say that making OpenSimulator as functional as possible out of the box (within certain bounds such as not bundling a web interface) is a standard OpenSimulator operating procedure. That's why we have SQLite as the default database, for example. I suppose that is certainly the case when you think of it as a distribution also in itself, and not just a part of some larger distros (like Diva's etc). If it would be strictly considered as a lib to be used in some system that fills in the rest, then what makes sense can differ. Like say Bullet or Ogre are. But given that there are a lot of people out there who just use Opensim as is, always new people just grabbing and launching it and starting to use, I figure your statement must have truth in it. I do find Melanie's point valid too, I'm sure you agree with that as well: is good practice to keep it stable so that updates don't secretly break setups. But the discussion how it goes in this case you already had. ~Toni ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] IRegisterInterface for extending scene entities
On Fri, 2012-12-28 at 19:29 -0800, Dahlia Trimble wrote: +2 on a hierarchical entity-component design. I have several prototype :) Is certainly interesting how the plan has come to the table again. and flexible. I've also used it in a prototype c++/opengl viewer which is compatible with SL/OpenSimulator content (prims, sculpties, linksets, avatars, meshes, terrain) and it's quite capable of functioning in this type of scenario.and has performance which is competitive with the fastest LL based viewers I've seen. We have also been happy with how the EC design has been serving in practice. First with Naali against Opensim + new ModRex (Taiga) just to sync persist custom data in scene entities in Opensimulator. Then now in the Tundra effort (i.e. using only the new Naali codebase, also as a simple server instead of Opensimulator) for everything: also the core features are made with ECs not only in the client side but in the network protocol and on the servers as well. That seems to allow many nice things in a uniform manner, for example GUI property editing and generic network synchronization (*). The early article where we reported about applying it in reX tells some of our experiences -- it also discusses that old effort to refactor Opensimulator SOG/SOP to something like this (just refers to Adam's plan basically), An Entity-Component Model for Extensible Virtual Worlds http://ieeexplore.ieee.org/xpl/login.jsp?tp=arnumber=5928309url=http% 3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5928309 For those interested without IEEE lib access, a html view of the source has the ~same content, misses images and the last edits by the magazine folks but essentially the same text: https://github.com/realXtend/doc/blob/master/arch_article/simple.rst (*) That is, both 1. core things such as EC_Placeable (the scene node), EC_Mesh, EC_Audio or WebView for that matter, and 2. your own custom EC_MyAppThing are same kind of components. The entity-component editing gui handles them identically, and the same builtin network messages are used to sync the data in them. The list docs of bundled ECs in Tundra are in http://doc.meshmoon.com/doxygen/component_base.html , perhaps interesting to see examples of scene extensions. I do have mixed feelings about trying to refactor the existing OpenSimulator codebase into such an architecture. So much of the codebase assumes SOG/SOP as the foundation that it may be nearly impossible task to convert. If this is the case, I would suggest first doing a more detailed analysis of how other shared online environments are implemented before attempting a new design; other systems which don't duplicate the SL model; This could result in a far more flexible design which could take OpenSimulator far beyond what SL users expect in a server. Agreed, some thought certainly doesn't hurt here. Hopefully some experiences and examples that we can report from the reX side are helpful, for that analysis of existing envs etc. Basic extensibility is kind of simple to achieve, for example how IIRC it was suggested from Intel's dir earlier .. by just adding a dict for custom data in SOG/SOP or so. Adam's plan was also simple and AFAIK realistic (he just didn't finish for other reasons). Melanie's plan I actually haven't seen personally (other folks within reX started that effort then). This new proposal by mr. Adams I didn't fully comprehend yet, also because don't know the code around Opensim's Scene's RegisterModule interface etc. Did become curious and may take a look when have better time :) Quick comments to a couple of points there: get me the interface for extracting the physical mesh for this SOG In Tundra that is done by accessing entity.rigidbody, i.e. the EC_RigidBody attached to that entity -- it just wraps Bullet. Basically what you suggest, we just call them components instead of interfaces. Wonderland calls them Capabilities (kind of makes sense too, is like a feature you add to a scene entity .. mesh geom, sit target information, light emitting values or whatever). About serialization: Not sure of the nuances of serialization. I believe that the registered interfaces would just be serialized with the SOG (thus saving and restoring the values in the registered interface instances) but I can't be totally sure of that. That's what we do, just save all the data in the components of an entity when the entity is saved. That is made with an attribute system which supports opting out (you can mark things temporary so they don't get saved). Same attribute system is used for the automated network sync. ~Toni On Fri, Dec 28, 2012 at 3:13 PM, James Hughes jam...@bluewallgroup.com wrote: The original proposal to the dev list is here: http://lists.berlios.de/pipermail/opensim-dev/2009-December/008098.html And the attached document here:
Re: [Opensim-dev] OpenSim's direction after Linden cutting support, and the possibility of an official OpenSim viewer
On Wed, 2012-12-12 at 08:15 +, Tom wrote: just a detail / confirmation about UI customization: the development of a bespoke OpenSim viewer is vital. I would argue that an OpenSim viewer is therefore needed. RealXtend is one possibility (having just seen Toni Alatalo's posting) although personally I am not too keen on the viewer frontend. I suspect that the frontend is something that could be readily changed and TPVs are very good at this. Indeed -- even in the extreme extent that with Tundra SDK there is no 'the' frontend. By default if you launch the app you just get a black screen, showing an empty scene (just like Ogre normally when you just create a window with no content). The UI's for chat and AVs etc. are written in javascript and are typically loaded from the net when the client logs in to some service. So for example if the Opensim community or some TPV team agrees on some default Avatar chat bubbles behaviour, with that tech it is easy to do in a modular fashion. Again I'm not saying that current realXtend stuff would work for everyone's (or anyone's :) Opensimulator needs out of the box, but at least such modularity and customization is implemented there. ~Toni On 12 Dec 2012, at 02:03, Adams, Robert wrote: The SL viewer model is an all in one application – viewer, editor, chat client, connection manager, … Maybe a way of attacking the problem is to separate the parts and not think about building one behemoth application that does everything. Some projects (like Radegast or Lumiya) have made interesting progress on a viewer. Maybe content creation can be handled with Blender plugins? Maybe the chat/voice client could be one of the gaming services? Maybe the social connection/interaction framework could be Facebook (OK. No one would ever choose Facebook but any service is possible). Then, of course, there is the problem of the client/server protocol. LLLP (my term for “Linden Lab Legacy Protocol”) grew organically and had different problems to solve (remember the days when SL worked over dialup modems?). An organized, partition-able protocol would go a long way toward making new clients (mobile or continuously connected or …) and servers (distributed or dynamically reconfigurable or …) possible. It’s just a new OpenSimulator region module to talk a new language. Anyway, just throwing that out there. -- ra From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de]On Behalf Of Mircea Kitsune Sent: Tuesday, December 11, 2012 5:00 PM To: opensim-dev mailing list Subject: Re: [Opensim-dev] OpenSim's direction after Linden cutting support, and the possibility of an official OpenSim viewer Ironically, Firestorm is one of the viewers I like least. It's actually starting to worry me how it's monopolizing all third-party viewers and being the only v3 fork getting any attention at this day. Earlier I read that the admin of the Teapot viewer isn't updating Teapot any more because he's now working for Firestorm too... ugh _ I do appreciate their team's effort of course, but I don't like that it's becoming the only alternative, and I'm not sure what else to find and use that I'm comfortable with. But like I explained in the first email, I believe the SL code base is the only path we've got rather than a dead end. SL's system (which OpenSim primarily went with during those years) is a very complex thing. Implementing all of its features from scratch in a good and consistent way would be an effort so big there will likely never be anyone doing it when SL is already there. There was an original viewer once which could render avatars, terrain and objects, but that was about it. The list of features and details is too big. The building tools with grid snapping, arrows to drag / rotate objects, texture position editing, etc. The avatar customization menu, where you customize worn shapes / skins / alpha masks / clothing. Avatar physics, such as clothing fluttering in the wind. The terrain editor with the raise / lower / flatten / smooth tools. The IM / chat / groups systems with all their sub-features. Voice chat support. Sculpt primitives and mesh rendering. Ability to play media on a prim and use HTML pages on object surfaces. The windlight sky and environment (which can also be set as a parcel property). Particles, sounds, spinning objects (llTargetOmega) and the many things you do with LSL scripts. Post-processing with bloom, depth of field, bump-mapping, etc. All this and more would take beyond a decade to re-create from scratch, and I couldn't imagine a new viewer ever doing them all as well as Second Life. If anyone would ever get that done from zero as part of a FOSS viewer, I will consider them a scientist that deserves a job at NASA :) I'm actually surprised even LL did so much in just 8 years,
Re: [Opensim-dev] OpenSim's direction after Linden cutting support, and the possibility of an official OpenSim viewer
Lainaus Adams, Robert robert.ad...@intel.com: Maybe a way of attacking the problem is to separate the parts and not think about building one behemoth application that does everything. Just for info that much of what you describe is what we have done and are doing withing realXtend. Yes, the rumors of the death of reX are very much exaggerated :) We are more alive than ever before I think actually, quite many substantial projects coming next year etc (at least 1Me in public projects even), it just doesn't show to the Opensim community nor worlds. Also an Android build of Tundra has been made now and is in testing, and there's good progress with websocket+webgl client side now again as well. Some projects (like Radegast or Lumiya) have made interesting progress on a viewer. Maybe content creation can be handled with Blender plugins? Maybe the chat/voice client could be one of the gaming services? Maybe the social connection/interaction framework could be Facebook (OK. No one would ever choose Facebook but any service is possible). realXtend is largely about plugging in and using together a set of existing open source products: On the creation side most of the focus is on Blender authoring and export -- even live sync has been experimented. For voice there is Mumble. Chat with XMPP (now a XMPP module is included in the new Tundra 2.4 series). Adminotech's Meshmoon hosting integrates with Facebook and Google, and whatever needed, authentication. Focus has largely been on making a modular framework where integrating different optional things is nice. Different services can then configure the world setups to their needs. For example I tested ages ago using Simiangrid for authentication with Tundra servers and it was easy and straightforward. Then, of course, there is the problem of the client/server protocol. LLLP (my term for Linden Lab Legacy Protocol) grew organically and had different problems to solve (remember the days when SL worked over dialup modems?). An organized, partition-able protocol would go a long way toward making new clients (mobile or continuously connected or ...) and servers (distributed or dynamically reconfigurable or ...) possible. It's just a new OpenSimulator region module to talk a new language. This also touches what we've made in the Tundra effort, dropped LLLP (I usually call it LLUDP :) and use an extensible minimal protocol for the scene-entity sync reusing a generic network lib (kNet, similar to enet). If I'd need to do Opensim server connectivity support for Tundra client's today, would seriously consider writing exactly what you suggest: a server side Opensim module for the new protocol, in this case Tundra over kNet. To summarize, I'd say that in realXtend we've somewhat successfully created a new platform from scratch, addressing the problems encountered with SLViewer, LLUDP and Opensim (hardcoded scene structure/data). So is perhaps interesting to look for folks who think of such efforts around Opensimulator. But for people who are happily using the SL content functionality models as is, rely on efficient prim rendering and using Opensim for chat and groups and everything, certainly just using and maintaining / devving a SLViewer LLUDP etc. based thing is what works. Anyway, just throwing that out there. .. and here just reacting with our basic view, willing to discuss more if there is interest. -- ra ~Toni From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Mircea Kitsune Sent: Tuesday, December 11, 2012 5:00 PM To: opensim-dev mailing list Subject: Re: [Opensim-dev] OpenSim's direction after Linden cutting support, and the possibility of an official OpenSim viewer Ironically, Firestorm is one of the viewers I like least. It's actually starting to worry me how it's monopolizing all third-party viewers and being the only v3 fork getting any attention at this day. Earlier I read that the admin of the Teapot viewer isn't updating Teapot any more because he's now working for Firestorm too... ugh _ I do appreciate their team's effort of course, but I don't like that it's becoming the only alternative, and I'm not sure what else to find and use that I'm comfortable with. But like I explained in the first email, I believe the SL code base is the only path we've got rather than a dead end. SL's system (which OpenSim primarily went with during those years) is a very complex thing. Implementing all of its features from scratch in a good and consistent way would be an effort so big there will likely never be anyone doing it when SL is already there. There was an original viewer once which could render avatars, terrain and objects, but that was about it. The list of features and details is too big. The building tools with grid snapping, arrows to drag / rotate objects,
Re: [Opensim-dev] OpenSim's direction after Linden cutting support, and the possibility of an official OpenSim viewer
Lainaus Adams, Robert robert.ad...@intel.com: Maybe a way of attacking the problem is to separate the parts and not think about building one behemoth application that does everything. Just for info that much of what you describe is what we have done and are doing withing realXtend. Yes, the rumors of the death of reX are very much exaggerated :) We are more alive than ever before I think actually, quite many substantial projects coming next year etc (at least 1Me in public projects even), it just doesn't show to the Opensim community nor worlds. Also an Android build of Tundra has been made now and is in testing, and there's good progress with websocket+webgl client side now again as well. Some projects (like Radegast or Lumiya) have made interesting progress on a viewer. Maybe content creation can be handled with Blender plugins? Maybe the chat/voice client could be one of the gaming services? Maybe the social connection/interaction framework could be Facebook (OK. No one would ever choose Facebook but any service is possible). realXtend is largely about plugging in and using together a set of existing open source products: On the creation side most of the focus is on Blender authoring and export -- even live sync has been experimented. For voice there is Mumble. Chat with XMPP (now a XMPP module is included in the new Tundra 2.4 series). Adminotech's Meshmoon hosting integrates with Facebook and Google, and whatever needed, authentication. Focus has largely been on making a modular framework where integrating different optional things is nice. Different services can then configure the world setups to their needs. For example I tested ages ago using Simiangrid for authentication with Tundra servers and it was easy and straightforward. Then, of course, there is the problem of the client/server protocol. LLLP (my term for Linden Lab Legacy Protocol) grew organically and had different problems to solve (remember the days when SL worked over dialup modems?). An organized, partition-able protocol would go a long way toward making new clients (mobile or continuously connected or ...) and servers (distributed or dynamically reconfigurable or ...) possible. It's just a new OpenSimulator region module to talk a new language. This also touches what we've made in the Tundra effort, dropped LLLP (I usually call it LLUDP :) and use an extensible minimal protocol for the scene-entity sync reusing a generic network lib (kNet, similar to enet). If I'd need to do Opensim server connectivity support for Tundra client's today, would seriously consider writing exactly what you suggest: a server side Opensim module for the new protocol, in this case Tundra over kNet. To summarize, I'd say that in realXtend we've somewhat successfully created a new platform from scratch, addressing the problems encountered with SLViewer, LLUDP and Opensim (hardcoded scene structure/data). So is perhaps interesting to look for folks who think of such efforts around Opensimulator. But for people who are happily using the SL content functionality models as is, rely on efficient prim rendering and using Opensim for chat and groups and everything, certainly just using and maintaining / devving a SLViewer LLUDP etc. based thing is what works. Anyway, just throwing that out there. .. and here just reacting with our basic view, willing to discuss more if there is interest. -- ra ~Toni From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Mircea Kitsune Sent: Tuesday, December 11, 2012 5:00 PM To: opensim-dev mailing list Subject: Re: [Opensim-dev] OpenSim's direction after Linden cutting support, and the possibility of an official OpenSim viewer Ironically, Firestorm is one of the viewers I like least. It's actually starting to worry me how it's monopolizing all third-party viewers and being the only v3 fork getting any attention at this day. Earlier I read that the admin of the Teapot viewer isn't updating Teapot any more because he's now working for Firestorm too... ugh _ I do appreciate their team's effort of course, but I don't like that it's becoming the only alternative, and I'm not sure what else to find and use that I'm comfortable with. But like I explained in the first email, I believe the SL code base is the only path we've got rather than a dead end. SL's system (which OpenSim primarily went with during those years) is a very complex thing. Implementing all of its features from scratch in a good and consistent way would be an effort so big there will likely never be anyone doing it when SL is already there. There was an original viewer once which could render avatars, terrain and objects, but that was about it. The list of features and details is too big. The building tools with grid snapping, arrows to drag / rotate objects,
Re: [Opensim-dev] future plans for NPCs (BOTs) in OpenSim
Lähetetty iPhonesta Hendrik Kunert hendrik.kun...@t-systems-mms.com kirjoitti Dec 19, 2011 kello 10:30 AM: plans for the future, does the community prefer server side or client side bots? And are there plans for Depends totally on the case, but certainly server side are essential often. OTOH bot clients can be very nice and useful too. But I wouldn't port our games to clients side NPCs. -Toni “real” NPC without the need of an real avatar? It would also be nice, if someone could give me some hints, where I can find the bot-relating parts in the OpenSim code. thanks Hendrik ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Any way for the server to get the viewer to send some information to another process on the client PC?
On Nov 11, 2011, at 10:43 AM, Edmund Edgar wrote: Not sure if this is the right place to ask, but wondering if anyone can help me with a problem I'm trying to solve while tinkering around with OpenSim/BitCoin integration. (I'm doing this mainly for my own entertainment - when we discussed it on opensim-users the other day the community didn't seem that into it). Cool to hear - I've also thought of it a bit, when someone asked about it, as it would be simple to integrate in the Naali / Tundra client. Rather than hacking BitCoin integration into the viewer, I'm thinking it might be good to run a separate piece of client software - a custom BitCoin client responsible for managing the user's money - alongside the viewer. When the money module on the server thinks the client Please do it like this so we can use it too :) (we don't use slviewer) So without altering existing viewers, can anyone suggest a way to get a message from the server, via the viewer, to another process? The other process could be listening on a local port, watching a file or doing whatever it needs to do. I'm open to nasty hacks, but not really, really nasty hacks. I don't know if there is anything in the LSL api for this -- I know LSL can open http connections, to do xml-rpc style stuff, but probably that is for the server side only. Dunno if a webview in a client could do it, perhaps if you can use the url opening command to open a html page in slviewer's webview that would send the command with http to the local money component .. might be though that the same origin policy in browsers prevents that. PS. I'm new to OpenSim module development and I've never tried to hack the viewer, so be gentle with me if there's some kind of fundamental misunderstanding behind my question... I don't see any misunderstanding, just that AFAIK vanilla slviewer doesn't support this. Would certainly be hackable there somehow. If you make the standalone component, I can do a proof of concept test UI for it to Naali/Tundra :) Perhaps someone can hack it then somehow to some slviewer based thing too. Unless there already is some way that I just don't know about. Edmund Edgar cheers, ~Toni Founder, KK Social Minds Educational Technology for the Web and Virtual Worlds e...@socialminds.jp +81 090 3912 3380 Skype: edmundedgar Second Life: Edmund Earp Linked In: edmundedgar Twitter: @edmundedgar http://www.socialminds.jp ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Considerations regarding long term development
On Sep 22, 2011, at 4:37 PM, Per Mint wrote: yes, I only have concerns about the core OpenSim functionnality and entities so far. There is one plan that was once made, and even kind of agreed, for a major refactor of the core entities. The SOG/SOP (SceneObjectGroup / SceneObjectPart) refactor. Adam worked on it for a while, and had funding for it from reX, but then unfortunately got busy with other things had didn't finish it (and didn't want any of the money then either, as dropped it). Christa / Diva has asked about it a couple of times and shown some kind of interest, and long ago some of the Intel lab folks wanted a part of the functionality (ability to add arbitrary state / info to the scene entities). Christa was thinking it could be the 0.8 target -- next big rework after the ROBUST / service connectors biz was made in 0.7. The plan is in a PDF in an attachment in a post to this list: Adam Frisby on Opensim-dev, Refactoring SceneObjectGroup - Introducing Components. http://lists.berlios.de/pipermail/opensim-dev/2009-December/008098.html I refer to it in a recent article: An Entity-Component Model for Extensible Virtual Worlds https://github.com/realXtend/doc/blob/master/arch_article/simple.rst (search for 'adam') Just for information, that this is one area where substantial change has sometimes been considered. In fact, little after I first got to know about Opensim .. back in late 2007, the devs (including the original author M. Wright / Darren IIRC) noted how the scene code should be refactored. But it is the heart of core (the sim code), and a couple huge reportedly intertangled classes that are not easy to touch -- refactoring would be considerable work (all those being signs telling that the refactor really would do good). Given how things seem to go currently, however, there is perhaps not so much interest in that as what is there sort of works, and implements the SL model that people use Opensim for. The original goals were also about making a generic 3d / vw app platform, not necessarily similar to SL always, and there the extensibility enabled by such a component model would be more critical. It might make sense to target stabilization of current Opensim as some sort of 1.0, and leaving possible core refactors to later, but I have no idea how the devs see the maturity of others parts and the whole situation. At reX we have that Entity-Component model implemented in Naali/Tundra, so have less pressure for Opensim changes (it was really critical for us to get it somewhere) -- and it was implemented in the modrex module for Opensim anyways (just the extensibility part, without the core refactor but just adding extra to it). Just for some (historical) info of what was once thought and attempted in this area :) Per Mint. ~Toni ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Considerations regarding long term development
On Sep 22, 2011, at 8:20 PM, Pi And Company wrote: Maybe a distro. of OS that has FloatSam Groups, Economy, Profiles, Search, WiFi, and other mod. already built in/ready to go. Well anyone, for example you, is free to make a distro. And, as the other reply already pointed out, there are already existing ones such as Diva. Just to mention that it's up to you if you want it, not necessarily someone else's (e.g. Justin's) job (I think he's responsible for loads already, and also Mel and Diva have their things). Jason ~Toni On Thu, Sep 22, 2011 at 10:59 AM, b...@s-grid.net wrote: Please, do not discourage the devs from doing good work during the release process. It has nothing to do with project status. Thank you, Bo On Thursday 22 of September 2011 16:12:59 Mike Chase wrote: On Thu, 2011-09-22 at 15:33 +0200, Melanie wrote: Hi, at this time we are refactoring and consolidating and fixing bugs. Enhancements will almost always be in modules and fully optional, so using OpenSim as a basis for something else is viable. Melanie So, I have to ask.. This sounds like maintenance. If so why is the project still considered Alpha? Mike ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- The contents of this message, including any attachments, are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this message in error, please delete this message from your system and notify the sender immediately. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Capabilities
On Apr 30, 2011, at 12:37 AM, Justin Clark-Casey wrote: It might be good to separate out generic capabilities code from Linden specifics in case some other environment uses them in the future. However, this is speculative. My understanding was like Melanie's, that CAPS are a somewhat generic thing and not specific to the Linden model. Just a way to get access to things with one time URLs. AFAIK a key to many things in the VWRAP drafts? For example, when we added Mumble VOIP to reX, and we needed some way for the sim to tell what Mumble server is designated for that place, CAPS came to mind as an option (I had finally learned what they are, after 2-3 years of hearing rumours :), and that's how Matti K. ended up implementing it then: http://wiki.realxtend.org/index.php/Current_Mumble_Server_Info_Delivery_Mechanism Client do http get request to 'mumble_server_info' caps url and get response with following headers: Mumble-Server, Mumble-Version, Mumble-Channel, Mumble-User, Mumble-Password, Mumble-AvatarId, Mumble-ContextId (BTW Matti K. later talked with the other ppl who also worked with mumble later, and the plan is/was to switch to their more developed impl for making opensim give mumble info -- that simple impl documented there was basically whipped together in an afternoon iirc). I don't see anything Linden specific about that. That said, I've no idea about the server side code for that in Opensim, dunno what these refactorings would actually mean. Just echoing the view that the idea at least seems generic. ~Toni Also, perhaps a typo point is the the current module is OpenSim.Region.ClientStack.LindenUDP, rather than OpenSim.Region.ClientStackLindenUDP On 29/04/11 22:19, Diva Canto wrote: I would like to clean up the way OpenSim handles capabilities. Here are my goals: (1) move everything-capabilities into LL space, because this is something that's very specific to the Linden-family of clients; and (2) make Capability URLs be externally configurable so that some of those services can be served from a Robust server, if operators see that need More specifically, I would like to: - rename OpenSim.Region.ClientStackLindenUDP to OpenSim.Region.ClientStackLinden - create two folders in there: UDP and Capabilities - Move everything that's currently under OpenSim.Region.ClientStackLindenUDP to the subfolder UDP - Move OpenSim.Framework.Capabilities to the subfolder Capabilities - Move the module that's currently in OpenSim.Region.CoreModules.Agent.Capabilities (CapabilitiesModule) to OpenSim.Region.ClientStackLinden.Capabilities - Move what's currently in OpenSim.Region.CoreModules.Framework.EventQueue to OpenSim.Region.ClientStackLinden.Capabilities - Move what's currently in OpenSim.Region.CoreModules.Framework.Avatar.Assets to OpenSim.Region.ClientStackLinden.Capabilities - refactor some of these modules, so that the handlers themselves are in OpenSim.Server.Handlers, so that they can be served from a Robust server Thoughts? Objections? Cautions? Crista / Diva ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Justin Clark-Casey (justincc) http://justincc.org/blog http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Region scalability of OpenSim
On Apr 27, 2011, at 4:34 AM, Sergiy Byelozyorov wrote: This paper by the Intel's Opensim guys is one at least: Dan Lake, Mic Bowman, Huaiyu Liu. Distributed Scene Graph to Enable Thousands of Interacting Users in a Virtual Environment http://www.pap.vs.uni-due.de/MMVE10/papers/mmve2010_submission_7.pdf . They had a big scalability test last week -- I was unfortunately unable to participate in the end, and haven't heard yet of new results, but that paper at least describes some of the approach. of it before, however I always considered OpenSimulator a an open-source implementation of Second Life server and nothing more. As I have found out, I was wrong - OpenSim does support other protocols than SL. I became curious to know if you also support other architectures than Second Life's, since to our opinion regions are not scalable enough with Second Life. Please help me answering the following questions about what can current Yes, the initial idea of Opensimulator is to be a generic 3d app platform -- SL viewer and the LLUDP protocol, and the embedded assumptions about region sizes and much of VW functionality there, being just one type of an app and client. Every once in a while folks have refactored 'SLisms' out of the core, moving them to the Linden ClientView module that implements that protocol. The reality, however, is still that it's pretty much made after the SL model and basically only used with LLUDP, and mostly only slviewer based clients. I think also some of the devs and many users like to prioritize that -- for some it suffices that it works as a slserver clone, and most important is that it'd do it well. The little experimental Sirikata and now MXP client modules are removed as are unused. The IRC ClientView is fun and useful, though! :) In realXtend dev the SL model hasn't sufficed, 'cause we need also other features (like storing and synching arbitrary, application defined data) so it's been implemented in a module (modrex does the Naali style EC sync with a few custom messages). Opensim devs also agreed a while ago that refactoring Opensim scene core around such a generic extensible model would be good, and we even hired one os core dev to implement it, but the work was unfinished because he got busy with other things (and left opensim dev alltogether). It is AFAIK an open question still whether Opensim will develop as a more generic platform in the future, and if it'll be refactored for scene extensibility -- the plan from late 2009 is attached as a PDF in an email to this list: Refactoring SceneObjectGroup - Introducing Components. http://lists.berlios.de/pipermail/opensim-dev/2009-December/008098.html . An article that explains the idea and status somewhat from reX perspective is at https://github.com/realXtend/doc/blob/master/arch_article/simple.rst (or as pdf, https://github.com/realXtend/doc/blob/master/arch_article/simple.pdf?raw=true . That explicitly does *not* address scalability, this was just to comment that other architectures other protocols part. Your actual questions are better answered by someone who knows the scene code better, but I'll throw my guesses in in the meantime anyway (and I've read the code a couple of times :) Can OpenSim create non-square regions? Can OpenSim create overlapping regions? Can I bound my regions also in 3rd dimension? Not currently. Megaregions can be non-square, though (e.g. 1024x4096). Can OpenSim separate part of the volume of a region to a dedicated server (think of a very popular bar with lots of users in the castle)? Opensim itself not, but the Intel folks have been doing this with server side proxying at least .. that article describes their Client Managers, which are between the end user clients and the underlying scene servers, and allow partitioning (I think also dynamically). Most of these questions are inspired by Sirikata, which was the first world that I have learned about. I do not expect that you are able to do all that, since Sirikata's approach to scalability is interesting indeed, we've been also considering using their system for large worlds on the server side in reX, or alternatively adopting the same techniques in new (currently still very simple, with no scalability at all) Tundra server that have written there. With Tundra we are now really happy with the ease of development, both of content scripting etc. to make e.g. games, and of the platform itself, but probably need to address scalability soon (later this year) so am trying to follow and understand how things with Sirikata, Opensim etc. go. Sergiy Byelozyorov ~Toni Computer Graphics Chair Universitat des Saarlandes Tel.: +49 (681) 302-3837 Web: http://graphics.cs.uni-saarland.de/sbyelozyorov/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Server problem while Helicopter scripting
On Wed, 2011-04-13 at 14:11 -0400, Teravus Ovares wrote: It's like... if you were quoting someone and left off the end quote. Someone reading it would have a hard time knowing the difference between what the person said that you're quoting and what you're saying. The compiler has that issue also with strings. I think that is the correct interpretation of that Python exception. Based on quick googling, Heaton Research only seems to have LSL scripts -- not IronPython rexscript for Opensim+ModRex. Perhaps the original poster's problem is that instead of putting LSL code in a LSL script, he was putting it in a rexscript .py file (which are more like opensim region modules). I didn't find a nice tutorial with screenshots, but basically it works so that you must select the object from inventory in the slviewer gui and go to contents of the object and put the script there. http://wiki.secondlife.com/wiki/LSL_Tutorial is Linden's tutorial about it. And if this indeed is a LSL usage issue, is only using opensim core stuff (also in rexserver) and not rex specific (although the error message was). -Teravus ~Toni On Wed, Apr 13, 2011 at 12:44 PM, Eldor Primov elikp...@gmail.com wrote: Thank you On Thu, Apr 14, 2011 at 1:46 AM, Melanie mela...@t-data.com wrote: We can not support ReX server issues here. The code you're invoking doesn't exist in OpenSim. Please ask this question on the ReX mailing list. Melanie Eldor Primov wrote: Hello I want to make helicopter, but can not fly. I looked through all script in viewer and i am sure that problem is in server side. When I am pressing Page UP helicopter should fly, but it does not. At that time server side(Realxtend-server 0.5) gives note(or error) like: *ExecutePythonCommand exception IronPython.Runtime.Exceptions.PythonSystaxErrorException:EOL while scanning single-quoted string * So I tried another server (RealXtend 04), but it can not compile the script. I have got helicopter script from Heaton Research web page. Thank you ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Opensim Inventory Parser to Obj or other formats?
12.2.2011 3:10, Ina Centaur kirjoitti: Are there existing protocols for conversion of OpenSim inventory items to obj, collada, or other formats, to be relatively usable in a Flash or Unity frontend. There is Dahlia's PrimMesher, which Opensim itself uses to generate meshes out of prim data for the physics calculations. Some c# written viewers use it too to generate meshes from prims for displaying them. With that it's quite simple to generate obj or collada files from prim geometry. We are using a c++ port of it in the Naali viewer to generate meshes in memory for ogre, don't have a feature to save those as files but would be quite simple to add actually. Probably some .net (c# or ironpython or so) standalone converter made using PrimMesher works for you if it's files that you need. ~Toni ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [opensource-dev] Where is MXP implementation ?
On Jan 22, 2011, at 8:39 AM, Rustam Rakhimov wrote: Thank you Toni, but can you be more narrow. Because when I search LLUDP in source code of rexviewer i couldn't find anything. May be it calls by other way. Quite possible, perhaps Linden calls it 'the protocol' :) I just wanna see that part in source code and learn in detail. So could you please tell me where exactly that source code is in rexviewer. Unfortunately I can not, because I must remain able to contribute to opensim, so must respect the contributions policy which denies reading Linden code. Back when rexviewer was developed ( 3 years ago) I was working with scripting on the server side and some separate libomv using apps -- only with Naali etc. have worked on a viewer. I can give a very good hint, though! There is a message template with the names and definitions of all the Linden messages, probably searching for those names solves it for you. in Naali repo that file is at https://github.com/realXtend/naali/blob/develop/bin/data/message_template.msg . So search for e.g. ObjectUpdate or ParcelBuyPass. For further discussion, I think fora with people who actually work with the Linden code would work better for you. Like possibly sl-dev mailing list and imprudence viewer dev. Do feel free to post to rex-dev too. For opensim-dev I think is off topic so let's stop cross-posting there. - Rustam ~Toni ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [opensource-dev] Where is MXP implementation ?
On Jan 21, 2011, at 2:04 PM, Rustam Rakhimov wrote: but, can u tell me same thing but for RealXtend, not Naali. Just i was working with RealXtend Viewer and i still didn't switch to Naali. So i want to know which part in RealXtend was doing functionality of MXP ok, we call that app 'rexviewer' or 'the old realxtend viewer prototype' to avoid confusion :) .. realXtend being the project that has later made Naali after that quickdirty prototyping. rexviewer does not talk MXP, in fact there we didn't touch the UDP level networking on the viewer at all -- just use it. so it only talks LLUDP with the original slviewer code. the old rexprotocol uses mostly the LLUDP generic messages for the new features, and some new LLUDP message was made to optimize movement of many objects. i tested implementing MXP a little by integrating it a bit to openviewer (pyov) when we were starting on Naali two years ago, was fun enough. used pythondotnet to do that, calling the c# reference implementation. one guy here promised to the mxp guys to integrate it to Naali when they provide a c++ lib, but they didn't but asked us to write it instead, and it wasn't the right time for that for us back then. now it can be that knet is better for the transport level than mxp. we chose knet because it behaved better than enet. knet is just the transport, though, does not have the bubbles etc. Virtual World stuff on top which MXP has. we figured separating these two levels is good. mxp could probably be implemented on top of knet if someone wanted. of course integrating MXP as is to Naali is possible too. i have never looked at the slviewer code due to the opensim contribution policy (lludp in naali is written from scratch), but have heard from others that adding a new protocol there is not easy (to put it mildly). and yes the c# idealist viewer has the only actual mxp implementation of the opensim related viewers. ~Toni 2011/1/21 Toni Alatalo t...@playsign.net On to, 2011-01-20 at 12:50 -0800, Dahlia Trimble wrote: I'm not sure about RealXtend, but there is a MXP implementation in realXtend Naali currently uses LLUDP for connecting to Opensim, and knet (either udp or tcp) to Tundra (which is a server module to Naali itself). knet docs are at http://clb.demon.fi/knet/ and code at https://bitbucket.org/clb/knet/ the Naali docs of the modules for knet and lludp respectively are: http://www.realxtend.org/doxygen/class_kristalli_protocol_1_1_kristalli_protocol_module.html http://www.realxtend.org/doxygen/class_open_sim_protocol_1_1_protocol_module_open_sim.html ~Toni IdealistViewer. You should be able to see the code here: http://forge.opensimulator.org/gf/project/idealistviewer/scmsvn/?action=browsepath=%2Ftrunk%2FIdealistViewer%2FNetwork%2F On Thu, Jan 20, 2011 at 12:34 AM, Rustam Rakhimov rusyas...@gmail.com wrote: Where is MXP implementation ? hi everybody, RealXtend uses MXP but where exactly, i mean which part and where its used or implemented please let me know. if possible file name and function name thank you in advance !! ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [opensource-dev] Where is MXP implementation ?
On to, 2011-01-20 at 12:50 -0800, Dahlia Trimble wrote: I'm not sure about RealXtend, but there is a MXP implementation in realXtend Naali currently uses LLUDP for connecting to Opensim, and knet (either udp or tcp) to Tundra (which is a server module to Naali itself). knet docs are at http://clb.demon.fi/knet/ and code at https://bitbucket.org/clb/knet/ the Naali docs of the modules for knet and lludp respectively are: http://www.realxtend.org/doxygen/class_kristalli_protocol_1_1_kristalli_protocol_module.html http://www.realxtend.org/doxygen/class_open_sim_protocol_1_1_protocol_module_open_sim.html ~Toni IdealistViewer. You should be able to see the code here: http://forge.opensimulator.org/gf/project/idealistviewer/scmsvn/?action=browsepath=%2Ftrunk%2FIdealistViewer%2FNetwork%2F On Thu, Jan 20, 2011 at 12:34 AM, Rustam Rakhimov rusyas...@gmail.com wrote: Where is MXP implementation ? hi everybody, RealXtend uses MXP but where exactly, i mean which part and where its used or implemented please let me know. if possible file name and function name thank you in advance !! ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] makehuman anybody??
On Dec 17, 2010, at 1:06 AM, Robert Martin wrote: has anybody played with the Make human program?? This would be a great program to create mesh based avatars when it gets a bit further along. Boris R. at the ENNE labs in Paris (http://ener.ensad.fr/partenariat-realxtend/) did not only play, but has made serious work using MakeHuman during the past half a year or so to make new avatars. I don't know if there's more info about his work anywhere yet, but the blend files should be available soon (I need them myself too, but don't know yet where they are :) He made a low-poly version of the base mesh, and iirc MH team itself has been doing that recently too. Then used Blender to apply some motion captured animation sets they did with a company there in France. These are coming out as free to use / creative commons stuff, new reX default AVs, but you can use them in SL or Sirikata or whereever else too (can export as Collada from Blender hopefully, that's why I need to test the blends, 'cause WebNaali uses the same GLGE engine as Sirikata's web client and we use Collada to bring models there). There's also an idea and interest to integrate MakeHuman to the Naali client, so that you can open it with a click of a button there to edit your av etc. I'll talk with him in Dec or Jan more to see if we can come up with a feasible plan for this. Robert L Martin ~Toni P.S. I was once proud and happy to be given the job to announce the Suzanne Award for the best Blender script of the year for the MakeHuman team, at the Blender conference -- we had to send the statue over to Italy for them as they were not present, but still :) Apparently the year was 2004, they've been working on this for a while.. (it's not a Blender script anymore but a standalone app). ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] makehuman anybody??
On Dec 17, 2010, at 8:24 AM, Toni Alatalo wrote: Boris R. at the ENNE labs in Paris (http://ener.ensad.fr/partenariat-realxtend/) did not only play, but has made oops that ENER, not ENNE, sorry. (enne.es is in spain, they've made a new ui module to Naali which is coming to next release, it allows external ui widgets i.e. using multiple windows and nice docking etc. so my excuse is that in a 3d view from Northern-Finland, Spain and France overlap so that are hard to distinguish!) ~Toni ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] a region module to visualize the state of a software project (Re: [opensim-dev] interfaces to opensim for sensor network data)
On Dec 11, 2010, at 8:19 PM, Richard Hackathorn wrote: WOW!!! Way to go, Markus! And TY to Toni! Eating our own 'dog food' - YES... :) .. The little there is in English now about this opensim's dog food idea, using a VW for software projects and Opensim especially, is at http://www.playsign.fi/web3/Introduction#shared-functional-environments-for-software-projects .. there are still some ideas that are not implemented in current code, like releases being the fruits that the tree produces. Pointed to that originally in April 2009 when wrote the text, but apparently got no replies then -- clearly it helps to have a working implementation and a video :p (http://www.mail-archive.com/opensim-users@lists.berlios.de/msg00974.html). For his thesis, Markus did research into the literature and found some nice similar existing examples from elsewhere too. The diploma thesis is now reviewed at the faculty, not published yet, but I expect it's done soon. I just emailed Markus forwarding your post, and I think we'll setup an updated version at least locally at our studio during the beginning week hopefully, so can verify update the install info to the wiki etc. Or perhaps package a zip with everything preconfigured for a standalone to run this. That's how I got the previous old version that have been running now, just got a copy of the entire opensim/taiga folder from Markus. He doesn't work with us normally, but took leave from his day job to finish his studies at the uni by doing this, and is now back at work etc. so might be fairly busy, but probably can help with setups. And certainly we want instances of these on public servers too so can really start using! But having a local copy will certainly be a nice way for you to get started with your own work with perhaps similar techniques for the data retrieval etc. It's actually really simple, just normal python xml-rpc etc. I think region modules are the way to make apps using opensim, it's just normal programming (not like LSL where you send text messages to communicate between the different things in the scene, which might be the only way in an untrusted federated env though). Ping us in a week if haven't heard back.. ~Toni The video is a WOT! Downloads as M4V and runs well in Win Media Player. Love the bugs! Excited about the IronPython interface as Region module. I would like to replicate this build or something similar. Read thru rexprojectspace wiki and browsed through the py source. Anyone willing to tutor me a bit on technical aspects? Richard Richard Hackathorn Bolder Technology, Inc. Email: richa...@bolder.com SL: Hack Richard On Sat, 11 Dec 2010 06:28:16 +0200 From: Toni Alatalo ant...@kyperjokki.fi To: opensim-dev@lists.berlios.de Cc: realXtend-dev realxtend-...@googlegroups.com Subject: [Opensim-dev] a region module to visualize the state of a software project (Re: [opensim-dev] interfaces to opensim for sensor network data) On Nov 27, 2010, at 4:13 AM, Justin Clark-Casey wrote: I am working on a project to create abstract 'data worlds' based on structures in a relational database. Justin's proposed approach would be great! If there is anything I can contribute (testing, documentation), please Lo-fi public visualization in OpenSim is an interest of mine. There has been some interesting stuff done via scripting on the Linden grid but I think there's also a lot of potential for the server-side approach (because of the advantages outlined previously). There is one quite new example out there btw, which originally came from the idea of thinking how we could 'eat our own dogfood' in opensim development .. visualizing the state of software projects as virtual worlds, to facilitate interdeveloper communications etc. It was developed against the Naali viewer codebase data, as an Opensim region module, but is general enough to work against any software project basically. The code is in http://code.google.com/p/rexprojectspace/ . It creates a quite rich scene on the server entirely from the code in the region module, using data it fetches from various services with http. There's a downloadable video on the project site, http://code.google.com/p/rexprojectspace/downloads/detail?name=rex_beta5.m4v .. demonstrates all these features: It pulls information about the code itself, mainly the module / directory structure, from the version control (on github in this case). And shows commit information, the latest commit msg to each dir. And has an object representing each dev, placed where the previous commit from that dev came. And shows bugs as a kind of flying bugs in the air, it gets that info from the tracker we have at google code .. unassigned bugs have different colour. Additionally it polls a buildbot to show build/test status -- if tests fail, the tree that shows the commits starts burning .. when tests again succeed
Re: [Opensim-dev] Serving textures in different formats
On Dec 8, 2010, at 5:36 PM, Diva Canto wrote: So far, all textures in OpenSim are stored and served as jp2. However, some viewers can't use jp2. Example: Unity3d, for the time being. I would like to improve the GetTexture cap service by adding the ability for it to make conversions on the fly depending on extra data provided by the caller. What about uploading? Ogre using viewers like realXtend apps are also happy with many texture formats, notable DDS which is most lightweight to load 'cause GPUs can decode them on their own. JP2 decoding with open source libs is very heavy, especially on small mobile devices. We've been using PNG as well. One problem IIRC we've had with Opensim is that it converts all the textures to jp2 upon upload. Is not much a problem for us anymore, as we are increasingly using normal web servers to host all assets. But it is insane to convert a png to a jp2 upon upload, and then convert it to png again upon download, so figured to point this out. Given I recall right and this was indeed on the server side, and not in the viewers. Of the actual question, I don't know my preference yet -- usually the easy safe way is to think that using standards like HTTP normally is good :) .. but haven't used those acceptcontent-type headers in own code so don't really know. ~Toni There are two ways of doing this. Which one do people prefer? A) Add an extra query parameter: http://foo.com/GetTexture/?texture_id=uuidformat=format B) Use the Accept and Content-Type headers appropriately. The request might have Accept: image/png, image/jp2 And the response might have Content-Type: image/png Diva / Crista ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Physics
On ti, 2010-11-30 at 11:41 +0100, Melanie wrote: I'm sorry, I can't give any advice on Taiga. The physics when using Taiga, i.e. opensim+modrex, are the same ODE physics that are used with vanilla opensim. Afaik the only difference is that modrex also has code that can feed ode the geom from Ogre meshes. To test you basically just put an object in-world and walk against it with your avatar and see if you collide :) In current Naali works with dragdrop from the web, as documented in http://wiki.realxtend.org/index.php/Getting_Started_with_Naali#Version_0.3.3_.282.11.2010.29 and demonstrated in this video: http://www.youtube.com/user/pallarim#p/a/u/1/uL4M__dCSnk To improve it, search for the ODE physics module in Opensimulator sources. Melanie ~Toni Dionisio Cortes Fernandez wrote: Hello everyone I hope not wrong putting the message here, but I think it is better to seek advice from the developers. I'm having problems with the physics, I tried taiga, but I don´t know how to put scripts or test the physics, so I would ask what would be the best way to improve the physics, files to look, some reference or guide to try to improve physics ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] terrain texture blend weight painting
Hi, we've had a first implementation of terrain texture blend weight painting in Naali for some weeks now. Am posting to ask for insight about how to go about integrating it to Opensim, or at least to give a little heads-up of what is going on with rex dev, also related to the generic scene entity-component work. An ugly but hopefully informative screenshot: http://wiki.realxtend.org/images/2/27/Terraintexturepaint2_scaled.png (from the public sandbox on world.realxtend.org:9000 -- that has auth off). What you see there is two terrains: 1) below a Linden style terrain received from Opensim with the lludp terrain messages, using the height-based texture mapping. The brick tile is used underwater, and the dirt above the water level. 2) above there is another terrain, using the same textures, but so that a weigtmap is used to specify where each texture is used, instead of determining it from the height. So with this you can e.g. paint where roads go for traffic sims or racing games. This works using the previous Naali (0.3.3) release and any version of opensim+modrex, for example the previous Taiga release. It currently just uses a local file to save the weights though, so doesn't work for real use now, but works for testing how it looks etc. currently. Now the question is: are there people out there interested in using this? Perhaps to help with integrating it to Opensim? Or at least with insight to how it should be integrated? Currently in that test Opensim doesn't know anything about that terrain. For Opensim it is just a prim, and the generic entity-component storage mechanism in ModRex is used to store and replicate it to clients. So Opensim doesn't do any collisions with it or anything. There are two ways to go about integrating: a) Add something to the Linden terrain protocol to communicate what technique is used to define the texture usage on a terrain. I.e. keep using the single hardcoded terrain otherwise as is, but just add the option to paint the texture blend weights. This I suppose would be quite simple to hack somehow? b) Work towards having a generic entity-component mechanism, and implement terrain as a component that can support different features depending on the type of the terrain, but integrate with the physics etc. elsewhere in Opensim. We are currently using the b) approach in the so-called Tundra experiment, where use Naali itself as a server (we've added a simple server module to Naali for that, but the scene code etc. is the same as when using as a client). This has been the simplest way to get to test how using the generic EC-model works for making features .. there's nothing hardcoded about the world, it starts as completely empty by default, but you can then add an Environment entity with a WaterPlane component, and any number of scene entities with the Terrain component etc. if you want. And the terrain component feeds the physics info for the physics module (we've also added physics with bullet to Naali). So far it still seems like this would be the good way for Opensim too. Tundra is very much w.i.p. yet and there is no release of it, is in a branch of Naali on github, but we'll make some sort of preview release soon (in 1-2 weeks I think) for those who want to test. But to get this feature to work properly with Opensim quickly I suppose some simple hack to do a) would be it. We'll be using this now with Tundra at least 'cause need it in some projects already now, but if there's interest in devving / using this with Opensim as well I think that'd be cool (and also the folks using it with Tundra now may need it some day in a project where need Opensim feats). ~Toni ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] .net serialization of SOGs
On su, 2010-10-10 at 17:06 -0700, d...@metaverseink.com wrote:
Adam ping!
How's the SOG/SOP refactor coming along? This is coming very close to
the need for the refactoring...
Yes, as I think was even written in the refactor plan, a goal there was
to get Collada saveload support. So that the scene code is first
refactored to use components, and then a new serialization system made
that can do many formats. First .net serialization, but then Collada
too.
All I know is that Adam has put the very first steps to the soprefactor
branch, a little addition that allows to store arbitrary data in
components in a map attached to prims. The refactor is not done, the
hardcoded prim data is still there etc. like before. With the refactor
the idea is that all data would be in smaller components, for example
the prim shape data is in an (optional) prim component etc. It seems
that Adam is so be busy with other things, that if we want the refactor
implemented someone else should probably step up and do it.
About the formats, yes, something that is not an autogenerated dump of
the internal code structures that AFAIK every dev wishes that would be
changed (sog/sop) would be good. A year ago I almost started
implementing OAR readwrite support to Blender, but then when actually
looked at the format decided otherwise and looked at the Collada scene
spec which seemed quite sane. We've since ended up using Ogre .scene
files 'cause it was most straightforward for now (dead simple xml scene
tree, http://www.ogre3d.org/tikiwiki/DotScene).
One suggestion from the talk we had on irc on #opensim-dev now:
k\o\w are you using collada to wrap entire scenes or for individual
meshes?
antont entire scenes
k\o\w I agree that OAR encapsulation should be replaced with collada
k\o\w but that the contained prim data still needs a saner format
like HPA
09:49 antont k\o\w: agreed
We are currently using Collada only when testing WebGL rendering, by
exporting old scenes from Blender that we've previously exported to
opensim+modrex using Ogre .scene and .mesh etc, to Collada .dae that
GLGE can load. But that is giving some more experience with the format
at least, and so far seems good. Of course it is not suitable out of the
box for OAR like usage where we need all the opensim specific bits, like
permissions etc. So perhaps Collada is for importexport, not for backup
and internal things. Unless OAR would be an extension to it somehow, the
x is for extensible after all :) . So I guess your plan to do continue
with the .net xml format but with more control is good.
I'm now about to diverge from your original question and the exact task
at hand, but perhaps it is helpful to explain a bit what we've done now
with scene formats and storing data to opensim to know what kind of
requirements and solutions there are around:
The goal that we have had for which would need the sog/sop refactor,
allowing storage of arbitrary data in scenes, we've implemented in
ModRex as a temporary measure so that the client development has been
able to continue.
The first solution made in March reused an old rex thing that had been
there forever, RexFreeData, which allowed storing max 1024 chars of text
attached to an object (to give params to scripts and for them to store
vals etc). That first impl, used in Naali 0.2 0.3 series, just stores
custom scene entity data as xml in that field and that works also
against the old pre-naalitaiga realxtend servers 'cause that freedata
mechanism was there already. But it is limited to that 1024 bytes
('cause uses a single generic message for synching all data for an
entity, and in lludp messages are max 1024 long).
Now, out since last week, there is a new implemention for custom scene
data storage in modrex. It has tables for entities, components and
attributes and new messages for doing per-attribute synchronization etc.
This is out in Taiga 0.2.0 rc1, but not implemented in Naali yet (I
guess the guys do the client side soon now?). Because it does per-attr
sync, I think is limited at 1024 for the size of an individual attr, but
doesn't have a limit for the aggregated size of all attributes of all
components that are attached to an entity. So should work for pretty
much everything.
We hope that this kind of functionality becomes supported by Opensim
core so that also the data of other applications, and not only the data
specified by the Second Life (tm) application, gets stored in OARs and
works when rezzing things from inventory etc. And here the application
does not mean some realXtend impl, but what *you* or any user defines as
the components attributes of your application. For example, I have a
minimal test component 'Door' with two boolean attributes: opened/closed
locked/unlocked. That works on the platform, but the platform doesn't
need to know anything about doors (in fact is not allowed to know, but
has to be generic and allow any kind of data).
In the spirit of what Melanie wrote about LLUDP
Re: [Opensim-dev] .net serialization of SOGs
On ma, 2010-10-11 at 10:40 +0300, Toni Alatalo wrote: Now, out since last week, there is a new implemention for custom scene data storage in modrex. It has tables for entities, components and attributes and new messages for doing per-attribute synchronization etc. This is out in Taiga 0.2.0 rc1, but not implemented in Naali yet (I Oh BTW a reason for doing that is that there was a need to store custom runtime information about avatars (scenepresences) in entity-components too, so neither the Adam's map in SceneObjectPart in the branch nor the old rexfreedata thing (also for prims only) worked. I guess OARs don't need to save runtime scenepresence info though :) ~Toni ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Srikata ClientView, any users?
On su, 2010-10-03 at 10:49 -0700, d...@metaverseink.com wrote: BTW, RealXtend folks: I would love to see WebSockets in OpenSim. If you already have that, please share! We don't, and all we have is out in the open. Like tried to say below, the c# thing we tried to use is in SimianSim (written by J. Hurliman) but he has only tested connecting to it with some c# test client, and actual web browsers didn't connect to it when we tried 'cause it didn't do the websocket handshake right. The simple stupid excuse of a websocket sim server we have is in http://github.com/realXtend/naali/blob/develop/bin/pymodules/websocketserver/websocketserver.py .. the simplest possible hack we could do to get client development going. The current client that can talk with that is at http://github.com/therauli/WebNaali .. but it also is not much. yet We'll test and add more stuff in the coming weeks and see if that goes anywhere. Is a small experimental side thing, but I do think it can work for relatively simple scenes with basic functionality. ~Toni same code (the component implementations). The simple websocket one we tried also against the c# websocket server stack in SimianSim, but it wasn't complete enough to even respond to the handshake so that a webbrowser can actually connect, so we ended up using an existing working websocket server impl from the Python eventlet library and run that in a Naali py module which is quick to develop. The focus in the websockets work is to get to test basics on the client side with webgl and that's going ok, we sync av movements and see a collada scene using GLGE (but it's currently slow for more complex scenes, we're investigating that). Either of these protocols: the new rex protocol on Kristalli UDP, and a protocol on websockets (now we just send json messages there), are possible to add as new clientstacks in OpenSim later .. if the experiments show that the protocols and clients are useful, and having OpenSim as the server for those is useful. The Sirikata architecture is interesting, and we try to keep track of their webgl client etc. work that uses that ObjectHost architecture, but we still don't know that too well, haven't used it for anything. If having Sirikata support in OpenSim is made later, the old stub is of course still in the repository even if it is removed from current. Perhaps having a pointer to it in the wiki or somewhere would be good if there's something useful in the code to ease googling .. I guess people don't find removed code too easily otherwise. ~Toni On Fri, Oct 1, 2010 at 4:59 PM, Melaniemela...@t-data.com wrote: Hi, Is there anyone who uses, or works with, the Sirikata ClientView in OpenSim? That code is likely nonfunctional in the core version and responsible for a huge number of warnings. If there are no users, we should remove it. Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Srikata ClientView, any users?
On pe, 2010-10-01 at 19:13 -0700, Dahlia Trimble wrote: Perhaps either the HTTP or IRC stacks would be sufficient as a skeleton example. I've sometimes read the IRC stack to see an example, and it did indeed seem useful for that purpose. AFAIK the sirikata one is just stubs, but the MXP one was implemented to do some basics .. against the MXP client side impls in the reference implementation and in Idealist. Things have been quiet in the MXP land though for a long time now, haven't heard anything in months. Within RealXtend we are currently working on two experimental protocol implementations -- one using the Kristalli UDP protocol (kNet, similar to eNet but has some advantages) and then a websocket protocol. Both experiments are now done as Naali server modules, for different reasons: The Kristalli one because it is more straightforward to do the generic Entity-Component attribute sync when both client and the server run the same code (the component implementations). The simple websocket one we tried also against the c# websocket server stack in SimianSim, but it wasn't complete enough to even respond to the handshake so that a webbrowser can actually connect, so we ended up using an existing working websocket server impl from the Python eventlet library and run that in a Naali py module which is quick to develop. The focus in the websockets work is to get to test basics on the client side with webgl and that's going ok, we sync av movements and see a collada scene using GLGE (but it's currently slow for more complex scenes, we're investigating that). Either of these protocols: the new rex protocol on Kristalli UDP, and a protocol on websockets (now we just send json messages there), are possible to add as new clientstacks in OpenSim later .. if the experiments show that the protocols and clients are useful, and having OpenSim as the server for those is useful. The Sirikata architecture is interesting, and we try to keep track of their webgl client etc. work that uses that ObjectHost architecture, but we still don't know that too well, haven't used it for anything. If having Sirikata support in OpenSim is made later, the old stub is of course still in the repository even if it is removed from current. Perhaps having a pointer to it in the wiki or somewhere would be good if there's something useful in the code to ease googling .. I guess people don't find removed code too easily otherwise. ~Toni On Fri, Oct 1, 2010 at 4:59 PM, Melanie mela...@t-data.com wrote: Hi, Is there anyone who uses, or works with, the Sirikata ClientView in OpenSim? That code is likely nonfunctional in the core version and responsible for a huge number of warnings. If there are no users, we should remove it. Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Any work being done on support for Colloda style meshes??
On Sep 18, 2010, at 5:33 PM, Jor3l Boa jo...@foravatars.com wrote: Hi Robert, Naali have mesh support now, not sure about OS Naali viewer works using OS as server, with the ModRex module. Also the old slviewer based realXtend viewer is there for those who need the Linden features that Naali doesn't implement yet. Naali (the new version of an Ogre based Opensim viewer) targets working on all systems .. Runs even on the n900 Linux phone, on virtualpc with mesa software gl (our buildslave runs tests after each commit in a virtual machine) and on laptops with Intel drivers etc. Perhaps Robert referred to the old rexviewer? It needs a good OpenGl impl cause runs Slviewer gl for ui and ogre for the scene in the same gl context. Doesn't work with Intel drivers, does with NVidia and ATI. Naali draws everything with Ogre and works everywhere. Sure it's great though that Linden is coming out with mesh support as well. Reportedly OpenSim will support it pretty much as soon as the viewer comes public. It's been prepared already and is quite a simple addition on the server side. In RealXtend we've made other improvements in the meantime, like importing full scenes from Blender/Max/Maya. The biggest thing that with the new modular, customizable, extensible scriptable viewer Naali +OpenSim is really becoming an application platform .. 'cause you can make your own UI to your app and use the Entity-Component system to add arbitrary data to the scene that you need for your functionality. Is easy to make e.g. custom mouse hovering code that you handle in your own client side script (Python or Javascript currently) etc. Improving this is a main focus in our dev now and we'll be demoing and documenting it more soon. The modularity and extensibility idea is similar to OpenSim on the server side, so we hope this proves to be a good match for people devving apps using OpenSim. For example we have client side GUI now for managing scene imports that live on the server -- using that with OARs might be nice too. Also with Naali there is no behind-closed-doors dev with private alphas etc., but it's all out in the open for you to fork on github and you can get commit rights similarily like to OpenSim etc. But if you just want an application that is exactly like Second Life (tm), does everything that it does, and doesn't need to do anything more, at least currently using slviewer based things are for you. Perhaps with the mesh support we can finally get compatibility so that OpenSim scenes with meshes show both with slviewer and Naali. Possibly helps that slviewer is LGPL now and people are ripping parts of it out to small reusable modules .. perhaps we (or anyone) can add their mesh code in a module to Naali at some point, so can show LLMeshes with Ogre there. ~Toni On Sat, Sep 18, 2010 at 8:47 AM, Robert Martin robertl...@gmail.com Since LL is in the process of launching a Public beta of mesh support i was wondering what is being done on the OpenSim side to also support mesh objects?? (i know about that ORGE project but it seems to be a no -go on my system) -- Robert L Martin ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Proposal: Introduce key:value pair dictionaries into SOP and PrimitiveBaseShape
Justin Clark-Casey kirjoitti: Do you guys see any problems with storing and manipulating dynamic data via the OSD classes in libopenmetaverse? Seems fine so far, but we haven't done anything with it yet. May start with it soon as are starting to use custom scene entity data on the viewer side more, and have now the APIs in place there for addons / scripts to add and use custom data which needs to be synched via and stored on the server. Would Adam's SOG/SOP refactor plan be essientally what you're thinking here, or do you see this somehow differently? I don't recall him needing I'm not sure. If you could provide a reference I'd be obliged. http://lists.berlios.de/pipermail/opensim-dev/2009-December/008098.html .. has a link to the pdf with diagrams etc. about the plan. The first part is now in opensim git in the soprefactor branch, http://opensimulator.org/viewgit/?a=shortlogp=opensimh=refs/heads/soprefactor I noticed Adam had also used a OSDMap to store the component info - perhaps this is very similar to your dynamicattributes branch? ~Toni We need this quite critically for RealXtend, not only because extend the scene for core functionality, but have worked for long now to allow arbitrary data in custom apps that anyone can write for the platform. I'm sure there are good ways to collaborate to get this done somehow -- Adam has told that his work is taking a long time still, so perhaps others like our team you and other devs can speed things up. I still want to implement this, though it's prone now to slipping down my priority list as other things bubble up. My original code also only concerned in memory storage. Persistent storage could be implemented simply by [de]serializing the OSDMap. What I will probably do is chuck the code up on a branch, implement storage and see what you guys think. I'd very much like input from people who would make use of it, since my driving use case (moap) has disappeared. Justin ~Toni John -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Thursday, July 29, 2010 8:55 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Proposal: Introduce key:value pair dictionaries into SOP and PrimitiveBaseShape On 29/07/10 01:40, Dahlia Trimble wrote: Similar to the OSDMap in libomv? Not dissimilar, though the in-memory maps in OpenSim would need to hold arbitrary data types. We couldn't use OSDMap directly unless we were happy to serialize objects to and from OSD for every get and set (or change the values directly in the OSD representation, which might be an idea). On Wed, Jul 28, 2010 at 2:39 PM, Justin Clark-Casey jjusti...@googlemail.commailto:jjusti...@googlemail.com wrote: Hi there. Whilst implementing media-on-a-prim, I've been keeping as much code in the MOAP region module as possible. I'm quite impressed with how feasible this is. However, there remain three major structures where the core of OpenSim has to understand something about media on a prim. 1) Database plugins - to get/put values to named database columns (e.g. prims.MediaURL). 2) Script functions (e.g. llGetPrimMediaParams()). 3) Scene objects (PrimitiveBaseShape.Media and SceneObjectPart.MediaURL). It's difficult to do anything right now about (1) and (2), but I believe there is an opportunity to address (3). What I would like to do is introduce dictionaries into PrimitiveBaseShape and SceneObjectPart that would supplement existing fields by storing arbitrary key/value pairs. So instead of having to hardcode a new MediaURL property on SceneObjectPart I could instead get/put the data as something like SceneObjectPart.Values[MediaURL]. Thus, the dictionaries can act as blackboards for communication between plugins and modules without the core of OpenSim having to get involved. I think that this would move us a tiny way towards our vision of being a generic virtual environment platform and away from hardcoded Second Life specifics, and make it easier to write more ambitious region modules without additions to core. Thoughts? -- Justin Clark-Casey (justincc) http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.demailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Justin Clark-Casey (justincc) http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list
Re: [Opensim-dev] Proposal: Introduce key:value pair dictionaries into SOP and PrimitiveBaseShape
On ke, 2010-08-04 at 21:38 +0100, Justin Clark-Casey wrote: Thanks a lot for reporting this adventure! to be working fine. However, using the OSD representation of MediaEntry got complicated and so I would rather implement dynamic attributes separately to reduce complexity. So how would you go about it? Sorry for the tl;dr but I think that this is a very interesting area. If we could also save the dynamic attributes to persistent storage (rather than breaking them up into separate columns) and have a script infrastructure where functions can be dynamically defined then we could be some of the way to properly separating SL modules and core. Core could be separated out as a content neutral component rather than as part of an ever-expanding monolith. Do you mean this is essentially the only sane way? I don't quite see why the script infrastructure would need to change to allow storage for other uses, but this is probably due to not reading all of the post properly yet (sorry) :p Would Adam's SOG/SOP refactor plan be essientally what you're thinking here, or do you see this somehow differently? I don't recall him needing to touch script infra etc. to begin with. We need this quite critically for RealXtend, not only because extend the scene for core functionality, but have worked for long now to allow arbitrary data in custom apps that anyone can write for the platform. I'm sure there are good ways to collaborate to get this done somehow -- Adam has told that his work is taking a long time still, so perhaps others like our team you and other devs can speed things up. Justin ~Toni John -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Thursday, July 29, 2010 8:55 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Proposal: Introduce key:value pair dictionaries into SOP and PrimitiveBaseShape On 29/07/10 01:40, Dahlia Trimble wrote: Similar to the OSDMap in libomv? Not dissimilar, though the in-memory maps in OpenSim would need to hold arbitrary data types. We couldn't use OSDMap directly unless we were happy to serialize objects to and from OSD for every get and set (or change the values directly in the OSD representation, which might be an idea). On Wed, Jul 28, 2010 at 2:39 PM, Justin Clark-Casey jjusti...@googlemail.commailto:jjusti...@googlemail.com wrote: Hi there. Whilst implementing media-on-a-prim, I've been keeping as much code in the MOAP region module as possible. I'm quite impressed with how feasible this is. However, there remain three major structures where the core of OpenSim has to understand something about media on a prim. 1) Database plugins - to get/put values to named database columns (e.g. prims.MediaURL). 2) Script functions (e.g. llGetPrimMediaParams()). 3) Scene objects (PrimitiveBaseShape.Media and SceneObjectPart.MediaURL). It's difficult to do anything right now about (1) and (2), but I believe there is an opportunity to address (3). What I would like to do is introduce dictionaries into PrimitiveBaseShape and SceneObjectPart that would supplement existing fields by storing arbitrary key/value pairs. So instead of having to hardcode a new MediaURL property on SceneObjectPart I could instead get/put the data as something like SceneObjectPart.Values[MediaURL]. Thus, the dictionaries can act as blackboards for communication between plugins and modules without the core of OpenSim having to get involved. I think that this would move us a tiny way towards our vision of being a generic virtual environment platform and away from hardcoded Second Life specifics, and make it easier to write more ambitious region modules without additions to core. Thoughts? -- Justin Clark-Casey (justincc) http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.demailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Justin Clark-Casey (justincc) http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Robust RemoteAdmin?
Jeroen van Veen kirjoitti: I don't think that the rest remote console is really suitable for that(correct me if im wrong), because you can't be sure what the response will be(it may be something unrelated to the request). It would be handy if robust had an xmlrpc Huh? Usually with http, no matter if it's rest or xmlrpc or what, the response you get is of course to the request you made. Nothing else makes any sense. I can't imagine how or why opensim rest interfaces would be any different, but haven't used them. Jeroen ~Toni On Thursday 08 July 2010 07:53:20 Jor3l Boa wrote: Hi, I'm trying to set up opensim without using php server side to add stuff in the DB (users, edit land, prims..). My first guess was RemoteAdmin but such module is only available in OpenSim.ini and I'm running GRID mode, is there a way to do something like that (xml-rpc admin) in Robust? There is a config ConsoleUser/Pass/Port wich looks similar but the User parameter is new, also, there is nothing related to this in the wiki, anyone have a doc to explain it usage?. Thanks and sorry for my english :) Jorel ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
d...@metaverseink.com kirjoitti: We can, by this order: 1) merge presence-refactor into master 2) create a sop-refactor branch from master immediately after 3) create a 0.7 branch some time later I would like to propose that the sop refactoring work be done in a branch rather than in the master branch, similar to what we did for the I also think a branch for it is a good idea, but don't know why wait - the sop-refactor branch can also be branched from presence-refactor right now if Adam wants to start already. Like Melanie suggested some days ago in this thread. AFAIK this won't be a problem with git, 'cause commits are commits and it doesn't matter from which repo they are from, a version being a set of commits. So sop-refactor could first pull from presence-refactor if work still goes on there, and then keep pulling from master when it lives there, etc. Perhaps this is not relevant anymore if 1) can be done now, might have been a good idea a couple of weeks ago when presence-refactor was pretty much done for parts that touch the scene(?). Also, I'm by no means a git expert, so am curious to know if have misunderstood it somehow and this idea wouldn't work .. Melanie did say in her post that it would. ~Toni services refactoring. It works pretty well -- gives the refactoring devs peace of mind to leave things unstable and isolates the master branch from prolonged instability. Also, are there any suggestions for Adam before he starts doing this? He sent out a document some time ago, but there wasn't a lot of feedback or discussion. Are there any alternatives or wishes for his proposed work? Justin Clark-Casey wrote: Frisby, Adam wrote: I would like to start the SOP refactor fairly soon - what if once 0.7 is tagged for the RC process; I go and and make a new branch; we can sic testers on the presence-branch, while dev happens on the branch I tag? My concern with branching for 0.7 release candidates immediately after the presence-refactor merge is that we won't get everybody helping to iron out the inevitable hiccups since most people follow master. Waiting a couple of weeks for at least some of this to happen is the minimum, I feel. Ideally, I'd like that to be longer but I know that you and other folk want to press ahead. I guess some of this depends on how disruptive the refactor is. What do you think? I'm assuming there will be breakage but perhaps I'm wrong? Of course, I guess you could create a separate sop-refactor branch at any point and start work there, possibly merging back to master and continuing in master once 0.7 RC has been branched. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [realXtend-dev] Re: [opensource-dev] Announce: realXtend Naali 0.1 (alpha) client viewer
On ti, 2010-02-09 at 19:46 +0200, Ryan McDougall wrote: B) I don't see any reason why it shouldn't work on 64bit linux -- although I have to admit my fedora is probably 32bit and so probably no one has even tried. I'm using it on 64bit Linux, works. The problems mentioned in the other post are probably due to not all parts having been built against the same version of Qt. I had to first install qt 4.6, then build all deps and Naali itself, to get it all right. Used the script that is in svn trunk tools/ dir for that on Ubuntu. ~Toni p.s. sorry for the excessive cross posting, but i don't know on which list the question was posed ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] autoexpose every scene (object) attribute over http?
Hi, would it be feasible for Opensim to automatically expose every scene scene object etc. attribute over http? I think everything is possible to add at least by hand to e.g. REST handlers, but having them all without (much) extra manual work would be nice. Perhaps the upcoming scene refactor can facilitate this too? The reason why have been thinking this is to be able to write a client test suite (for Naali) which would do things like: #change an object on the client side e = scene.entities[MYTESTOBJECT_UUID] #the scene entity in the client, for example a prim e.pos.x = 20 #self documenting i hope :) e.sync() #sync the change made in the viewer to the server, using sludp or equivalent #test whether the information on the server matches what the client was supposed to set it to assert e.pos.x == urlopen(http://testregion:9009/scene/entities/%s/pos/x; % MYTESTOBJECT_UUID).read() #(here ignoring types and float conversions and possible inaccuracies etc for simplicity, authentication likewise) I think having a test suite like this would be invaluable when working on protocol stuff, e.g. optimizing packets or testing alternative protocols etc .. but also to test the default impls when refactoring code, kind of an integration test 'cause needs all parts to work. Would be very straightforward to write that kind of tests using libomv too, obviously, when that is more suitable than Naali. Of course having such at least in one way complete REST or equivalent easy access API would probably be useful for many other things too. Perhaps is easy enough to do with .NET reflection stuff, which is also needed for OAR saving of the data in the upcoming components to work? (or how does the plan go there exactly?) Regarding the earlier post, about web services by ssm2017 asking about the general state of the web services and where they are in the code etc., I personally have no clue 'cause haven't used them yet -- others here know, and finding them in the code with normal searches is probably easy. ~Toni ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] User services refactoring status
Impalah Shenzhou kirjoitti: http://www.dotnetnuke.com/ Is a CMS (like Alfresco, Drupal, Joomla...) but runs over .NET. It shouldn't be too difficult to connect the native Opensim components to get/set data instead of accessing directly to database. It is also possible to use some of the Python written CMSes and web frameworks (Django and such) and the Opensim .net code together. I'd do it with pythondotnet, which is a .net to Python bridge for the normal cpython that allows use of .net libs in py apps. I've used that to use LibOMV in Blender before - it runs the normal .net vm under the hood and just translates the types passed/returned in the method calls, performance has seemed ok and would certainly be fine for the management stuff I can imagine. Another option would be IronPython, some folks have tried running Django on it: http://jdhardy.blogspot.com/2008/12/django-ironpython.html but afaik that is still incomplete - probably some simpler web frameworks work fully on it already. To me using the opensim code instead of direct access to DB seems attractive, given that the schemas may change, and that it's easy to make a mess if have bugs in own code that work with the db differently than Opensim itself? ~Toni 2010/1/7 Fly Man fly.man.open...@gmail.com mailto:fly.man.open...@gmail.com In other words: Wiredux won't use those connectors but will grab to the database itself. Wiredux is not a .NET application so it will go directly to the database. I will wait until the refactoring is done, have a look what's wrecked and maybe fix it. 2010/1/5 d...@metaverseink.com mailto:d...@metaverseink.com Putting PHP in front of the DBs is one of the most natural things to do from here on -- not just the things that Wiredux does, but for a lot more! In fact, the entire collection of OpenSim.Services that are provided as reference implementations can be replaced with implementations in Apache+PHP. Calls from the simulators to the services are now all neatly packaged in OpenSim.Services.Connectors (these are the out connectors). Just browse through those connectors and check out the wire protocols, then do the receiving end in PHP. Many of them are using standard web forms, others use XMLRPC, others use custom-made HTTP-based dialects. Calls from outside to the simulators are packaged in OpenSim.Server.Handlers. Again, check them out and, if not using .NET, write your own client for them. If using .NET/mono you can import the DLL OpenSim.Connectors.dll, and reuse the existing connectors as-is. But that's not all. Since now the interactions between the simulators and the resource services are all formalized in interfaces (OpenSim.Services.Interfaces), and the handlers and connectors in the simulator are loaded dynamically, you can replace the connectors and handlers themselves. In other words, if you want OpenSim to talk web services, roll your own Web Services handlers and connectors under those interfaces, and you're done -- you'll have to use .NET for this part, though. Tom Willans wrote: Hi, First thanks for all your work. I assume from this that the webredux will no longer work without modification and will need updating. ( Thanks again here). Is there any information about the new authentication approach anywhere, if not in detail then an overview. Is LDAP on the horizon? I am mostly interested in linking php based frontends to opensim and hence accessing the database directly. Particularly relevant is moving away from using UUIDs. Please forgive me if I am missing something but I assume there are no web-services that can be called and calling C# from php is not a very good solution. Thanks. Tom On 5 Jan 2010, at 10:37, Ai Austin wrote: At 18:32 04/01/2010, opensim-dev-requ...@lists.berlios.de mailto:opensim-dev-requ...@lists.berlios.de mailto:opensim-dev-requ...@lists.berlios.de mailto:opensim-dev-requ...@lists.berlios.de wrote: To be honest, I don't think Sqlite should be a database type that we (OpenSim) should keep alive in the project, It is useful to have a double click and go out of the box solution which people can try out and test with. One other use of SQLite that I am aware of and fine very useful is for the really
Re: [Opensim-dev] Client-side API/scripting Re: LookingGlass Viewer progress
Dzonatas Sol kirjoitti: Mister Blue wrote: Several people are playing with protocols and I am intrigued by the possibilities of a better protocol. That is the case with realXtend development now too. The new Naali viewer has the basics of the old things implemented now, against the pre-existed server implementations using the sl protocol. But one of the reasons for writing a new viewer was to be able to switch to another protocol, or perhaps even support multiple protocols for different services like has been discussed recently. We've having a short (1-2) weeks research period in early January, besides finalizing things for the Naali 0.1 release in late January, and one of the things will be looking at more closely now is protocols. MXP has been in the talks and something like that might be what we need, let's see. Basically the idea is to have something good for transferring the default movement updates etc. efficiently, and then a way to describe application specific custom messages that would be efficiently transmitted as well - not kind of second class citizens like the generic messages in the sl protocol. Something like Google protocol buffers, perhaps. Let's say there are two main routes for protocols in regards to this area. Between the grid/server and the viewer/client is more of the easiest one to point out. We can call this route as being in the Agent Fair enough, so the above was about the former. could say it is within the User Domain. The User Domain is where all the client-scripts and interfaces communicate. If we can somehow standardize the REST/HTTP based APIs, then that would be a key element to many developers that make human-computer interfaces and want to make them more immersive. This also applies for those that just want their developer tools to 'just-work' easier with the Agent Domain without the the need to write an entire new viewer. (i.e. a blender plug-in that can easily import/export a live version of an object before it is uploaded to the grid -- or, a movement control to help machinima be easier and be supported separately from the viewer). That has been one of the goals in the Naali development, actually the one I've been personally responsible for. One of the motivations actually being Blender integration, but mostly to enable making things to the viewer itself. Also on the c++ level Naali is a module framework, with the idea is that anyone can write the modules they want - indeed to not have to write a viewer, but the own modules, inspired by the idea of Opensim itself. But what I've been working on is the same for interpreted langs, so far Python and Javascript. Currently the editing UI in Naali, also in the 0.0.2 developer preview release we made in October and enhanced in trunk, is a plugin that could well be written by a 3rd party and the core doesn't know anything about it - just provides a powerful enough API that you can do object placement in 3d using the mouse, draw local graphics to hilite the selected scene object, and make gui widgets using qt etc. It shows in the first screenshot in http://wiki.realxtend.org/index.php/Getting_Started_with_Naali#What_is_Naali.3F - the panel called World Edit, and it's also responsible for showing the movement arrows that are drawn with the Ogre head. The source for this py plugin is at http://code.google.com/p/realxtend-naali/source/browse/trunk/bin/pymodules/editgui/editgui.py - the idea is to support similar stuff for Javascript too, for more info see http://wiki.realxtend.org/index.php/Interpreted_Languages_Working_Group The API for manipulating objects, tracking the mouse etc. was actually developed for other reasons starting in spring (we wan't to make custom UIs for our arcade games at Playsign), but coincidentally it fitted that basic UI tool too so has been used to write that. The idea now has been to use the editing UI as a proof and driver for the API, trusting that it can then used by others for many kinds of other things too (and indeed to customize / enhance the editing itself more easily). We started the work by manually exposing c++ things to Py while evaluating the automated tools for it, and later when the project adopted Qt for UI, we've started using the object metadata system of Qt for scripting support as well. The slots (methods) and properties of QObjects show automagically to Python via PythonQt, and to Javascript via QtScript. Also the normal Py Qt things are available, so you can things like http requests and show qt webviews etc. (the source of the w.i.p mediaurl handler featuring a WebView to render HTML to show as textures in Naali is http://code.google.com/p/realxtend-naali/source/browse/trunk/bin/pymodules/mediaurlhandler/mediaurlhandler.py) Another experiment I did in July was to have a Py written http server running inside Naali: http://wiki.realxtend.org/index.php/Naali_webserver_plugin ..
Re: [Opensim-dev] Server based navigation/pathfinding
Teravus Ovares kirjoitti: stored on the simulator and there's a chance that if you start now, in a month or two, the module will be obsolite because the API changed significantly. I would wait until about 2 weeks after 0.7 is tagged.. which should be sometime in January. That is a valid point, and perhaps good advice, but I still think that you don't necessarily need to wait to proceed with new things like this that use the scene data. I believe that if this was done now, it would be quite simple to port to the new system later. After all, very many things in opensim itself and other modules need to be ported, so the refactoring can't make all those obsolete, 'cause we'd end up with having no functionality at all. The same data remains there, just accessed in a different way which doesn't make much of a difference to an algorithm like A* .. It doesn't change basically anything about the actual work a module like this need to do (generate a waypoint graph, have a a* backed autopilot impl). So if the original poster wants it quick, can just do it, and the work won't be wasted - just needs some porting later. If is not in a hurry and wants to save the trouble of learning the scene API twice, first the old and then the new, is a good idea to wait indeed. 2009/12/23 V.Rovensky v.roven...@lit.cz: to find the route for my bot. I was thinking I could create an invisible prim for every waypoint and reimplement the autopilot function so it suits my needs a little more. To do this I suppose I need to do the following: With these manual markers this seems quite simple. Before noticed this part, was thinking that the navigability of different kind of geoms might be very difficult to deduce from just the visible geometry or even collision data, especially if you'd need to support arbitrary kind of builds by users etc, query the physics code or something etc. 1) Be able to access all the region's prims, their locations and shapes to create and manage the graph of waypoints How do you get the connections for the graph if you have the points only? And how do you know which of the scene entities are waypoint markers - use simply some naming convention perhaps? 2) Be able to reimplement the autopilot function, so whenever the client starts autopilot, my method gets called and sends the client along the computed route. Could this be done via RegionModules? I'm fairly new to OpenSim development, so any tips that could point me the right way would be greatly appreciated. Seems like a good fit for region modules to me, 'cause what they get from the sim is a reference to a scene object where you can get all the scene objects (i hate the term 'prim' for them which is just one way to define geometry :p) .. am not sure how you'd go about hooking this to the existing autopilot mechanism, but I'm sure it's possible somehow. And that part (if it relates to scriptengine etc) I guess won't be affected by the sceneobjectgroup/sceneobjectpart refactor (much) at all. If/as you just need the positions of your custom scene objects to form the graph from those nodes, my guess actually is that the refactor may result in very little code changes to this tool (5-10 lines change perhaps, just the call how to get all entities (of a type?), and then how to read position data from them? is just an ignorant guess, not knowing much of the details of the current impl or the new plans .. i know how a* works in our games though and what the opensim primdata is). A big idea behind the upcoming refactoring is that the core would support applications having arbitrary data about scenes - for example navigation graphs. In the new model I think a navigation graph like yours could be a component type, which you could register to the system from your module and the core could then store it etc. And perhaps support communicating it to the outside too - we have the same entity-component model in the Naali viewer, and the idea is that we'd then support having custom components both on the viewer and the server and networking to sync the data in between. So that you could just make the graph in the viewer with a custom editor for that, and it'd be synched to the server as well, and you could e.g. do a* on eiher or both depending on needs. V.Rovensky ~Toni ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Mumble Voice
Jeroen van Veen kirjoitti: does that mean that the prototype's version can be used as a dropin replacement for SLVoice with the vanilla sl-viewer? Yes, I think so. It was made about two years ago, dunno if has needed touching since, nor whether anything has changed in the ipc protocol recently that would break it with newer viewers. Jeroen ~Toni Op zaterdag 05 december 2009 07:48:42 schreef Toni Alatalo: Rob Smart kirjoitti: Mumble/Murmur looks great (Murmur is the server component) but they use the speex codec which is not supported by SLVoice (the SL clients inbuilt VOIP client) so use of it without modifying the client is unfortunately not possible. IIRC the original rexviewer prototype (aka. the current prod. version) comes with a slvoice replacement which uses Speex. AFAIK slvoice is a separate app with which slviewer talks over some kind of ipc, so it can be changed to another implementation without touching the viewer itself. Rob. ~Toni On Fri, Dec 4, 2009 at 2:10 PM, Robert A. Knop Jr. rk...@pobox.com mailto:rk...@pobox.com wrote: I don't know if anybody is aware of this, but there's a fully open source (BSDish) VOIP server/client named Mumble -- http://mumble.sourceforge.net/ . I don't know if they have a library/API that could be used for integrating the server into other things. However, this might be something that could be integrated into OpenSim as built-in Voice. (It would require changes to the client as well, of course.) I know that some folks use Skype or phone voice bridges to use Voice while in OpenSim, but I've found that not having the visual feedback on who's talking (voice gestures or the green lines over your head) really breaks the immersion. It'd be great to have some sort of built-in Voice solution (even better if it was spatial, but even just global with visual feedback would get us most of the way there). Is anybody working on integrating Voice into OpenSim right now? I know that there's something going on with FreeSwitch. Who's the expert on Voice in OpenSim? -- --Rob Knop E-mail:rk...@pobox.com mailto:rk...@pobox.com Home Page: http://www.pobox.com/~rknop/ http://www.pobox.com/%7Erknop/ Blog: http://www.sonic.net/~rknop/blog/ http://www.sonic.net/%7Erknop/blog/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFLGRhdfEn1oMJSrdsRAuyiAJ41T9G8sDyyQ15tZlM0u4gdKWevoQCg4oKp xUuX1dtP9NSWNkwuzAOQ73w= =ovBl -END PGP SIGNATURE- ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] scene import/export to another app: oar? dotscene? collada?
Paul Fishwick kirjoitti: Could OAR be generalized to include scene graphs with meshes? That would be really nice as it would create two things not currently supported: hierarchical scene graphs and triangular mesh. If an importer is written to opensim, It is possible. A simple hack would putting a reference to a mesh asset to the place where shape entry with the geom data is used for prims. As OAR is a serialization of the internal SOG/SOP data structure, and ModRex extends those to have the mesh references in the scene, it in a way already does that. Like Mikko Pallari commented to this discussion on rex-dev yesterday, we could easily add another serializer in ModRex that would do that: save OARs where 'prims' are not prims but scene nodes with mesh references, and have ogre mesh assets in the assets dir of the oar. That would already be useful for what OARs are for: saving scenes from OpenSim and loading them back, in that case just with also the Rex (Ogre) data. But it might not be helpful at all for exchanging scenes between Opensim and other applications, which is what I'm looking into now. then it is a matter of coaxing the viewer to render these.. In your list of options, you might also consider the indexedfaceset of X3D for the mesh (X3D also supports a true scene graph). Yes, it is a possible format also. I've now been leaning against writing OAR support elsewhere exactly 'cause it is the internal structure and perhaps awkward for what need now. For example there is no single file with the scene as positions of all objects, but a separate file for every object which has both the scene pos and in case of prims the shape. And if SOG/SOP refactoring happens within OpenSim, it easily changes the OAR 'format' as well, and would break reading archives written using some custom thing that would write the files as they are now .. right? DotScene is somewhat attractive 'cause it's simple and there are working exporters for Blender, Max, Maya and for some editors written using Ogre itself. There's a C# loader we've used in our company before when using MOgre, http://www.ogre3d.org/wiki/index.php/MOGRE_dotSceneLoader . Downsides of DotScene are that it's Ogre specific, and contains *only* the scene, leaving textures and meshes etc. out .. which may be ok though, 'cause textures are just images and there is separate code for mesh export so getting those over too is just a matter of packaging files for transport (perhaps in a .oar like container). Collada and X3D would be engine independent standards that would probably easily cover all I need now, so probably must give them another look before starting to port that encouraginly simple dotSceneLoader (a single simple 600 lines c# file) to OpenSim.. so will be googling for .net libs for Collada and X3D next I guess (there's exports to both from Blender, am not sure if the X3D one does scenes though .. and am a bit afraid of how complex and big collada stuff may be, but hopefully that fear is in vain). Thanks for input! -p ~Toni Toni Alatalo wrote: Hi, I started looking into implementing scene exchange between Opensim and Blender yesterday, and am planning to continue later today. Was reading OARs and the code in OpenSim.Region.Framework.Scenes.Serialization .. where SceneObjectPart #region XML Schema seems to be the fields that are autoserialized by some .net writer, right? It seems well possible to read and write OAR elsewhere, but I'm not sure if it makes sense, or whether it's more the internal representation in Opensim. Are there any alternatives? With Ogre we've sometimes used the simple DotScene (.scene) made for it, and basically that would cover the info I'm interested in now (positions of meshes in a scene, not prim geom 'cause am not having prims in Blender at least right now anyway). There is an existing DotScene exporter for Blender, would it make sense to write an importer to OpenSim? Or a Collada scene importer perhaps? I haven't looked (yet) what the scene format there looks like. For the Ogre format there is a 15 line complete scene example at http://www.ogre3d.org/wiki/index.php/DotScene In one way the question is: does OAR loading work with 'partial' data, or would I have to make the exporter write all the fields? Am now looking into exchanging this data first: GroupPositionX123/XY129.55/YZ29.340004/Z/GroupPosition OffsetPositionX0/XY0/YZ0/Z/OffsetPosition RotationOffsetX0/XY0/YZ0/ZW1/W/RotationOffset ScaleX17.7774/XY22.8028/YZ69.2987/Z/Scale and things like velocity would not apply .. also, are valid region handles, creator-id etc. required, and should I generate GUIDs at export? I'll experiment what happens at loads of partial data etc., and of course can just make the exporter write all those fields, but hints are welcome so would not be banging my head against the most irrelevant walls. ~Toni
Re: [Opensim-dev] scene import/export to another app: oar? dotscene? collada?
Justin Clark-Casey kirjoitti: I've now been leaning against writing OAR support elsewhere exactly 'cause it is the internal structure and perhaps awkward for what need That's theoretically true, but I should think that the old format will still be loadable in some way since changes here would break everybody's existing content Yah was thinking about the same - I guess there are ways to deal with that .. perhaps kind of loosing the initial comfort of automatic serialization though, needing manual processing for backwards compat. Separate files for objects and assetes were used in order to potentially allow regions to be more easily composed out of world from separate components. Whether this is a good thing or whether there are more advantages to a single monolithic file is, I'm sure, something that could be debated. Agreed - I think assets in separate files easily make sense, and for SL/Opensim like prims too 'cause there is no distinction of the specific geom and it's instance(s) in the scene. That said the single file Collada .dae files that am working with now seem sensible too. Collada and X3D would be engine independent standards that would I built something called 'ColladaDotNet', using the Collada Document class from the Collada for XNA project, and have succesfully tested using that to read reference Collada scene files, and my own exports from Blender. Am planning to test importing scene info to Opensim / ModRex using that .. first just object positions. May test in the Naali viewer (first) too .. reading collada files there for local preview (may use with the pycollada lib there, have the same test as for ColladaDotNet working now with that too). ~Toni Toni Alatalo wrote: Hi, I started looking into implementing scene exchange between Opensim and Blender yesterday, and am planning to continue later today. Was reading OARs and the code in OpenSim.Region.Framework.Scenes.Serialization .. where SceneObjectPart #region XML Schema seems to be the fields that are autoserialized by some .net writer, right? It seems well possible to read and write OAR elsewhere, but I'm not sure if it makes sense, or whether it's more the internal representation in Opensim. Are there any alternatives? With Ogre we've sometimes used the simple DotScene (.scene) made for it, and basically that would cover the info I'm interested in now (positions of meshes in a scene, not prim geom 'cause am not having prims in Blender at least right now anyway). There is an existing DotScene exporter for Blender, would it make sense to write an importer to OpenSim? Or a Collada scene importer perhaps? I haven't looked (yet) what the scene format there looks like. For the Ogre format there is a 15 line complete scene example at http://www.ogre3d.org/wiki/index.php/DotScene In one way the question is: does OAR loading work with 'partial' data, or would I have to make the exporter write all the fields? Am now looking into exchanging this data first: GroupPositionX123/XY129.55/YZ29.340004/Z/GroupPosition OffsetPositionX0/XY0/YZ0/Z/OffsetPosition RotationOffsetX0/XY0/YZ0/ZW1/W/RotationOffset ScaleX17.7774/XY22.8028/YZ69.2987/Z/Scale and things like velocity would not apply .. also, are valid region handles, creator-id etc. required, and should I generate GUIDs at export? I'll experiment what happens at loads of partial data etc., and of course can just make the exporter write all those fields, but hints are welcome so would not be banging my head against the most irrelevant walls. ~Toni ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] scene import/export to another app: oar? dotscene? collada?
Hi, I started looking into implementing scene exchange between Opensim and Blender yesterday, and am planning to continue later today. Was reading OARs and the code in OpenSim.Region.Framework.Scenes.Serialization .. where SceneObjectPart #region XML Schema seems to be the fields that are autoserialized by some .net writer, right? It seems well possible to read and write OAR elsewhere, but I'm not sure if it makes sense, or whether it's more the internal representation in Opensim. Are there any alternatives? With Ogre we've sometimes used the simple DotScene (.scene) made for it, and basically that would cover the info I'm interested in now (positions of meshes in a scene, not prim geom 'cause am not having prims in Blender at least right now anyway). There is an existing DotScene exporter for Blender, would it make sense to write an importer to OpenSim? Or a Collada scene importer perhaps? I haven't looked (yet) what the scene format there looks like. For the Ogre format there is a 15 line complete scene example at http://www.ogre3d.org/wiki/index.php/DotScene In one way the question is: does OAR loading work with 'partial' data, or would I have to make the exporter write all the fields? Am now looking into exchanging this data first: GroupPositionX123/XY129.55/YZ29.340004/Z/GroupPosition OffsetPositionX0/XY0/YZ0/Z/OffsetPosition RotationOffsetX0/XY0/YZ0/ZW1/W/RotationOffset ScaleX17.7774/XY22.8028/YZ69.2987/Z/Scale and things like velocity would not apply .. also, are valid region handles, creator-id etc. required, and should I generate GUIDs at export? I'll experiment what happens at loads of partial data etc., and of course can just make the exporter write all those fields, but hints are welcome so would not be banging my head against the most irrelevant walls. ~Toni ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] ConsoleClient -pass option
Dr Scofield kirjoitti: operations involved (i.e. the load oar function specifies how the oar file is transported over the wire) so the interface is truly remotable. If you i've to agree on that. i'd started something like that, but haven't really made any headway due to lack of time. being a pythonista i tend to look at things through python glasses: invoking an XmlRpc method is easy, doing the same thing with REST is a pain. Where is the pain with REST? Am just curious to learn more, have written some REST servers and simple clients to them in Python, but used XML-RPC and SOAP too. Haven't written complex REST clients (yet). Invoking a method is of course trivial, just a http get, but does it get difficult with parameters then? http://code.google.com/p/python-rest-client/wiki/Using_Connection says: conn.request_post(/upload, body=body) is it difficult to put a oar file in the body? or are you talking about defining types, having the signatures of the methods etc explicit in some interface description? Like with SOAP it was kinda handy with soappy that what you get to py is normal objects with functions with __doc__ about the parameter vals and return vals etc. DrS/dirk ~Toni ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] versioning question
Stefan Andersson kirjoitti: to me, that what the community wants is some sense of progression to compare two official git revisions to each others. That seems to be the case indeed. We are already doing this by tagging releases with a version number, so either we a) start doing (tagging) more frequent official releases so most users very seldom feel the need to bother with individual git revisions. or b) Tag some kind of sequential number to each opensim commit, possibly by adding some git commit hooks to update a text file somewhere. I doubt a) would suffice and that we'd easily want b) - the granularity of individual commits. On the surface post-commit hooks sound better to me than the technique parsing and processing log output, which was done in the solution in that one blog post .. the idea there seems nice though, but I still don't even understand it fully so this view is to be taken with a grain of salt. http://michaelandlaura.org.uk/~michael/blog/index.php?id=379 That would mean, basically that we would have a show version output saying something like OpenSim 0.6.6.10201 (Git:6cf610) (Dev) (interface version 5) Seems like something that could make everyone happy :) /Stefan ~Toni -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Toni Alatalo Sent: den 3 september 2009 20:07 To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] versioning question On Sep 3, 2009, at 7:30 PM, Justin Clark-Casey wrote: The next revision to 6cf610 will be 6cf610 + 1 = 6cf611, then at least there is some logic to it. This is exactly what isn't the case - the identifiers are generated randomly without any connection between them. This seems to be one of the (few) downsides of git. In a way it is what GIT, and distributed versioning control, is. I think at least, am still just learning the practice of it.. On the base system level, there is no sequence 'cause you can arrive to the same situation in many ways. Commits are commits, and each commit/revision/patch has an identity. I think this 'theory of patches' applies to GIT as well, the part about 'Patch relationships' seems relevant http://darcs.net/manual/node9.html#SECTION0094 .. besides sequential patches there are parallel patches: There is one other very useful relationship that two patches can have, which is to be parallel patches, which means that the two patches have an identical context (i.e. their representation applies to identical trees). Of course, two patches may also have no simple relationship to one another. In that case, if you want to do something with them, you'll have to manipulate them with respect to other patches until they are either in sequence or in parallel. So to have what grows as a sequence in the current opensim main thing, something else besides the individual patch IDs are needed. The thing in the blog post that has been referred to seemed promising, but don't know much about that. ~Toni There was some talk on this list about somehow producing sequential numbers some time ago but I don't know the details. If my hex intuitions serve me, 6cf610 a82950 so does anyone know how these version #s are to be interpreted or are they random identifiers? And if they are random, how do we track where we are? maybe, I should go back to the 10185 revision(s) and use that #. -p not sure how to interpret this hexadecimal indexing. Should I consider 10185 to be the number? The actual commit # is a long hexadecimal string. The beginning of it matches what you said: 6cf610 is the revision #? Do we need to bring out the old HP calculators? :) -paul Justin Clark-Casey wrote: Paul Fishwick wrote: Justin: Justin Clark-Casey wrote: The 'interface v5' part refers to the interface protocol between the region simulator and the grid (and defacto, between region simulators). It doesn't have anything at all to do with the OpenSim version (0.6.6). OK In principle, if you are running from a source repository update then the git version should be tacked on the end of OpenSim 0.6.6 (e.g. 0.6.6 239a1). This should also be true if you are updating from the SVN mirror (e.g. 0.6.6.10108). If this isn't the case then this is arguably a bug. Where does one find this build # (i.e., 239a1 or 10108) ? It is not produced through show version. If that is a bug, I can file it. -paul If you execute 'git log' on the command line, the long string after the word commit is the build identifier, e.g. in paste commit 4841858600cf35903966d48451015b2be5e97d5c
Re: [Opensim-dev] client API bindings?
Maróy Ákos kirjoitti:
Now I finally understand what you are after, after reading about x-plane
on the net and your original message again..
X-plane is a standalone non-networked app, a single player simulation.
You want to make it networked, and consider using the OpenSim server for
that?
The wording 'x-plane client' in your original post lead me to think that
it already is a client-server architecture, and you have an existing
protocol and some server implementation already etc.
basically the point is that one has to have a client library in
languages that compile to native code, most preferably C and C++.
Ok.
Well for the existing protocols to OpenSim there are several
implementations. Most common one to write clients is LibOMV, which is a
cleanroom SL(tm) compatible SLUDP implementation in c#. So it doesn't
compile to native code.
In Realxtend Naali we have another from scratch implementation of that
same protocol, written in C++. That might work for you. It's Apache
(bsd-like) licensed. The web svn view to it is
http://dev.realxtend.org/gf/project/viewer/scmsvn/?action=browsepath=/trunk/OpenSimProtocol/
http://dev.realxtend.org/gf/project/viewer/scmsvn/?action=browsepath=/trunk/OpenSimProtocol/
A relevant part in the documentation is Interfacing with the OpenSim
world using OSUDP message at
http://www.realxtend.org/doxygen/viewer/osudp.html
You can test how our new implementation works with the Naali 0.0.1
developer preview we packaged in June, a main reason exactly to get
feedback on how well the data transfer performs etc. Seems to work well.
Another native code implementation is funmv from 3di ('fun' for
functional) which is iirc in c, i don't know if/where that's available
nor much about it's usage (other than that it passes the packed data
around unparsed, and the whoever needs some data can read that section
from there, that being the func style).
Of course there is also the implementation in the Linden viewer if you
are fine with the GPL license they use, I don't know anything about that
except a guess based on rumours that it may not be very modular and
easily usable for other apps, I don't know any app besides the slviewer
and it's forks that uses that implementation.
The MXP reference implementation is also C#, there is no C++
implementation of it (yet).
send about is like: 'there's an object at this-and-that coordinate,
heading this-and-that way', with some metadata like type, etc. isn't
this what a virtual world environment would provide?
Yes. Like said I just thought you already had a protocol and existing
clients for it that you wanted to support.
SLUDP is not an optimal generic VW protocol, not made for extensibility
like google protocol buffers, but it works and there is a packet called
GenericMessage which can be used to pass arbitrary information. That is
what has been used in Realxtend so far to pass data which doesn't exist
in the plain original protocol, and which may work for your usage too
(for whatever metadata you need, and the trajectories etc).
Akos
~Toni
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] client API bindings?
On Sep 3, 2009, at 5:55 PM, Maróy Ákos wrote: region module loader for OpenSim once and probably you could use it to write a ClientView too if you prefer that to C#. But C# is also nice, kind of a mix of C++ and Python -- if those are what you know from actually it's not that simple. for example, X-Plane has a plugin architecture, that accepts plugins written in C++, or in Python. thust the best is if there's a client implementation in any of these languages, as one has to create a shared object a python files (without native libraries linked) to integrate to X-Plane. (oh, and the native ones in three platforms, Linux, MacOS and Windows) Hm, trying to get what you are saying exactly .. are you saying this is something that applies to both the server and clients? Where do you create the shared python objects? On either end, and then those are sent across and deserialized? I know how pickles work and how those can be used for sharing state, but am actually very surprised to hear that x-plane would use them in the protocol. I don't know basically anything about x-plane before. As you say 'without native libraries linked', perhaps ironpython and cpython are compatible, or can be made so, on that level .. am not sure exactly but we can find that out, if that indeed is the need .. i'm not sure I understood this correctly. Sounds that it may be really cool (pickles can be arbitary data and code .. which is also why they are often not used for security reasons, you must know what you are doing if you use them .. that might be a reason why linking to native libs is not allowed, dunno :o) also, if one wants a proliferation of clients, one has to allow for a wide range of client implementations. Well I thought that if you write an x-plane protocol implementation as an OpenSim plugin, a XplaneClientView or something, it would support any client that talks that protocol. Like the SL, MXP and IRC ClientViews do support any compatible clients. One problem is that due to the Second Life compatibility origins, the OpenSim worlds are partitioned in 256x256m regions, which run as yes, this is a problem indeed. moreover, in a flight simulator, the horizon spans quite far. also, you actually need different update levels - for objects that are close, one needs fast and accurate update, while for objects far but still visible, one doesn't need that frequent updates. For that it may not actually be much of a problem. As you can see in the viewers now, the horizon can span far. In ones that talk sl protocol the viewers can know about several regions at a time, so they can draw the neighbouring ones too, and they draw sky and sea etc. however they want of course. And there needs to be LOD (level of detail) systems for all usages, in many ways (for movement update detail amount, for 3d data resolution etc.). moreover, movement prediction is also important - the client needs to be able to predict the trajectory of the objects for smooth drawing, and graceful handling of network connection issues. Again, I thought that this was about a server implementation, as OpenSim is a server platform / SDK, and that you'd use existing Xplane clients. Or do you mean that the server also communicates expected trajectories, so the client can draw based on the 'future' info too? Should be doable, if it's done elsewhere too.. Client side movement interpolation is implemented in the current viewers, even in our Realxtend Naal which in very early stages still (0.0.1 dev preview was published in June after 4 months of dev work, 0.0.2 is targeted in october or so and something like 0.1 perhaps by the end of the year). So I don't know how much of that you need on the server with xplane, but certainly sounds like something that flight servers could do .. and again very cool if they do. A trick I've been thinking for supporting fast large movements is to change the scale: make your planes 1/100 the size, so the default region size is then 25,6km for the lilliput pilot in the plane :) A 10x10 hm, but what is the position precision then? is it precise enough? May be, could be tested .. I think they are floats, at least in our viewer, and floats are IIRC accurate near 1.0 .. hmhm well we can see, or someone wiser can tell, am too tired to do any math right now here. For example in MXP you don't have this kind of region stuff in the protocol at all - there you just have a thing called a bubble, which AFAIK is the sphere of perception for the viewer, and the server always tells the client about the things close to it. The client nor the this sounds a better approach - but one still needs to treat 'near' and 'far' objects differently (see above) Yes, both server and client need to be smart about that. Server to know what to send I guess, and client for what to draw (or what to request from server, when server can be dummier? Dunno, but there probably are solutions to this
Re: [Opensim-dev] client API bindings?
Maróy Ákos kirjoitti: space, and write client plugins for the simulators to connect (for example, using X-Plane as the flight simulator). For this, I need to integrate the client as a plugin to these applications, which is done using C / C++ or Python in the case of X-Plane, for example. Cool idea. In OpenSim they are called ClientViews.They implement a protocol which clients can use to connect to the server. The prominent one is for the SL(tm) viewer, but there is an experimental one for another new VW protocol called MXP, and at least an IRC one as well. Also for the Realxtend project there is a modified ClientView where the SL protocol is extended to support Ogre meshes etc. OpenSim is a .NET project, written in C#, so you can use any language that has a .net implementation for writing your thing. IronPython is a pretty cool and mature implementation, I wrote an experimental .py region module loader for OpenSim once and probably you could use it to write a ClientView too if you prefer that to C#. But C# is also nice, kind of a mix of C++ and Python -- if those are what you know from before, should be easy to learn. The API is the same for any .net language. As I'm new to OpenSim, it might be that the above scenario is not feasible at all :) It should be feasible in principle, and I think a quite interesting challenge for the platform. One problem is that due to the Second Life compatibility origins, the OpenSim worlds are partitioned in 256x256m regions, which run as separate instances. When you cross a region border, there is a handover procedure etc. So the default architecture is not at all suitable for flying 300m/s 'cause you'd need so many regions and it'd be doing the crossing procedure all the time. I think there's an on-going experiment with different sized / large regions, just today Teravus touched this thing it seems, that might serve you and I guess he can tell more - /OpenSim/Region/CoreModules/World/Land/RegionCombinerModule.cs A trick I've been thinking for supporting fast large movements is to change the scale: make your planes 1/100 the size, so the default region size is then 25,6km for the lilliput pilot in the plane :) A 10x10 region grid or something would already give quite nice amount of space, and grids can be much larger too. Then you could fly past the giant avatars there and they'd have fun seeing small model planes fly :o For example in MXP you don't have this kind of region stuff in the protocol at all - there you just have a thing called a bubble, which AFAIK is the sphere of perception for the viewer, and the server always tells the client about the things close to it. The client nor the protocol don't know anything about how the space is partitioned on the server(s). So in the MXP ClientView you can perhaps see an example how to adapt the OpenSim internal scene things to a different protocol. Akos ~Toni ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] custom scene data (Re: [Proposal] Separate SceneObjectGroup/Part into separate classes/interfaces)
Justin Clark-Casey kirjoitti: One issue we have is the Opensim scene object data model. For the viewer side, we designed and implemented an Entity-Component model in spring - Out of interest, have you thought about a Model-View-Controller approach to this problem? AFAIK not explicitly. It's possible though that the people who did the research in January (Tuomo Korva IIRC) considered it. Am not sure what exactly it would mean together with the model we have. One key thing in the E-C model is that it's all just data, no functionality. MVC-like issues may become current here now that work on GUI tools is approaching. For example in the little test object editing/placement widget I did on friday one thing I didn't implement yet is having the gui widget state update when the object being edited is simultaneosly changed by someone/something else on the server. The network connection and the GUI tool being kind of two controllers to the same data. In the current viewer code that'll work by the gui component also registering to scene events so it can handle updates from elsewhere to the object it's modifying. Personally, I think that we should support arbitrary data directly but I know other core developers have concerns about this (such as performance ones). This is probably a topic for debate. Obviously everyone wants and needs good performance too, hopefully both can be achieved acceptably with a good design. I think it would be fantastic if Realxtend could help lead the way on a SOG/SOP refactor in partnership with the other interested devs. The best thing would be to develop a roadmap in co-operation rather than wait for one to happen. The topic of SOG/SOP refactoring has been kicked Ok, thanks for the feedback. We haven't discussed this much here yet, and it's not urgent just yet - easily enough work still on the client side for now. We have a planning session next week, and will probably discuss before that whether something related to this should be prepared now or postponed yet another month or more. If anyone else is ready to have a go with some refactoring there, don't wait for us now - if we start something soonish I bet it will be with tests and planning, like you said a roadmap, and not immediately jumping to modify the current codebase. ~Toni around before in this mailing list - not just this time - but no-one has had the resources to go forward with it. I don't now about the interface registry, I'd rather see this minimal class be a base class from which more specific classes inherit and that handles the connections to Scene and the linking stuff. Seems more sensible to make this most used entity be fast, specific subclasses rather than registered interfaces. But... a subclass could offer that registration method if it needs to be that extensible.. So in our design the base Entity is so minimal that it doesn't have any data, just an identity with pointers to mostly minimal data components like Placeable for posrotscale, and larger data like Prim. No interfaces are used, but the extensibility is achieved by aggregation. Melanie ~Toni MW wrote: Both SceneObjectGroup and Part are growing beyond manageable sizes (with both of them over 3000 lines long), and are not very easy to change when trying to make custom classes bassed on them (as I think Sean found out recently during his attempts). Ideally I think we would all like to see the separate Group and Part architecture replaced with a architecture that was more like a Node based scenegraph , and had a hierarchy of SceneObjects. But I think we all know of the problems in doing that, and how much work is involved. So as a small step in (hopefully) that direction, I propose to start splitting those two classes up, and having something similar to the interface registry we use in various of parts of the architecture. (RegisterInterfacetype , RequestInterfacetype() ). So things like the methods for editing prims would move out into a separate class; for example ISceneObjectGroupEditing. And then when the scenegraph wants to call a editing method on a Group, it can call : Group.RequestInterfaceISceneObjectGroupEditing(); I believe that this will at least make the code more manageable and make those classes easier to customise. I also hope that it will make it easier to head towards a new combined architecture for prim handling. The draw back could be performance, as we will have the overhead of calling those methods to request the correct interfaces. Although we could do the same as we do in scene and have properties that can access the common interfaces. (eg. SceneObjectGroup.Editor) ___ Opensim-dev mailing list
[Opensim-dev] custom scene data (Re: [Proposal] Separate SceneObjectGroup/Part into separate classes/interfaces)
Melanie wrote on 18th July 2009: (am cc'ing rex-dev to inform the devs here who follow that but not opensim-dev, we talked about this in RL here yesterday, but propose that the discussion will be continued on opensim-dev) A clear and loud +1 on getting started on removing this SOG/SOP hierarchy thing. The basic node could be stripped down to position, rotation, scale, parent, children and a few more things, with the prim stuff being in it's own class like Inventory was already moved out. Has this been worked on already? We have now had a short two week research period at Realxtend, now that everyone returned from holidays, and next week we'll plan the work for coming autumn and the rest of the year. One issue we have is the Opensim scene object data model. For the viewer side, we designed and implemented an Entity-Component model in spring - this part of the design doc (written in February and implemented in Naali later) is http://wiki.realxtend.org/index.php/NG_Design_Document/Viewer_Architecture/Framework#Component_based_World_Object_design Instead of a base scenenode class, that model uses aggregation: an Entity is just an identity, which can refer to any components it wishes to use. One example is what you say above: position, rotation and scale -- those are currently implemented in Naali as the Placeable component. So any entity which wants to have those props can have that component, currently that is avatars and prims. But also e.g. the terrain and the water skybox are entities. Prim data we haven't splitted into many different components, but now there is a single component for that data: http://www.realxtend.org/doxygen/viewer/class_rex_logic_1_1_e_c___open_sim_prim.html The idea is that with that Entity-Component model we can have all kinds of data, like the Ogre material properties or whatever physics settings. Even that an application can define own custom components, which the uniform system could then store and transfer, and the application code could handle how it wants. These components are just passive data, no code. The question for Opensim developers is: would this kind of design be a good target in the SOG/SOP etc. refactoring? In coming Realxtend work there is increasing pressure for being able to easily extend the data there is about the objects in worlds. This is not for any specific application only, but specifically to allow all kinds of applications. In that sense it would seem to fit the Opensim goal well, being a generic platform for many apps and not only a SL impl. But for us it would also support the immediate specifics in Rex, like Ogre animation data etc. There is basically two places where we'd need the server to support arbitary data: 1. in networking and 2. for storing. Also of course it would have to be within the Opensim internals so that scenes with the data like that would still function, the actual running of the simulation like movements and physics etc. One option is that we make a module that implements an additional network connection to the client with another protocol that communicates the scene object data, with basics like movements remaining in SLUPD as they are. In this case the module could also use some own storage system for storing the data too. But in this case similar(?) basic information about objects would be in two places .. dunno if/how bad that would be, we'll have to examine this more I think. But if we could refactor the core Opensim scene to this design, and implement the core storage mechanism so that it'd support additional data (or even arbitary custom app specific data?), it would be just a matter of different ClientViews .. SL view communicating just the prim data as it currently does, and Rex view communicating Ogre and/or arbitary data in the E-C style, possibly using some other protocol like MXP and/or Google protocol buffers, or an own solution. We still have enough tasks to keep us busy easily for the next month or so without this, but need to get this ball rolling at some point -- possibly later in the autumn. This is basically just a heads-up to inform opensim devs about what we have in the client now, and what would need from the server, to get initial reactions and ideas about how it might be good to start with this. If there is a feasible roadmap towards this within Opensim, I imagine we would do the bulk of the work, of course appreciating all the help that could get. I'm a bit afraid of the SOG/SOP monster having heard about the difficulties in changing it, but I guess we'll have to see that as an argument *for* a refactor and not against it. At least Realxtend can not be stuck with the SL scene model forever. I don't now about the interface registry, I'd rather see this minimal class be a base class from which more specific classes inherit and that handles the connections to Scene and the linking stuff. Seems more sensible to make this
Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and OpenSim.Grid.AssetServer?
On Jul 8, 2009, at 7:51 PM, Sean Hennessee wrote: MW wrote: I also would rather a different name than BUST, and also before any How about BOSS? Basic Open Simulator Servers? nice acronym - perhaps too JBoss-y a name though, and it being also a server framework (the open source j2ee thing) is a little bit close. i don't mind BUST, but it's not a huge matter i think anyways. ~Sean ~Toni ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OGPX and IETF-ing things
On Jun 3, 2009, at 10:37 PM, Cristina Videira Lopes wrote: Personally, I think this is all premature. IETF-ing the Hypergrid is premature for different reasons than IETF-ing OGP is premature. The I think that depends on what is meant by IETF-ing. For proposing as a standard, you are most probably correct. But starting to discuss something within the IETF doesn't mean there's a ready proposal for a standard - perhaps just an idea of the need, a set of requirements and some early implementation. For example a working group can then discuss based on those. So if mr. Hamrick's proposal is about having the discussion on a different forum, one which is vendor neutral and independent of any specific implementations, I think it's worth considering. It kind of sounds sensible to focus on OpenSim specific development on this list.. And many of the points (quoted at the bottom) that you made in your post sounds like something that other people working with other implementations might be interested in. I do appreciate your point also that it doesn't seem attractive to participate in extra talks when what is needed is more experience and visible issues with the implementations, but just wanted to hilight that other point of view. The right thing to do, I think, is to first have implementations of both OGP and the Hypergrid2 in OpenSim. Once that is in place, we can all see the similarities and differences, and try to standardize the Sounds right to me in any case, no matter where the related discussions are to be held. Here am quoting some of your points that seemed to be of general interest.. that are substantially different. Things like posting/retrieving agents to/from regions, for example, we already converged to using REST; inventory access, we already converged to using capability URLs (...) authority: what component has authority to do what. In OGP regions are still the ones doing agent transfers, therefore implying a trust relation between interacting grids that must be established in some non-technical manner (i.e. the receiving region trusts that the sending region is not stealing the user's identity). In the Hypergrid, agent transfers between non-trusting regions are done on the client side, so that the identity of the user can always be verified, there is no region in the middle acting on behalf of anyone. Crista ~Toni ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Worlds.com CEO: We're 'Absolutely' Going To Sue Second Life
Sean Hennessee kirjoitti: without ever having heard of that what-.com-was-it-again and couldn't-caring-less about it (but having planned and written parts of a scalable mmorpg in '90 or so :) , and not clicking he links, one remark: licensing negotiations -- including giants such as Second Life and World of Warcraft, a property of Activision Blizzard (ATVI). I wonder if/how this will affect OpenSim. I assume we couldn't afford to defend a lawsuit. Would we just stop development if sued? Are we likely to be sued? AFAIK typically such guys are after easy money (which I guess he won't get in this case), and preferrably big money, and don't perceive open source projects as easy targets for that. We had a patent lawyer at the Blender conference once and that's what he told us iirc :) As he already names SL, WoW and such he'll get to fight in that league first and I at least will just continue in peace while they do that somewhere. Of course as Blender is GPL and no big corps are involved the case may be different with OpenSim, dunno. ~Sean ~Toni ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] presenting at a web3D meeting
daniel miller kirjoitti: sorry for the cross-post, but this is something I think all parties yah wasn't sure where to reply, but doesn't matter too much i guess :o should be aware of. I have been asked to give a short presentation plus QA on Opensim, Openviewer, and RealXtend (focus on Next Gen sounds great! plans). This is at a meeting of the Web3D consortium, the folks behind X3D (and now Collada). Here's a link to the meeting oh, so Collada moved from Chronos (where opengl still is, right?) to there? interesting. btw there is Collada export from Verse (was a sponsored request by certain 'collada guys' couple of years ago, Eskil made it and they talked about future stuff too), and Verse support in Cable Beach AFAIK (once it comes out with VerseSharp, right? and is using Axiom (a c# port of ogre) on the server side to read the .mesh data? JHurliman worked on that some weeks ago, http://opensimulator.org/wiki/AssetServerProposal/Verse) ~Toni announcement: http://www.web3d.org/events/details/web3d-consortium-members-meeting/ My talk is on the Emerging Web3D Applications. I think it's import to have dialogue among the disparate people working towards a 3D-enabled web. The goals and motivations may be different, but it's all going to intersect at some point. I would hate to see a tower of babel situation such as transpired in the audio/video world. Any thoughts would be appreciated. -danx0r --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups realxtend-architecture group. To post to this group, send email to realxtend-architect...@googlegroups.com To unsubscribe from this group, send email to realxtend-architecture+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/realxtend-architecture?hl=en -~--~~~~--~~--~--~--- ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] On solving Authentication and such
Toni Alatalo kirjoitti: sense, the experiments with MXP now are interesting (i started testing adding support to that to openviewer btw to learn more, dunno if will have time to complete that soon but we'll see). well now can login to mxp server with openviewer, just inject an avatar to the server but don't build the scene on the client side yet nor have any controls, but those are easy to add. hopefully get to continue in the evening again, will out somewhere then and see what's the proper place to talk (some ovdev list i guess). ~Toni ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] On solving Authentication and such
First, a big + the separation of concerns. Then some brief remarks and comments: Mike Mazur kirjoitti: This means that the server will provide one client stack implementing one protocol that deals only with 3D information. Avatar movement, scene description, agent updates, prim updates, etc. The viewer speaks this protocol in order to display to the user what is happening in the 3D world. This makes it possible to write a client that is only capable of viewing the world and doesn't care about inventory. The protocol could be, for example, the LLUDP protocol. That is BTW exactly the plan in the RexNG viewer effort now: implement a minimal set of LLUDP for the client to get the world, and leave out all the IM, social networking, commerce etc. related parts of the SL protocol, as the idea is to use other existing things for those (xmpp etc). And possibly switch away from LLUDP later if it seems to make sense, the experiments with MXP now are interesting (i started testing adding support to that to openviewer btw to learn more, dunno if will have time to complete that soon but we'll see). So I guess a part of the plan is to facilitate that on the server side too, AFAIK that part hasn't been examined more closely in Rex work yet (apart from doing modrex and hence getting experience with dealing with client views etc). But if the core etc. would be refactored as needed in Opensim in general to support using such a minimal set nicely I think it'd also benefit the Rex effort directly. The inherently 2D features, such as chat or inventory, can use another protocol. The server will provide a different client stack that deals only with the 2D feature(s). The viewer also implements this protocol to A remark on the concepts: There is nothing 'inherently 2d' about those. They are information that can be represented in many ways. Some GUI may use a 2d widget to show them, some other may feature 2,5d or 3d UIs to e.g. deal with inventory, and for e.g. blind people you can have chat and inventory as audio. provide these additional services to the user. This 2D information can then be overlaid over the 3D rendering of the world. This allows to Or some other client implementation may come up with interesting ways to integrate them to inworld. In fact the idea that the other GUIs would disappear, and the VW itself would be the interface for all services: e.g. google searches, making notes, planning an API, .. but not via putting rendered html pages as images to planes, but having the structures of the world itself be the information, services and tools -- that's what sometimes intriques me most as a long-term thing (and this is just my private thinking based on good experiences from earlier research systems, can point to them elsewhere if someone's interested). Back to short term concrete plans, with Rex the plan is exactly that - overlay traditional GUI things on top of the Ogre scene (like openviewer and idealist do too). But yes, I'd also think that such separation would make sense - especially because there are many possible and I'd bet yet unknown ways to mixmatch these different features. Like someone said, let's do components and let the world decide about the configurations. And indeed a specific client may be interested in a single feature, and doing that powerfully (e.g. inventory management). Mike ~Toni ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] MXPClient?
Charles Krinke kirjoitti:
How is the ModRex module? Is that what we need for the Rex client to
connect to OpenSim? I dont recall if it is functional or not.
yep that's what you need, afaik is functional (you can log in, see
meshes etc) but not complete in the sense that not all rexserver feats
have been ported from the trunk yet nor all probs solved (last i heard
Mikko and Adam were working on something related to multiple regions).
Are any of the ActiveWorlds, There.com others interesting? Croquet?
Wonderland?
I think AW might be fun, haven't looked at that in ages though (back
when it was 2d, heard they changed to 3d at some point).
Croquet is already being worked on IIRC, Adam said something about some
guys on some Croquet side coding something to help it first before work
progresses from his part or something?
Was also thinking of Darkstar, which is the tech used for Wonderland and
some other things - found that there is/was no real protocol spec
('cause there are the open source implementations anyone is free to use
i guess..), but (to help making actionscript clients i think) a couple
of months ago some specifications were written to the javadoc (by a dev
has written real protocol specs before) - there's on overview at
http://www.projectdarkstar.com/distributions/current/sgs-server/doc/overview-summary.html
and that recent wire protocol doc was added to
http://www.projectdarkstar.com/distributions/current/sgs-server/doc/com/sun/sgs/protocol/simple/SimpleSgsProtocol.html
Just last week I talked with a local games company that had done an MMO
using Darkstar, they were pretty happy with it (just used it out of the
box to make their game). I have no experience from it myself, just took
some look years ago and a little now.
I was also trying to find if the new Quake or Doom 3/4 protocol
specifications would be somewhere, but didn't find anything resembling
that really, so I guess implementing those would mean reading the
source. Well I found one student work from '98 that had sniffed Quake2
from the wire, and that has been made for many game protocols to be able
to write 'pirate' servers (like libsl opensim was made basically).
However classic game protocols are perhaps not so interesting 'cause
they only synch movement etc. and load the maps from the local HD at
level start. Or I guess we could convert e.g. Wright Plaza (from .oar?)
to a Quake map, put it somehow so that people / quake clients can
download it, then use Quake clients to connect to OpenSim with modquake
installed and run around WP shooting each other :o
Charles
~Toni
*From:* Frisby, Adam a...@deepthink.com.au
*To:* opensim-dev@lists.berlios.de opensim-dev@lists.berlios.de
*Sent:* Sunday, February 22, 2009 8:16:45 PM
*Subject:* Re: [Opensim-dev] MXPClient?
I'm open to ideas on other clients we could implement too btw.
Anything that has a well described protocol is up for grabs.
Adam
-Original Message-
From: opensim-dev-boun...@lists.berlios.de
mailto:opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
boun...@lists.berlios.de mailto:boun...@lists.berlios.de] On
Behalf Of Diva Canto
Sent: Sunday, 22 February 2009 7:55 PM
To: opensim-dev@lists.berlios.de mailto:opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] MXPClient?
Frisby, Adam wrote:
Melanie can probably elucidate a little as to why it's good for us to
have a couple of IClientAPI's in core - namely that it helps prevent
monoculture in naming schemas and flow.
+100 just for this.
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] what are the core region modules? which are not?
Stefan Andersson wrote: That said, I would also suggest we set up a forge build server - something that would synthesize, build and runt tests on an 'extended' build file - containing all non-core, but 'approved extended modules'. (...) Now, if an 'extension' module stops _functioning_ I believe that situation is exactly as it would be if it was included in core - the only thing having a module in core guarantees is that it's built, not that it is tested by the committer well if there are indeed tests for that functionality, they ought to be run by committers (and are run and reported by the server too), so that breaking things without knowing would not happen. i figure running tests of the non-core but living modules might work well if it can be setup somehow. one neat feature in svn is external repos that let you combine many repos into one so that you get them all with one update command. Melanie wrote: The extras directory won't fly because different modules need different references and even external stuff. I have a Linux build script I use that will combine selected modules with my tree. I can i wonder if you could help keeping such modules functioning by writing tests for the parts of the api that they depend on .. perhaps you can test what they assume from opensim without having the external stuff. versioning sounded like a good idea too, but don't know whether it's the time for that and would it be practical really. this is an issue for modrex too, where already the guys had to do some refactor now due to changes in the core. hopefully the situation can be helped with tests there for the future. Melanie ~Toni It would probably be a good thing if the module sub-projects would keep track of some kind of 'last known good' revision. And, lastly, I believe that by grouping several modules into one or a small number of 'packages' the impact of core deviation would lessen, as more devs would have to configure less to have it installed. By the way, I was thinking that we could have a in-place bogus project in Prebuild.xml called OpenSim.Modules.External residictng in /OpenSim/Modules/External, which prebuild would include /*.cs recursively. That would mean that you could just check out a set of forge module sources into that directory - which prebuild would then just bundle together into one big fat glorious module dll, custom to your environment. Best regards,Stefan AnderssonTribal Media AB Date: Mon, 9 Feb 2009 11:42:31 -0800From: c...@pacbell.netto: opensim-...@lists.berlios.desubject: Re: [Opensim-dev] what are the core region modules? which are not? SDague has a good point. And it gets a bit more interesting when one considers the OSSearch module, which did become non-functional a few days ago and folks have been scrambling and struggling to get their regions back in operation.It could be argued that bringing that active module, which is one small C# file into SVN might be to our advantage for the same reasons we are discussing here.Charles From: Sean Dague sda...@gmail.comTo: opensim-...@lists.berlios.desent: Monday, February 9, 2009 11:30:59 AMSubject: Re: [Opensim-dev] what are the core region modules? which are not?Dahlia Trimble wrote: When a module moves out of core and to forge, what process would be in place to make sure these modules remain compatible when possibly breaking changes are made to core? I use the IRC module in some of my regions and I wouldn't want to see it broken, and I like to stay close to head in all of my regions so I can be more aware of how development progresses. As such I would potentially vote -1 on taking IRC out of core until there is some way to maintain functionality as core evolves.I'm personally all for moving thinks to an Optional space, but we haveto be honest with ourselves, moving a module to the forge means thatthere is a better than 50% chance it's unusable in 2 weeks time. Ithink for things we've considered dead that's fine, but I'd bereluctant to push bits out that people do regularly use (like the ircbridge). At least until we have:1. an easy way to build an out of core module build tree2. network repository support for modules (ala what's in mono addins)3. some type of versioning on module interfaces, so we can know if aplugin thinks it can work with the current buildOtherwise we are more or less jetisoning a lot of features and reducingthe number of users that we can serve out of the box. The same logicthat would leave these modules in the tree is the same logic that keepsall the extra stuff in bin/, to make it easy for the new user to getstarted.This shouldn't stop this current level of reorganization, which I thinkis very useful. But is just a warning on next steps of removing thingsfrom the tree.-Sean-- Sean Dague / Neas badesda...@gmail.comhttp://dague.net
Re: [Opensim-dev] Technical assessment of Cable Beach asset server
Eugen Leitl kirjoitti: On Thu, Jan 15, 2009 at 02:10:13PM +0900, Mike Mazur wrote: As an aside from the peanut gallery, it would be nice to have asset storage in a distributed cryptographic filestore like Tahoe http://allmydata.org/~warner/pycon-tahoe.html that has been my understanding as well. basically after worked a bit with the guys who pushed it in the Fenfire project (in 2002). i've understood that basically by using URIs as references to assets we get that: URLs for current http stuff and location independent URNs with distributed things like p2p networks. seems that Tahoe also uses short URI-like strings - dunno why 'URI-like' and not just URIs but anyway :) .. also as SL and OpenSim already uses UUIDs i guess some things are basically kind of ready for this. http://www.ht03.org/papers/pdfs/24.pdf is about the work in that area i was interested back long ago, dunno about the current implementations whether Tapestry, that Tahoe or something I haven't heard of is the thing, but i guess the basic idea is the same. in that Fenfire Storm the idea was to use content based hashes as IDs of files (like images), similar to Freenode -- the goal not being anonymous publishing in a secure p2p net, but instead having a nice storage system for both local own files and publishing them on the net. goals included the secure storage via redundancy, that seems to be emphasized in Tahoe and is indeed a great motivation for these things. looking forward to learning more, perhaps by testing Tahoe ~Toni ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
