[prev in list] [next in list] [prev in thread] [next in thread]
List: opensim-users
Subject: [Opensim-users] Region coordinate confusion (was Re: Tibetan Classroom OAR
From: karen_palen () yahoo ! com (Karen Palen)
Date: 2010-01-29 15:31:04
Message-ID: 420623.8718.qm () web63101 ! mail ! re1 ! yahoo ! com
[Download RAW message or body]
You are correct about the +-128 notation, I am used to that notation from some other \
software and I was the one confused. I apologize if that confusion has spread to \
others.
For the rest, you have outlined the theory of what should be the mapping between a \
megaregion and a "simple" region.
I have actually used Diva's workflow as intended and it works quite well.
However any graphical mapping is fraught with unexpected "special cases" which appear \
as bizarre results to the user.
Other than the specific scenario that Diva explored, transformations between \
megaregions and "simple" regions is still pretty much untested.
I have managed to cause database corruption by moving OAR files between "simple" \
regions and megaregions. Corruption bad enough to require rebuilding of the entire \
database!
I have not taken the time to explore and analyse the causes of these problems yet, \
but clearly great caution is required!
Bottom line: this feature needs testing, it should not (yet) be used for a system \
that has active users!
Karen
--- On Fri, 1/29/10, James Stallings II <james.stallings at gmail.com> wrote:
> From: James Stallings II <james.stallings at gmail.com>
> Subject: Re: [Opensim-users] Tibetan Classroom OAR
> To: opensim-users at lists.berlios.de
> Date: Friday, January 29, 2010, 6:45 AM
> Namaste :)
> Just to clear up any confusion about oar files - they
> are simple compressed xml representations of the
> regions' content and the assets required to reproduce
> them. The xml embeds object coordinates; the coordinates are
> taken directly from the objects.
>
> As a result, it is certainly possible to load
> oars of one size and configuration on opensim instances of a
> different size and configuration. Results are predictable
> but not necessarily desirable. Terrains may exhibit bizarre
> artifacting and objects may be 'off-world' ?if the
> oar size exceeds the target region size on any given
> axis.
>
> Which brings us to coordinates: there is no
> practical use of a notation like "+/-128" in this
> context. I've never seen it used before and it is
> clearly leading to some confusion in this instance.
>
> In opensim, region coordinates (the coordinates
> used to position regions on the grid), are in meters. Region
> cells (a subunit in opensim who's distinction is not
> meaningful in secondlife), are 256 meters on a side
> (identical to a canonical secondlife region). All objects in
> canonical region will have x/y coordinates that satisfy the
> condition '255>coordinate>0'. These may be
> combined into megaregions.
>
> When a megaregion is in use, all the objects on
> the megaregion will, under normal circumstances, be present
> in the root region's database tables. They will have x/y
> coordinates that satisfy the condition
> '(subregions_along_the_axis*255)>coordinate>0'.
>
> Diva Cantu has a workflow for merging simple
> regions and their contents into a single megaregion. I have
> not experienced success in my attempts with this workflow;
> this doesnt mean it is not effective; it means my attempts
> with it haven't been. That said, I'd suggest making
> backups at critical points in the process to avoid loss of
> content.
>
> I hope I have brought light into the shade with
> this post :)
>
> Cheers!James
> --
> ===================================
> http://osgrid.org http://simhost.com
>
> http://del.icio.us/SPQR
> http://twitter.com/jstallings2
> http://www.linkedin.com/pub/5/770/a49
>
>
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> Opensim-users mailing list
> Opensim-users at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-users
>
[prev in list] [next in list] [prev in thread] [next in thread]