Regions larger then 256x256

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

Regions larger then 256x256

Americo Damasceno-2
  Like there are the problem of performance when we have more than 15/20 avatares inside one sim , I believe that is important to have regions smaller than 256x256. By example, a "mini-region" having  32x32. Using grid and a server for each of 64 glued mini-regions we can have a superpopulated area of 256x256   running well.
 
Americo


check out the rest of the Windows Live™. More than mail–Windows Live™ goes way beyond your inbox. More than messages
_______________________________________________
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
Again, that could be accomplished by having a 3x3 region matrix, where all three put 'their' objects onto the central region.
 
This of course means that they all need to share that regions state, to be able to do physics for it.

Another concept that we've toyed with in the past is to let a region place a scenepresence in another region to be informed of what's going on there; this could be one way of doing it.

Best regards,
Stefan Andersson
Tribal Media AB



From: [hidden email]
To: [hidden email]
Date: Mon, 26 Jan 2009 07:46:04 -0300
Subject: [Opensim-dev] Regions larger then 256x256

  Like there are the problem of performance when we have more than 15/20 avatares inside one sim , I believe that is important to have regions smaller than 256x256. By example, a "mini-region" having  32x32. Using grid and a server for each of 64 glued mini-regions we can have a superpopulated area of 256x256   running well.
 
Americo




check out the rest of the Windows Live™. More than mail–Windows Live™ goes way beyond your inbox. More than messages

_______________________________________________
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

Mircea Kitsune
In reply to this post by Americo Damasceno-2
I too had this wish for Opensim, but gave up on it understanding it would be too difficult to implement and would hold too many issues. Sure, region *x* arrangements are possible and commonly used, but it does cause more complexity that way and moving all of them together or tweaking each individually could be a bit harder.

My idea back then was being allowed to create regions in powers of 2 (eg: 256x256 as now, then 128x128 smaller or larger 512x512). First thing which wouldn't work here however would be positioning them correctly over certain X and Y coordinates in order to fit smaller sims around larger ones, which would end up causing grid coordinates such as 1000.5, 1001.25. Second, I don't think the client actually supports simulators larger then 256 x 256 so the client would probably need modifying as well to do that. Third, exporting and importing settings and stuff (such as terrain or .oar archives) between different sizes of simulators could be problematic and buggy. And fourth, larger single sims could possibly cause performance issues even with computers in our days.

If some of these issues didn't exist though this might be doable and could be fun. Anyway the best practical way at the moment are region groups of 2x2 or 3x3 or how many you wish for having a larger square, which isn't that bad in the end.


From: [hidden email]
To: [hidden email]
Date: Mon, 26 Jan 2009 07:46:04 -0300
Subject: [Opensim-dev] Regions larger then 256x256

  Like there are the problem of performance when we have more than 15/20 avatares inside one sim , I believe that is important to have regions smaller than 256x256. By example, a "mini-region" having  32x32. Using grid and a server for each of 64 glued mini-regions we can have a superpopulated area of 256x256   running well.
 
Americo


check out the rest of the Windows Live™. More than mail–Windows Live™ goes way beyond your inbox. More than messages

Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it!
_______________________________________________
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

Cristina Videira Lopes
It should be possible to have regions larger than 256, at least in
multiples of 256. The LL client assumes that as the size, and that is
hardocded all over the place (regionhandles etc), so if we continue to
use this client we need to live with that;  but I strongly suspect it is
possible to trick it, to some extent.

Mircea Kitsune wrote:

