OpenSimulator:0.5 Release Target Discussion

From OpenSimulator

(Difference between revisions)
Jump to: navigation, search
 
(34 intermediate revisions by 17 users not shown)
Line 1: Line 1:
 +
{{Quicklinks}}
 
==Suggested Goals==
 
==Suggested Goals==
 +
== Bug Fixes ==
 +
 +
* Make prim unlinking work.  <b>Done</b>
 +
* Intra & inter region teleporting
 +
* Complete avatar customization
 +
* Complete connection of script editor to allow editing a prim directly
  
* ODE/ Physics
+
== Physics==
 
   
 
   
I respectfully and self-servedly recommend ODE support as a core feature of 0.5.
+
* Support for at least one physics engine with basic collision detection '''Done'''
  
Even though there are still legitimate questions about ODE's stability, it works well enough already to get ppl excited.  Most of the work for the core team will transport to any other physics plugin, ie bullet or physx.
+
* looks like hollow prims and some other simple shapes may be possible '''Done'''
  
If there is still a strong desire to completely redesign the physics interface, let's bite the bullet and do itA world without physics is like -- well, a world without photons!
+
* ODE is furthest along at this pointIssues include overall stability and lack of multithreading
  
* New Backend Protocol (OGS 2)
+
* BulletX is being worked on
  
* As part of the new protocol, give Commsmanager a big overhaul.
+
* New physics interface design? (event driven)
  
A lot of the functions currently in there need moving out. Like most of the Caps handling needs to be moved to the backend servers (possible with a dedicated Caps Manager server, like LL seem to have).  
+
==New Backend Protocol (OGS 2)==
 +
 
 +
<br/>
 +
 
 +
==Restructure and Normalize code==
 +
* We should follow 'one dir, one assembly'
 +
* We should follow 'dir == assembly == namespace'
 +
* OpenSim.Framework should not be OpenSim/Framework/General - the whole namespace needs normalization.
 +
* The OpenSimMain and RegionApplicationBase should be renamed (ConfigurableSimulator and SimulatorBase) and moved to a more suitable assembly.
 +
<br/>
 +
 
 +
== As part of the new protocol, overhaul the "commsmanager"==
 +
 
 +
*A lot of the functions currently in there, needs moving out. Like most of the Caps handling needs to be moved to the backend servers (possible with a dedicated Caps Manager server, like LL seem to have).  
 
   
 
   
Inventory handling etc should move to a module. As should Xfer uploads.
+
*Inventory handling should move to a module. As should Xfer uploads.
 +
 
 +
== Rewrite Asset Cache/Server==
 +
 
 +
<br/>
 +
 
 +
== Improve the management of client updates==
 +
 
 +
* Use a "interest list" for each connected client, so they only get updated about prims/objects that are in range (or they need to know about).
 +
 
 +
* Combine objects (parts) into single packets, rather than sending a separate packet for each prim as currently happens.
 +
 
 +
== Finish implementing the ll functions for scripting. ==
 +
 
 +
<br/>
 +
 
 +
== Improve UDP network code (ClientStack) ==
 +
 
 +
<br/>
 +
 
 +
== Clean up the IClientAPI interface ==
 +
 
 +
<br/>
 +
 
 +
== Start to think more about security ? (most likely will not happen until a later version)==
 +
 
 +
* Add security sinks in the "region to region" .Net remoting process.
 +
 
 +
* Check for security holes in scripting engine.
 +
 
 +
== Tighter integration of DataStore into the core ==
 +
 
 +
'''Suggestion''' : Code persistence logic code duplication in current OpenSim.Framework.Data.* could be avoided using ADO.NET base classes (DbCommand, DbConnection, DbDataAdapter... see System.Data.Common) in a common core for all existing database engine. A tiny library that is specific to a database engine could create typed version of these objects (createConnection, createCommand, createDataAdapter...). Theses "tiny library" would use the same interface (ie: DBEngine) and would have the responsibility to handle tricks as SQL syntax differences as TOP vs LIMIT, SQL Parameters naming, SQL specific types...
 +
<br/>
 +
 
 +
== Planet Mode ==
 +
One on the shortcomings of the grid model is that it is a "Flat Earth" approach. By doing little more modifying OpenSim to (optionally) connect the northern edge of the topmost region to the southern edge of the bottom region and a similar mod for the east and western edges and we have effectively brought together any group of contiguous regions within a grid and created a planet. If you keep walking/flying long enough you would eventually (or very quickly - the more sims the larger the planet) arrive back at your point of origin.
 +
 
 +
Try this - take a map of your sim and apply it as a texture to a sphere - see what I mean?
 +
 
 +
The analogy can also be extended further, a sandalone sim becomes a Planetary System Server, a grid server becomes Star System Server and a new level could be added to link Grids - The Galaxy Server but I am thinking the info DNS provides may already have that covered. 
 +
 
 +
I now invite the community to debate the concept further - are we a "Flat Earth" or a "Planetary System" with galactic potential?
 +
 
 +
Magi.
 +
 
 +
<br/>
 +
 
 +
Not to pick nits, but connecting N/S and E/W edges of a plane doesn't give you a sphere. It gives you a torus. The image we have here is a universe of doughnut shaped grids floating in space.... Mmmm donuts (it is still a pretty cool idea)
 +
 
 +
Lamont
 +
<br/>
 +
 
  
* Rewrite Asset Cache/Server.  
+
I think we need a section for suggestions to new features (Done, see [[Opensim: Future Release Discussion]]) and a section for what will be part of the next release.
 +
<br/>
 +
Tleiades
  
