[Opensim-dev] Implemented oar merge facility

[Cristina Videira Lopes]

We need to do something new because of all the metadada associated  
with this kind of content, but we don't need to reinvent the wheel  
from scratch:

http://linuxcommand.org/man_pages/tar1.html

There's more options in tar than one would care to implement here, but  
they are certainly a good starting point. The main difference is that  
files don't have a whole lot of metadata, therefore tar is relatively  
light in terms of filters. But it does have the --exclude=PATTERN  
which is very rich.


On Nov 27, 2009, at 4:49 AM, Len Brown wrote:

> I totally get the z1 to z2 approach.  I had a situation a while back  
> where I'd been doing a lot of experimental building up around 3,000  
> to 4,000 meters and had kind of forgotten about that stuff up there  
> and focused on some ground-level builds.  Well, when I made an OAR I  
> thought it was a bit big and then remembered the 5,000 or so prims  
> I'd "abandoned" up above.  If I could have just backed up a certain  
> elevation section then I could have backed up the stuff on the  
> ground and left the other stuff up above out of the backup.  Would  
> make for a much cleaner and consistent restoration in a new region  
> later.
>
> So definitely +1 to the idea of backing up based on Z coords, if  
> that is at all a possibility for future consideration...
>
> - Len W. Brown
>      lenwbrown at gmail.com
>
> On Fri, Nov 27, 2009 at 5:47 AM, Zonja Capalini <zonja.capalini at gmail.com 
> > wrote:
> A cool use case that comes to my mind immediately (but I don't know  
> whether it's easy or not :-)) is
> the relocation of airboxes. I remember having to relocate a 10000+  
> prims airboxed city in SL,
> and it was a real pita. Moving all objects manually was out question  
> because it would have been
> too time consuming, and mass-selecting 10000 prims is buggy, to say  
> the least -- additionally,
> the viewers are very stupid in that respect, because mass selection  
> does not select Linden
> plants and trees. I ended up by mass-selecting anyway, then manually  
> moving up the
> airboxed city (which caused of course incredible lag), and then a  
> lot of smaller objects
> had escaped the selection and had to be moved manually, etc.
>
> It would be great if the load/save oar pair would allow for the  
> following:
>
> 1) Saving everything in a sim between z1 and z2 meters (effectively  
> storing one aixbox
> level only), and
>
> 2) Load the previous oar with an offset of z3 (i.e., all objects  
> would get their previous
> z plus z3, which could be positive or negative).
>
> As I mentioned previously, I don't know if this falls under the  
> "easy" case category or not :-)
>
> Indeed, once one starts to think in the direction of saving anything  
> less than a whole
> sim, the relocation problem appears immediately. What if I save a  
> building in a partial
> oar but I want to have it load-merged in a different position? Of  
> course this can also
> be done with linksets, but large linksets tend to be unmanageable --  
> or with coalesced
> objects, but the same problem applies, and besides they are not  
> currently implemented
> by Opensim. I think partial oars can fill a hole here, but at the  
> price of implementing
> relocation in the load-merge operation (and possibly some form of z- 
> rotation too).
>
>   /Zonja
>
> On Thu, Nov 26, 2009 at 9:12 PM, Justin Clark-Casey <jjustincc at googlemail.com 
> > wrote:
>
>  Cool easy things with real world use cases get highest  
> priority :).  And of
> course it's all dependent on what time I have available :)
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20091127/0bc68c96/attachment-0001.html>