> I too had this wish for Opensim, but gave up on it understanding it
> would be too difficult to implement and would hold too many issues.
> Sure, region *x* arrangements are possible and commonly used, but it
> does cause more complexity that way and moving all of them together or
> tweaking each individually could be a bit harder.
>
> My idea back then was being allowed to create regions in powers of 2
> (eg: 256x256 as now, then 128x128 smaller or larger 512x512). First
> thing which wouldn't work here however would be positioning them
> correctly over certain X and Y coordinates in order to fit smaller
> sims around larger ones, which would end up causing grid coordinates
> such as 1000.5, 1001.25. Second, I don't think the client actually
> supports simulators larger then 256 x 256 so the client would probably
> need modifying as well to do that. Third, exporting and importing
> settings and stuff (such as terrain or .oar archives) between
> different sizes of simulators could be problematic and buggy. And
> fourth, larger single sims could possibly cause performance issues
> even with computers in our days.
>
> If some of these issues didn't exist though this might be doable and
> could be fun. Anyway the best practical way at the moment are region
> groups of 2x2 or 3x3 or how many you wish for having a larger square,
> which isn't that bad in the end.
>
> ------------------------------------------------------------------------
> From: [hidden email]
> To: [hidden email]
> Date: Mon, 26 Jan 2009 07:46:04 -0300
> Subject: [Opensim-dev] Regions larger then 256x256
>
>   Like there are the problem of performance when we have more than
> 15/20 avatares inside one sim , I believe that is important to have
> regions smaller than 256x256. By example, a "mini-region" having  
> 32x32. Using grid and a server for each of 64 glued mini-regions we
> can have a superpopulated area of 256x256   running well.
>  
> Americo
>
> ------------------------------------------------------------------------
> check out the rest of the Windows Live™. More than mail–Windows Live™
> goes way beyond your inbox. More than messages
> <http://www.microsoft.com/windows/windowslive/>
> ------------------------------------------------------------------------
> Invite your mail contacts to join your friends list with Windows Live
> Spaces. It's easy! Try it!
> <http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

mw-2
I think with a bit of trickery its also possible to have multiple region servers managing a 256X256 area. As apart from terrain, a region can tell a client that objects are outside its own 256X256 area.

So if you had 9 regions set up in a 3X3 array. With the centre 256x256 area being where everything actually would be. Then each of those region servers could manage a 85X85 area (numbers rounded down) of that centre area.

As I said terrain would be a problem, so the centre server would have to send all the terrain data for that 256X256 area, while the others would maybe send data to show their terrain was under water.

But for the prims and avatars in each area, each server would just need to be configured to manage a 85X85 area. And then when it is sending data to the client, just offset the data so that the client got the correct positions in that 256X256 centre area.

I also don't think border crossings would require too much extra work, if the region server had been set up to consider its region as 85X85, it would just do a normal transfer to the next region when a avatar moved outside that area. Again some converting of position data would be required in that process but I don't think it would be too much.

So while it would take some work to get opensim to be able to run like this, I don't think it would be a great amount.

Cristina Videira Lopes <[hidden email]> wrote:
It should be possible to have regions larger than 256, at least in
multiples of 256. The LL client assumes that as the size, and that is
hardocded all over the place (regionhandles etc), so if we continue to
use this client we need to live with that; but I strongly suspect it is
possible to trick it, to some extent.

Mircea Kitsune wrote:

> I too had this wish for Opensim, but gave up on it understanding it
> would be too difficult to implement and would hold too many issues.
> Sure, region *x* arrangements are possible and commonly used, but it
> does cause more complexity that way and moving all of them together or
> tweaking each individually could be a bit harder.
>
> My idea back then was being allowed to create regions in powers of 2
> (eg: 256x256 as now, then 128x128 smaller or larger 512x512). First
> thing which wouldn't work here however would be positioning them
> correctly over certain X and Y coordinates in order to fit smaller
> sims around larger ones, which would end up causing grid coordinates
> such as 1000.5, 1001.25. Second, I don't think the client actually
> supports simulators larger then 256 x 256 so the client would probably
> need modifying as well to do that. Third, exporting and importing
> settings and stuff (such as terrain or .oar archives) between
> different sizes of simulators could be problematic and buggy. And
> fourth, larger single sims could possibly cause performance issues
> even with computers in our days.
>
> If some of these issues didn't exist though this might be doable and
> could be fun. Anyway the best practical way at the moment are region
> groups of 2x2 or 3x3 or how many you wish for having a larger square,
> which isn't that bad in the end.
>
> ------------------------------------------------------------------------
> From: [hidden email]
> To: [hidden email]
> Date: Mon, 26 Jan 2009 07:46:04 -0300
> Subject: [Opensim-dev] Regions larger then 256x256
>
> Like there are the problem of performance when we have more than
> 15/20 avatares inside one sim , I believe that is important to have
> regions smaller than 256x256. By example, a "mini-region" having
> 32x32. Using grid and a server for each of 64 glued mini-regions we
> can have a superpopulated area of 256x256 running well.
>
> Americo
>
> ------------------------------------------------------------------------
> check out the rest of the Windows Live™. More than mail–Windows Live™
> goes way beyond your inbox. More than messages
>
> ------------------------------------------------------------------------
> Invite your mail contacts to join your friends list with Windows Live
> Spaces. It's easy! Try it!
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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


_______________________________________________
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

Mircea Kitsune
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! Try it!
_______________________________________________
Opensim-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-dev
Loading...