OpenSimulator:0.5 Release Target Discussion
From OpenSimulator
| (32 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 | ||
| − | == | + | == 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) | ||
==New Backend Protocol (OGS 2)== | ==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/> | ||
| − | *A lot of the functions currently in there | + | == 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 | + | *Inventory handling should move to a module. As should Xfer uploads. |
== Rewrite Asset Cache/Server== | == Rewrite Asset Cache/Server== | ||
| − | + | <br/> | |
== Improve the management of client updates== | == 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 need to know about). | + | * 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. | * Combine objects (parts) into single packets, rather than sending a separate packet for each prim as currently happens. | ||
| Line 31: | Line 49: | ||
== Finish implementing the ll functions for scripting. == | == Finish implementing the ll functions for scripting. == | ||
| − | + | <br/> | |
== Improve UDP network code (ClientStack) == | == Improve UDP network code (ClientStack) == | ||
| − | + | <br/> | |
== Clean up the IClientAPI interface == | == 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/> | ||
| + | |||
| + | |||
| + | 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 | ||
| + | |||
| + | |||
| + | 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 | ||
| + | <br/> | ||
| + | |||
| − | + | 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 | |
| + | <br/> | ||
| − | + | == 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. | |
| − | + | <br/> | |
| + | [[Category:Development]] | ||
Latest revision as of 18:29, 29 December 2010
 |
Languages: |
|
[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.
