Regions larger then 256x256

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Regions larger then 256x256

Teravus Ovares
Hey all,

I've been thinking about this supposed limitation of 256x256m sized
regions because of the recent discussion on integrating GIS data with
it and I wanted to discuss all of the known limitations, mitigating
factors, and potentially some solutions to dealing with this.

Now, from what I understand, the Linden client only really knows about
256x256.   However, also, so far, the only two things that I've found
that really make use of that limitation is terrain, and maptiles.
The terrain system is designed in such a way that it makes a region
have 256x256m split into 16x16 blocks and therefore there's only space
for that.     Map Blocks just assume 256x256.    Mind you, the client
also seems to use it for caching the terrain and objects as well, so
it really shouldn't change whatever it is or the client will have an
issue

Now, the kicker is object positions, avatar positions, textures,
border crossings and just about everything else *doesn't care about
256x256 on the client side*.    The rest of the 256x256 limitations
are in the service.

So, solutions..

Now, technically, it's possible to make a region 512x512 and have it
generate 4 maptiles and 3 'psudo regions' in the client stack..  the
psudo regions would simply be 'terrain senders' and 'terrain update'
mechanisms..   and that would work!

Any thoughts on this?

Best Regards

Teravus
_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Regions larger then 256x256

Stefan Andersson
Teravus,
 
you're revisiting our old, old, vision of having a many-to-many between scenes and regions, I think. (Where regions would be the IP endpoints, and the scene the graph)
 
If I understand you correctly, we would separate region from scene, letting the regions manage their bit of terrain, but having one region have a 'scene' that was 768x768, centered on the mid 'region'.
 
(Btw, can you terraform in a neighbour region? If not, a hacked setup might be a bit cumbersome to administrate)
 
So, the physics engine would communicate with the scene, but something would have to 'route' scene updates to the right scenepresence (avatar to the root, terrain to the right child).
 
And if it does, as all presences are 'root' presences today (as per an earlier post by Diva) I think that that would mean we are on our way towards a _true_ (as in 'not a one-off hack') many-to-many scene/region relationship.

Which I believe could seriously rock, eventually.

And yes, in the 'hack' version, you would have to disable the moving the avatar and objects between regions bit.

Best regards,
Stefan Andersson
Tribal Media AB



> Date: Mon, 26 Jan 2009 03:11:51 -0500
> From: [hidden email]
> To: [hidden email]
> Subject: [Opensim-dev] Regions larger then 256x256
>
> Hey all,
>
> I've been thinking about this supposed limitation of 256x256m sized
> regions because of the recent discussion on integrating GIS data with
> it and I wanted to discuss all of the known limitations, mitigating
> factors, and potentially some solutions to dealing with this.
>
> Now, from what I understand, the Linden client only really knows about
> 256x256. However, also, so far, the only two things that I've found
> that really make use of that limitation is terrain, and maptiles.
> The terrain system is designed in such a way that it makes a region
> have 256x256m split into 16x16 blocks and therefore there's only space
> for that. Map Blocks just assume 256x256. Mind you, the client
> also seems to use it for caching the terrain and objects as well, so
> it really shouldn't change whatever it is or the client will have an
> issue
>
> Now, the kicker is object positions, avatar positions, textures,
> border crossings and just about everything else *doesn't care about
> 256x256 on the client side*. The rest of the 256x256 limitations
> are in the service.
>
> So, solutions..
>
> Now, technically, it's possible to make a region 512x512 and have it
> generate 4 maptiles and 3 'psudo regions' in the client stack.. the
> psudo regions would simply be 'terrain senders' and 'terrain update'
> mechanisms.. and that would work!
>
> Any thoughts on this?
>
> Best Regards
>
> Teravus
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Regions larger then 256x256

Dahlia Trimble
In reply to this post by Teravus Ovares
anyone ever tried creating a larger region just to see what would happen?

On Mon, Jan 26, 2009 at 12:11 AM, Teravus Ovares <[hidden email]> wrote:
Hey all,

I've been thinking about this supposed limitation of 256x256m sized
regions because of the recent discussion on integrating GIS data with
it and I wanted to discuss all of the known limitations, mitigating
factors, and potentially some solutions to dealing with this.