* Improve the management of client updates
 
  
Use "interest list" for each connected client, so they only get updated about prims/objects that are in range (or need to know about).  
+
Would like to see planet mode considered early in the project. This is essential for accurate representation of "real world" versus the "fantasy world" (but could also be used in fantasy world as well). One of the team members did some work looking at the healpix project as a possible solution. http://healpix.jpl.nasa.gov/ 
  
* Finish implementing the ll functions for scripting.
+
Nink
 +
<br/>
  
* Improve UDP network code (ClientStack)
 
  
* Clean up the IClientAPI interface
+
I have always wanted to see a grid where you could have regions not only to the north, south, east west of a region but also above and below. This would enable space above for orbiting space stations and the like and depth below for underwater worlds and tunnels.
  
* Start to think more about security ? (most likely really will wait till a later version)
+
Garth FairChang
 +
<br/>
  
Add security sinks in the region to region .Net remoting process.  
+
== Parcel Media Settings ==
 +
The multimedia functions in OpenSim create an awesome environment for presenting an enormous range of material. Whilst the parcel media settings can be set they do not persist between sessions.
  
Check for security wholes in scripting engine.
+
Magi.
  
* Integrate Datastore into the core more closely
+
<br/>
 +
[[Category:Development]]

Latest revision as of 18:29, 29 December 2010

Contents

[edit] Suggested Goals

[edit] Bug Fixes

  • Make prim unlinking work. Done
  • Intra & inter region teleporting
  • Complete avatar customization
  • Complete connection of script editor to allow editing a prim directly

[edit] Physics

  • Support for at least one physics engine with basic collision detection Done
  • looks like hollow prims and some other simple shapes may be possible Done
  • ODE is furthest along at this point. Issues include overall stability and lack of multithreading
  • BulletX is being worked on
  • New physics interface design? (event driven)

[edit] New Backend Protocol (OGS 2)


[edit] Restructure and Normalize code

  • We should follow 'one dir, one assembly'
  • We should follow 'dir == assembly == namespace'
  • OpenSim.Framework should not be OpenSim/Framework/General - the whole namespace needs normalization.
  • The OpenSimMain and RegionApplicationBase should be renamed (ConfigurableSimulator and SimulatorBase) and moved to a more suitable assembly.


[edit] As part of the new protocol, overhaul the "commsmanager"

  • A lot of the functions currently in there, needs moving out. Like most of the Caps handling needs to be moved to the backend servers (possible with a dedicated Caps Manager server, like LL seem to have).
  • Inventory handling should move to a module. As should Xfer uploads.

[edit] Rewrite Asset Cache/Server


[edit] Improve the management of client updates

  • Use a "interest list" for each connected client, so they only get updated about prims/objects that are in range (or they need to know about).
  • Combine objects (parts) into single packets, rather than sending a separate packet for each prim as currently happens.

[edit] Finish implementing the ll functions for scripting.


[edit] Improve UDP network code (ClientStack)


[edit] Clean up the IClientAPI interface


[edit] Start to think more about security ? (most likely will not happen until a later version)

  • Add security sinks in the "region to region" .Net remoting process.
  • Check for security holes in scripting engine.

[edit] Tighter integration of DataStore into the core

Suggestion : Code persistence logic code duplication in current OpenSim.Framework.Data.* could be avoided using ADO.NET base classes (DbCommand, DbConnection, DbDataAdapter... see System.Data.Common) in a common core for all existing database engine. A tiny library that is specific to a database engine could create typed version of these objects (createConnection, createCommand, createDataAdapter...). Theses "tiny library" would use the same interface (ie: DBEngine) and would have the responsibility to handle tricks as SQL syntax differences as TOP vs LIMIT, SQL Parameters naming, SQL specific types...

[edit] Planet Mode

One on the shortcomings of the grid model is that it is a "Flat Earth" approach. By doing little more modifying OpenSim to (optionally) connect the northern edge of the topmost region to the southern edge of the bottom region and a similar mod for the east and western edges and we have effectively brought together any group of contiguous regions within a grid and created a planet. If you keep walking/flying long enough you would eventually (or very quickly - the more sims the larger the planet) arrive back at your point of origin.

Try this - take a map of your sim and apply it as a texture to a sphere - see what I mean?

The analogy can also be extended further, a sandalone sim becomes a Planetary System Server, a grid server becomes Star System Server and a new level could be added to link Grids - The Galaxy Server but I am thinking the info DNS provides may already have that covered.

I now invite the community to debate the concept further - are we a "Flat Earth" or a "Planetary System" with galactic potential?

Magi.


Not to pick nits, but connecting N/S and E/W edges of a plane doesn't give you a sphere. It gives you a torus. The image we have here is a universe of doughnut shaped grids floating in space.... Mmmm donuts (it is still a pretty cool idea)

Lamont


I think we need a section for suggestions to new features (Done, see Opensim: Future Release Discussion) and a section for what will be part of the next release.
Tleiades


Would like to see planet mode considered early in the project. This is essential for accurate representation of "real world" versus the "fantasy world" (but could also be used in fantasy world as well). One of the team members did some work looking at the healpix project as a possible solution. http://healpix.jpl.nasa.gov/

Nink


I have always wanted to see a grid where you could have regions not only to the north, south, east west of a region but also above and below. This would enable space above for orbiting space stations and the like and depth below for underwater worlds and tunnels.

Garth FairChang

[edit] Parcel Media Settings

The multimedia functions in OpenSim create an awesome environment for presenting an enormous range of material. Whilst the parcel media settings can be set they do not persist between sessions.

Magi.


Personal tools
General
About This Wiki