[Opensim-dev] Ways to bundle a building/content for sharing with others

Sat Jan 10 21:31:31 UTC 2009

Absolutely amazing to read these ideas Stefan. Use of ViewPorts, as I am
imagining from your description, could indeed become the 'Save As' of the 3D
internet browser. I have an image of using something like the edit tool to
select objects in world, or from one's inventory, and select 'Save As' to
store them in one of many formats serialized on one's desktop system and
importable into other sims either by viewer function or server-side command.

On Sat, Jan 10, 2009 at 1:37 PM, Stefan Andersson <stefan at tribalmedia.se>wrote:

>  Actually, there are some interesting options with the approach we
> investigated with Tribal Net; The Tribal Net Desktop Server is an OpenSim
> instance that runs witha local gui. Now, one of the things that that
> approach would allow for, would be to 'browse' the sim for content - so
> saving part of a sim would be as easy as locating it in the scenegraph, then
> righ-click and choose 'save as...'
>
> Of course, the non-local approach would be to have a 'region service admin'
> console, something I think several people have been working on and thinking
> about, that would offer to do the same, probably over said REST interfaces.
> (ie, something would pull a region, or part of a region over REST, then just
> re-serialize it and allow for a save-to-disk)
>
> Of course, the same would go for inventory - a grid admin could be able to
> browse user inventories visually, and save nodes into an array of formats -
> one of them, obviously, the opensim default library node format. This is a
> feature much needed if we're going to clean up the library node like I
> suggested in the 2nd birthday post. It's also not that hard, actually. If
> one shuns desktop guis, one could definitively see the same function as part
> of a web admin tool, like the redux - or even in the built-in http servers
> on the regions. Given we already are serving quite a lot, that might not be
> difficult to implement.
>
> And on JSON; of course, object serialization format should be totally
> transparent. There should be xml, json and probably a number of others as
> well. (binary, llsd et c) There are some patterns around to create
> serialization factories to allow for various file formats for same objects.
>
> You might be interested in what we did with 'Tribal One' - there, we
> implemented a new type of scene object, the ViewPort that defined a part of
> region space, that had an 'Content Url' that loaded the ViewPorts content
> from an http fetch of a save-xml graph (this was before save-oar) Actually,
> since ViewPorts could contain ViewPorts, the whole region was a ViewPort, so
> the terrain was fetched as well, and child ViewPorts terrain was combined
> with parent terrain. This allows for 'fetching' of programatically
> constructed xml fragments, not necessarily originating from any object dump
> at all, but rather from applications serving renditions of data. That
> probably also tells us that we need _one_ save paradigm, and that we simply
> should be able to either incorporate fragments, or reference them.
>
> So your os function would be something like
> osCreateViewPort( v1, v2, url )
>
> There's nothing out there to show it, as we still haven't found any
> business case for it (too far out, perhaps, for the time being) but feel
> it's probably a concept well in line with the notion of the 3D web - moving
> fethcing of content off database accesses and onto http fetches. I believe
> Vast Park is based on the same premises.
>
> http://lbsa71.net/category/tribal-media/tribal-one/
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>
>
> ------------------------------
>
> Date: Sat, 10 Jan 2009 12:13:20 -0500
> From: imohax at gmail.com
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] Ways to bundle a building/content for sharing
> with others
>
>
> +1 Ai, we need a improved way to save reusable, complex content in singular
> files that can be passed between sims. Whatever results from such an effort
> will likely play nicely into REST transfer of such things between OpenSim
> grids.
>
> Up to now the methods you describe are the only methods and do not allow
> the casual OpenSim user any way to put such content into their inventory
> requiring, instead, sim administrator intervention. I think that will remain
> that way for some time to come because anything else requires some sort of
> viewer customization.
>
> I know others have created LSL scripts to transform XML from a notecard
> into an in-world object like some of the SL tools available for sale do. So
> far I know of none that actually use save-xml, xml2, oar output however.
>
> One approach I have been meaning to explore, but have lacked the time and
> skill, is creating an OpenSim module or special scripted function that would
> accept XML from xml, xml2 or oar as input, perhaps even directly from a
> notecard (but that could be a lot of dataserver hits) and automatically
> build out the represented object in world. In fact, there is already a
> suggested OSS function to do this from a URL pointing to such XML:
>
>
> osRezFromURL(string url, vector pos, vector vel, rotation rot, integer
> param)
>
> A whole family of osRezFrom*() functions would perhaps be best, each with
> different imposed lag penalties to avoid overloading XML sources. I cannot
> see such functions, with the parsing and possible network calls, ever being
> used to rez objects more than once every 0.2 seconds, the usual delay for
> similar things in LSL. Maybe something like the following:
>
> osRezFromXML(string xml, vector pos, vector vel, rotation rot, integer
> param)
> osRezFromXML2(string xml, vector pos, vector vel, rotation rot, integer
> param)
> osRezFromOAR(string oar, vector pos, vector vel, rotation rot, integer
> param)
>
> I admit I like rez from URL best in the long run since it takes care of the
> ugly issue of getting the XML/XML2/OAR into the string argument in the first
> place, too many dataserver calls to read such a thing from a notecard I
> would think. But before layering all the network fetching code having a
> function that simply does the parsing and rezzing would be work enough to
> write.
>
> On Sat, Jan 10, 2009 at 6:34 AM, Ai Austin <ai.ai.austin at googlemail.com>wrote:
>
> This might be a question for Justin as he has worked on the OAR
> mechanism and load/save-xml console commands....
>
> It would be useful to be able to take some content, such as  a
> building or developed area, and to be able top save that in a  form
> that can be downloaded or shared with others to get the same content
> in heir own opensim setup.  save-xml, save-xml2 preserve the whole of
> a sim region keeping creatorid, ownerid, lastownerid and prim uuids
> as they were, and save-oar pr serve the whole of the contents of a
> sim region including the terrain height map.
>
> The mechanism I have used to make a building available to different
> Opensim setups, or in different areas of our own build is to use one
> of two mechanisms...
>
> a) save-xml on a sim region that ONLY contains the required content
> (I use a sandbox region just for this purpose), and note how many
> prims were in the region as a check.. I edit the creatorid, ownerid
> and lastownerid manually (i.e. change UUID for 3 X number of prims).
> Then on restore I use the load-xml with -newuid flag to ensure new
> UUIDs are used for the newly loaded prims.  I then check the required
> number fo saved prims did come back in.
>
> b) save-oar on a sim region that ONLY contains the required content
> (I use a sandbox region just for this purpose).  load-oar into an
> empty sandbox region (as the terrain will change).  Then take the
> contents into inventory - with the disadvantage that relative
> positioning of parts is lost.  or link teh whole build and take into
> inventory to be moved where you wish with the disadvantage that major
> linked parts in a modular build are lost.
>
> As you can see, the save-xml and save-oar are VERY clise to what is
> needed, but are really for archiving within one Opensim set rather
> than transfer of modular assets to others.  I think a mechanism to
> save-oar with a  flag to say -noterrain, and/or a mechanism to
> load-oar -noterrain that can ignore any terrain included in the
> OAR  and a way to say -add so that the objects in te oar are added to
> the current region, rather than everything being replaced would be
> close to what is wanted.  A way to make sure that all UUIDs in the
> new content are suitable for the target environment (Prim UUID,
> texture UUIDs, creatorid, ownerid and lastownerdid) may be needed if
> the OAR mechanism does not already do that.
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
>
> --
> Mo Hax
> http://imohax.com
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>

-- 
Mo Hax
http://imohax.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090110/bae18969/attachment-0001.html>