Open Source Portal Learning the System Ways to Participate Architecture Working Group Design Documents
[edit/talk]   Description: Dzonatas Sol/AWG Region Some space. It can have any form. It can be grouped together with other Regions. It is part of a Region Domain.

Brainstorming

• allow regions of arbitrary size and form
• allow portals and landmass-style connections between regions or a mix of both
• region should be able to decide which agents to let in depending on the grade of verification (age, RL identity, financial, ... )
• User defined topology. Like bookmarks, but in 2D. Crossing a custom boundary would result in a "walking teleport"
  • Extending these ideas more generally, see Comments on generality of geometries.
• Multiple instances of a region within a topology. Everyone can have a front row seat for the show.
• Allow as many avatars as will fit in the virtual space of a region. Don't limit the population of a region based on architectural limitations.
• Inactive land acreage and passive prims cost only the price of disk storage. Scripts cost the price of CPU power. Avatars cost the price of bandwidth. In the LL grid, these issues are all coupled together, but this will change in a distributed world.
• Beyond the confines of the Linden grid, land, prim, script and avatar limits should not have a-priori restrictions that are relevant only to the static Linden grid. In the distributed world, local resourcing will determine which limits and costs are appropriate. One fallout from this will be that inactive land acreage will cost next to nothing, since the price of storage is in freefall.

Implementation Thoughts

• if we have different region domains will each of them have their own map or would it somehow work to connect certain region domains together while it would still be possible to grow one domains space? Maybe a simplified map will show connected region domains, think of a tag cloud,with the current region+domain largest in the middle, around it the connected domains with only the crossing region(s) displayed.
• Can we see into neighboring regions using a low LOD mesh dynamically created to represent the land and objects in a region?
• Virtualize the regions. If no one is in or near a region, don't waste hardware on it. If a region gets too busy, dynamically split it onto two servers, each taking half of the area.
• Allow arbitrary assignment of geography to processing resources - including dynamic migration.
  • As someone who's developed 3D virtual world simulations before (and always wanted to create something like SL), the first thing that hit me when I entered SL for the first time was that sims were visible to residents (and scripts).
    • A sim is an implementation detail and residents should never need to know they exist. Making that particular initial implementation choice (to divide processing power into a regular grid and distribute it statically over separate servers) has now locked it in for the future - as removing the concept of regions would break a lot of scripted content.
    • However, it is still possible to lay a foundation that can deal with arbitrary assignment of geographic simulation to processing units (including dynamically) transparently and then add a 'backward-compatibility' layer over it which simulates the familiar square regions for legacy content (virtualizes them as suggested above).
    • Such a system could also be implemented to allow non-flat and non-contiguous geography (e.g. like planets, for example). Current continents could be mapped into small surface patches in a 'legacy' area.
    • It would also allow the possibility of distributing the various aspects of simulation of a geographic area differently - such a physics, collision, scripts, occlusion etc. (for example, if there are few physical objects over a large area, one processing unit could compute the physics for the whole area, while a larger number of processing units execute the area's scripts if required)
  • See Virtualization for a scheme that addresses this.