Now, from what I understand, the Linden client only really knows about
256x256.   However, also, so far, the only two things that I've found
that really make use of that limitation is terrain, and maptiles.
The terrain system is designed in such a way that it makes a region
have 256x256m split into 16x16 blocks and therefore there's only space
for that.     Map Blocks just assume 256x256.    Mind you, the client
also seems to use it for caching the terrain and objects as well, so
it really shouldn't change whatever it is or the client will have an
issue

Now, the kicker is object positions, avatar positions, textures,
border crossings and just about everything else *doesn't care about
256x256 on the client side*.    The rest of the 256x256 limitations
are in the service.

So, solutions..

Now, technically, it's possible to make a region 512x512 and have it
generate 4 maptiles and 3 'psudo regions' in the client stack..  the
psudo regions would simply be 'terrain senders' and 'terrain update'
mechanisms..   and that would work!

Any thoughts on this?

Best Regards

Teravus
_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Regions larger then 256x256

Tommi Laukkanen
How about allowing global scale change which would affect everything else except terrain. If you would divide object scales by 10 you would have regions of size 2560x2560. This of couse would be grid wide setting and grids making hyper grid links should share the scale settings. Would this be feasible?

regards,
Tommi

_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Regions larger then 256x256

Ralf Haifisch
In reply to this post by Teravus Ovares
Heho,


Just to mention two points

Oar:
If i think about a region in size of 9x9 or 2560x2560 - how much memory
would it need and how long would it take ?
Can get very interesting...

Migration:
How to get from A (single 256m) to B (whatever it is), it maybe needs
coexistence.


Besides that, i would likely agree with Mircea.


Cheers,
Ralf
--
German opensim HowTo: http://www.ralf-haifisch.biz/Opensim%20HowTo.html
Cybertechnews blog: http://opensim.cybertechnews.org/


--
Date: Tue, 27 Jan 2009 15:28:04 +0200
From: Mircea Kitsune <[hidden email]>
Subject: Re: [Opensim-dev] Regions larger then 256x256
To: opensim-dev mailing list <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="iso-8859-2"


I did have another idea about simulator links which I wanted to post about
as well. I don't think region groups are that bad to create larger regions,
but the problem is the way they are individually managed. The thing I
personally have against making larger regions from 256x256 square groups is
that you can't make a larger island be treated as a whole.

Lets say you have a 3x3 square of 9 regions which you form a single island
with. First of all you need to have an .xml file under the Regions folder
for each simulator and manage every one individually which is harder then if
you had a single setting and .xml for all of them instead. Second, if you
need to move the entire island somewhere else that is very difficult because
you need to choose new coordinates for each region / part individually and
make sure they're in the same position from one another.

After that comes the problem of console region settings and importing /
exporting .oar and .xml archives. For changing any region you need to go in
the console and write "region MySimsName" to switch the tools to that
simulator. I'm not sure how that selection handles itself it two or more
regions have the same name (since if one had an entire area formed of many
simulators they'd put the same sim_name for each sim) but that tool needs to
know to act on the group as a whole, and a single terrain command should
adjust the terrain on the entire island while a save-oar and load-oar should
save or load the entire group.

So what I was thinking is if Opensim could be thought about region groups,
and know to treat many simulators which are touching each other as a whole
if asked to even if each sim technically remains a separate one. The first
thing it should know here is to be able to automatically position other
simulators to a certain offset from another one. For instance, I have a 2x2
group. From it I choose a master simulator and the other 3 are slave
simulators. Then each of the slaves could be set X units in a given
direction from that master sim rather then given individual grid
coordinates, so in case someone moves the main simulator of the group in
another spot on the grid the entire group moves which makes it easy to
relocate the entire island by choosing new coordinates for a single sim
only. Second, it needs to know to take region and terrain commands for the
entire group. Maybe this already works if many regions have the same name
set from the .xml-s though I don't know if that's
 safe yet. I'm not sure if all regions in the group should have the same
region UUID as well in this case (this is generally not recommended but if a
group is meant to be treated as a whole that group could have the same
region UUID then). What do you think?

_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live
Spaces. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&
mkt=en-us
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
https://lists.berlios.de/pipermail/opensim-dev/attachments/20090127/d7358f78
/attachment-0001.html

_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev
Loading...