OpenSimulator - User contributions [en]

OpenSimulator:Future Release Discussion

2014-06-10T10:26:58Z

LaeMing: Some additional ideas on 3D security.

{{proposal}}
A collection of ideas for additional functionality in OpenSim. Please add your thoughts - anyone may contribute.

== 3D grid structure ==
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

I like the idea of a 3D Grid structure, along with that, the ability to turn off gravity, water and the terrain textures. It would be nice to set the region's background image to a starscape or something other than the default background.

User defined gravity fields. This would be useful in a grid environment that was space themed, certain areas could have defined gravity fields. The possibilities for this could be very interesting.

== 3D Security ==

At the end of the day, this technology is a new form of computer user interface, and mobile agent application server. We need to move away from the concept of land, in a 3D environment we could assign access rights to 3D volumes, call them security regions. These security regions would have permissions granted by access lists, ability to assign different rights to different users or groups. (if we did 3D grid structures this would be a must)

One security feature, is the ability to "hide" objects within a security region from users that don't have access rights. Much like barriers in SL, these 3D security regions would just not show up in the viewer, and the user would not have rights to enter the area. It would interesting if you could do this on a primative level, an object that is only viewable by people/objects with the proper permissions. (The engine could detect collision based on bounding box)

LaeMing adds:

An alternative might be to add volume-based permissions to prims themselves, so - for example - you could define a transparent phantom prim, and anything spacially within this prim is subject to its security settings (can enter space, can see/interact-with contents, etc.). This would allow arbitrary sized/shaped security regions (I often would like to use cylindrical/spherical security zones, given the chance!).

== Portal Primatives ==

I propose a "hyperlink" prim that would be configured with an URL to a destination region/grid. The prim would be like a phantom prim, and when looked at, the user would see the destination, a doorway, like a region boundry, when the avatar passes through the object, the avatar is handed off to the destination region. This would be very cool feature, a user/company could "rent" space on a popular grid a store front, in the back of the store is a "doorway" to the user/company's private region/grid server.

(Croquet is an excellent referral to this concept, since the developers devised Portal "primitives" that allow travel not only between different worlds, but to your own one aswell. Also, once your in your own world, you can create yet another Portal to a new world that you created and so on.) -Darakon Kayvon

== Governance System ==
The online world would have to provide a means for communities to develop legal and political systems of governance. I can think of voting systems as a start.

== Scripting ==
See the list of [[OSSL Proposals]].

== Payment System ==
OpenSim will need to support micropayment. See [[Money]] for details on how this could be achieved.

== Free-form Avatars ==
OpenSim should, at some point in time, support the design and animation of free-form avatars (e.g. animals, monsters, robots).

== In-World console maintenance ==
Terrain manipulations, statistics and some SIM administration related tasks are not available using the Viewer - they are only available on the command line application console where OpenSim is running. It would be nice to have this same console available in-world, using an Instant Messaging window with the simulator itself, the same way as we do with thoses old command line terminals.

== Externally Scripted Objects ==
A prim with the script contents something along the line of //external:somehost:someport.
Have the simulator connect to this host:port and relay data from it to the prim.
Example, have a simple library that maps the LSL functions to a simple binary protocol, which can be used from various programming languages, not neccessarily .NET, and have it act like a server.
This would allow scripts to be hosted outside the Simulator while adding security, as no code would be running on the Simulator. People could code Prim scripts using C if they wished, and the library would simply send the LSL commands to the server for relaying to the clients. If this could go straight to the client then even better. The next step after that would be for the script to be able to send Prim data aswell.
This also gives the possibility of using one running script on several different Simulators at once.
- HashBox

==Object Inventory Source Control==
* This wish list feature starts with the premise that "I HATE working on scripting and objects within SL". Basically, allow users to checkout an object and its contents to an SVN repository. Work on the object and contents locally in whatever application they wish. Later, they can checkin the changes, and update the object inside the simulator.
* [http://www.softec.st/en/OpenSource/ClrProjects/SubversionSharp/SubversionSharp.html SubversionSharp]

==The ability to set region bounderies==

Useful in adding a max ceiling to a region. If it was possible, ability to create a "region box" with as stated earlier, an arbitrary origin. Thinking a little further, a "region sphere" would be interesting.

==Universal Location Addressing==

As part of grid to grid travel, a common standard for a universal location address / coordinate will need to be defined and supported.

Proposal: opensim://sim.grid.domain.tld:x.y.z/named_location/?param=value (alternatively, could be osa:// or osl://, or sim://).

Examples of use:
* opensim://sim25.mygrid.mycompany.mycountry/
* opensim://shoppingcenter.gridprovider.mycountry/myshop/
* opensim://mysim.mygrid.mycompany.mycountry:100.75.80/
* opensim://closedgrid.myworld.business/entrance_hall/?userid=xxx&password=yyy

To avoid confusion, Opensim TLDs will need to be different from existing Internet TLDs.
A naming registrar (NIC) will need to be established that ensures uniqueness and proper handling of registrations. - Ezekiel

Proposal: <sim|grid>://<FQDN>[[:<[zonename,]x,y,z>] | [/<symbolic destination>]]

Examples:
* sim://www.mydomain.com
* sim://www.mydomain.com:0,0,0
* sim://www.mydomain.com/mycoolplace
* grid://www.mydomain.com
* grid://www.mydomain.com/mycoolplace
* grid://www.mydomain.com:Zone1,0,0,0

The client can then get the required information regarding port numbers, protocols, and so on from SVR records embedded in the FQDN DNS Zone. This way clients are immune to changes in the physical hosting of the simulators. The data encoded in the SVR record could also give clues as to the protocol versions, abilities and restrictions of the destination. -Kelannim

==Scriptable 'bodyparts' (Shape, Hair, Eyes etc)==

This relates to Shapes, Hair, Eyes etc which are not prims but 'bodyparts', and are not manipulatable via LSL.

Two script commands could be implemented, one to write say a vector to 'bodypart' parameters (the numbers one edits in 'Appearance...'), and another to read them. It would be interesting to be able to create 'bodyparts' from scripts, using data derived externally or calculated in a script, perhaps from other 'bodyparts' data....

Further, with an extension to the permission system (notifying user that a script wants to modify a Shape/Hair/Eyes/whatever of theirs), perhaps editing of existing 'bodypart's could also be available.

==Tide Server==

It might be interesting to support tides in OGS. It should be doable without any mods to the SL client and probably wouldn't be even a big project (possibly a good teeth-cutting project for someone who wants to get into OGS server coding but isn't confident to tackle parts of a big or critical server component).

A few things to consider:

* The tide server just periodically updates the water level in a grid's sims.
* Would need to be grid-wide or dis-synchronised tides would have ocean-edge alignment issues (so no rolling tides across huge grids, sorry) so it would be a server operating at the grid level talking to regions.
* Needs to be over-ridable as inland regions often use water level for things other than ocean and wouldn't want to follow the tides.
* By using plug-in servers, different complexities of tide can be implemented depending on grid needs.

===Some example tide servers===

* Null tide - simply a way to globally set sea-level in a grid. Takes a single sea-level value.
* Simple Periodic - set the max, min and period and starting time values and let it roll.
* Sun (and moon) locked - uses the position of the sun/moon to place tides realistically (presently rather easy as the sun and moon are always 180deg apart, but they might get unlocked from eachother later, extra suns/moons might also crop up long-term - presently it would be the same as Simple Periodic, but time-synced with whatever the day cycle is). Can day-cycles be enforced (or at least a default set) region-wide? Otherwise this would not be feasible.

===SL Client compatibility===

When the client sends a water-level request to the region, the region does one of two things:

* if the water level is -32768 (assuming this value is stored as signed32) or 65535 (if it is a u32) or whatever represents the most 'insane' value possible, then the region refers back upstream to the grid tide server, gets the present tide level, and returns that (sane) value to the client.
* if waterlevel set for the region is in the 'sane' range, that (region-local) value is returned without referring to the tide server.

(A region-server console command to set the water level outside what the current SL viewer allows is assumed).

===Updating the tides.===

(I assume the region is capable of informing attached clients when water level changes so that on-the-fly changes by region admins are reflected reasonably immediately in clients already).

* tide server periodically multicasts a tide update signal to all regions.
* if the region water level is in the 'insane' setting, it passes the update on to the attached (and neighbour-attached) clients.
* if the region water level is 'sane' it does nothing, leaving the region-manager's water-level alone.

==Client Side Weather System==
A client side based weather system would be a breath of fresh air to those who enjoy more realism (Graphically). An overall Grid Weather System could also be created, so that different parts of the grid will be experiencing different forms of weather e.g 4+ Regions more to the north of the Grid would be in the midst of a blizzard whilst several sims further to the south are enjoying clear blue skys, but with an onset of rain on the way.
A Server could be set up in order to simulate the overall GWS (Grid Weather System) and would shout to each region to simulate a specified weather type.
All the Client has to do is pick up on the Information being sent to the region from the GWS and simulate it on-screen for it's users.
Obviously this feature can be turned on and off at will, but it would be nice to not have to set up a particle weather system that cause's more lag than necessary. - Darakon Kayvon
<math>Insert formula here</math>

==Strong Identities==

Basically objects and users would have strong identities created using public key cryptography. A creator or user would create a public/private key pair and register it with a key server, along with a signed hash of their character name/UUID/whatever. This creates a strong identity associated with the user.

This creator key could be used to generate certificates associated with their objects (signing the UUID and a hash of the geometry of the object along with their key identity) and register along with the geometry hash in a database. They could also create 'ownership' certificates which would be a signature against a player's identity and the object hash.

One of the uses of this is to allow a sort of voluntary property enforcement. The way it would work is that when an object is transferred using an intergrid (HyperGrid) connection, the transferor would also send any certificates associated with the object. These certificates, if the receiving server wishes, could communicate ownership or copy/mod/no-transfer rights based on the certificate and checking against the public key servers and object registries; it may also simply communicate a sort of certificate status to the other clients such that it could be verified that these objects are indeed created or authorized copies owned by the client. This would of course be completely voluntary within the grid, but it could allow commercial grids to manage intergrid object moves strictly if they want to. It could also exist simply to increase the 'cachet of ownership' such that you can show that you indeed purchase this from the creator.

Some notes:
* It would be trivially easy for malicious clients to modify the object slightly in order to generate a new hash and register it with the object server. The point boils down to really more supporting the social movement of supporting artists you like and being able to show thus. Artists could publish their object UUIDs along with their owners so that they could be reverified orthogonally.
* It would be trivially easy for malicious clients to submit erroneous hashes for objects. This could be solved by transferring the object parameters (all of the prims, locations, and parameters, the object description) to the object registry and having it do the hashing.
* The creator keypair could be used for intergrid authentication also. Since it is a proper strong encryption keypair which is tightly associated to an avatar identity it could allow authenticated intergrid connections. It could also be used to encipher the communication between the client and the grid and authenticate messages back and forth.
* Strong identities for objects could include a keypair which allows real-world integration such as bank transactions and whatnot to have a physical metaphor.
* The point of the object certificates really isn't DRM (although in a limited sense it can be used for thus), but (partially) a way to show other players that an object was payed for and is original, that you willingly supported a creator voluntarily with your patronage.

--[[User:NickRusnov|NickRusnov]] 21:45, 28 November 2008 (UTC)

==Extend the form of the Sphere to a Superquadric Ellipsoid + Geodesic==

On the end of present sphere data definition add the fields...
*'''Sharpness''' - default to zero, meaning a regular sphere/ovoid and the sphere rendering path is to be used as per usual client-side (and the 'sides' field ignored).
*'''Sides''' - can be set to any valid geodesic shape (client-side renderer can clip this value if too high). Negative value indicates to use the geodesic's dual.

Client-side (eg HipoViewer) would then need to be altered to allow editing and rendering of these shapes. (Detecting full sharpness and full roundness and passing these to appropriate optimised renderers for these shapes likely a good idea).

Adding same values to the end of the Cylinder shape to make an extruded Superellipse would be nice too (and with full sharpness, arbitrary regular shape extrusions such as pentagonal/hexagonal/octagonal prism).

Then finish the set with a Superellipse-extended torus.

Texturing as per sphere/cylinder/torus, so this does not - even if maxed out to be sharp-edged - replace a real box which can have one texture per face.

==Simple Underwater Avatar Physics==

Simulator physics '''option''' for:

When Avatar_position+(Avatar_Height/2) (ie. their head) is below simulator water level, they are put into fly mode. When they are more than Avatar_position+(Avatar_Height/3) (approx shoulder level) below simulator water level, they get a low positive gravity value (buoyancy) applied to them (use the page-down key to swim down against it). 'Swim' into waist-shallow water and Page_Down into land to stand again. No special client-side swim animations, etc. - they would be nice, but fly mode animations are good enough for a start and don't require client-side changes.

(Yes, it can theoretically be done with scripted attachments, but I prefer the efficiency of the physics engine doing it directly).

OpenSimulator:Future Release Discussion

2014-06-09T05:00:51Z

LaeMing: feature provided by hypergrid - request cleaned from proposals page

{{proposal}}
A collection of ideas for additional functionality in OpenSim. Please add your thoughts - anyone may contribute.

== 3D grid structure ==
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

I like the idea of a 3D Grid structure, along with that, the ability to turn off gravity, water and the terrain textures. It would be nice to set the region's background image to a starscape or something other than the default background.

User defined gravity fields. This would be useful in a grid environment that was space themed, certain areas could have defined gravity fields. The possibilities for this could be very interesting.

== 3D Security ==

At the end of the day, this technology is a new form of computer user interface, and mobile agent application server. We need to move away from the concept of land, in a 3D environment we could assign access rights to 3D volumes, call them security regions. These security regions would have permissions granted by access lists, ability to assign different rights to different users or groups. (if we did 3D grid structures this would be a must)

One security feature, is the ability to "hide" objects within a security region from users that don't have access rights. Much like barriers in SL, these 3D security regions would just not show up in the viewer, and the user would not have rights to enter the area. It would interesting if you could do this on a primative level, an object that is only viewable by people/objects with the proper permissions. (The engine could detect collision based on bounding box)

== Portal Primatives ==

I propose a "hyperlink" prim that would be configured with an URL to a destination region/grid. The prim would be like a phantom prim, and when looked at, the user would see the destination, a doorway, like a region boundry, when the avatar passes through the object, the avatar is handed off to the destination region. This would be very cool feature, a user/company could "rent" space on a popular grid a store front, in the back of the store is a "doorway" to the user/company's private region/grid server.

(Croquet is an excellent referral to this concept, since the developers devised Portal "primitives" that allow travel not only between different worlds, but to your own one aswell. Also, once your in your own world, you can create yet another Portal to a new world that you created and so on.) -Darakon Kayvon

== Governance System ==
The online world would have to provide a means for communities to develop legal and political systems of governance. I can think of voting systems as a start.

== Scripting ==
See the list of [[OSSL Proposals]].

== Payment System ==
OpenSim will need to support micropayment. See [[Money]] for details on how this could be achieved.

== Free-form Avatars ==
OpenSim should, at some point in time, support the design and animation of free-form avatars (e.g. animals, monsters, robots).

== In-World console maintenance ==
Terrain manipulations, statistics and some SIM administration related tasks are not available using the Viewer - they are only available on the command line application console where OpenSim is running. It would be nice to have this same console available in-world, using an Instant Messaging window with the simulator itself, the same way as we do with thoses old command line terminals.

== Externally Scripted Objects ==
A prim with the script contents something along the line of //external:somehost:someport.
Have the simulator connect to this host:port and relay data from it to the prim.
Example, have a simple library that maps the LSL functions to a simple binary protocol, which can be used from various programming languages, not neccessarily .NET, and have it act like a server.
This would allow scripts to be hosted outside the Simulator while adding security, as no code would be running on the Simulator. People could code Prim scripts using C if they wished, and the library would simply send the LSL commands to the server for relaying to the clients. If this could go straight to the client then even better. The next step after that would be for the script to be able to send Prim data aswell.
This also gives the possibility of using one running script on several different Simulators at once.
- HashBox

==Object Inventory Source Control==
* This wish list feature starts with the premise that "I HATE working on scripting and objects within SL". Basically, allow users to checkout an object and its contents to an SVN repository. Work on the object and contents locally in whatever application they wish. Later, they can checkin the changes, and update the object inside the simulator.
* [http://www.softec.st/en/OpenSource/ClrProjects/SubversionSharp/SubversionSharp.html SubversionSharp]

==The ability to set region bounderies==

Useful in adding a max ceiling to a region. If it was possible, ability to create a "region box" with as stated earlier, an arbitrary origin. Thinking a little further, a "region sphere" would be interesting.

==Universal Location Addressing==

As part of grid to grid travel, a common standard for a universal location address / coordinate will need to be defined and supported.

Proposal: opensim://sim.grid.domain.tld:x.y.z/named_location/?param=value (alternatively, could be osa:// or osl://, or sim://).

Examples of use:
* opensim://sim25.mygrid.mycompany.mycountry/
* opensim://shoppingcenter.gridprovider.mycountry/myshop/
* opensim://mysim.mygrid.mycompany.mycountry:100.75.80/
* opensim://closedgrid.myworld.business/entrance_hall/?userid=xxx&password=yyy

To avoid confusion, Opensim TLDs will need to be different from existing Internet TLDs.
A naming registrar (NIC) will need to be established that ensures uniqueness and proper handling of registrations. - Ezekiel

Proposal: <sim|grid>://<FQDN>[[:<[zonename,]x,y,z>] | [/<symbolic destination>]]

Examples:
* sim://www.mydomain.com
* sim://www.mydomain.com:0,0,0
* sim://www.mydomain.com/mycoolplace
* grid://www.mydomain.com
* grid://www.mydomain.com/mycoolplace
* grid://www.mydomain.com:Zone1,0,0,0

The client can then get the required information regarding port numbers, protocols, and so on from SVR records embedded in the FQDN DNS Zone. This way clients are immune to changes in the physical hosting of the simulators. The data encoded in the SVR record could also give clues as to the protocol versions, abilities and restrictions of the destination. -Kelannim

==Scriptable 'bodyparts' (Shape, Hair, Eyes etc)==

This relates to Shapes, Hair, Eyes etc which are not prims but 'bodyparts', and are not manipulatable via LSL.

Two script commands could be implemented, one to write say a vector to 'bodypart' parameters (the numbers one edits in 'Appearance...'), and another to read them. It would be interesting to be able to create 'bodyparts' from scripts, using data derived externally or calculated in a script, perhaps from other 'bodyparts' data....

Further, with an extension to the permission system (notifying user that a script wants to modify a Shape/Hair/Eyes/whatever of theirs), perhaps editing of existing 'bodypart's could also be available.

==Tide Server==

It might be interesting to support tides in OGS. It should be doable without any mods to the SL client and probably wouldn't be even a big project (possibly a good teeth-cutting project for someone who wants to get into OGS server coding but isn't confident to tackle parts of a big or critical server component).

A few things to consider:

* The tide server just periodically updates the water level in a grid's sims.
* Would need to be grid-wide or dis-synchronised tides would have ocean-edge alignment issues (so no rolling tides across huge grids, sorry) so it would be a server operating at the grid level talking to regions.
* Needs to be over-ridable as inland regions often use water level for things other than ocean and wouldn't want to follow the tides.
* By using plug-in servers, different complexities of tide can be implemented depending on grid needs.

===Some example tide servers===

* Null tide - simply a way to globally set sea-level in a grid. Takes a single sea-level value.
* Simple Periodic - set the max, min and period and starting time values and let it roll.
* Sun (and moon) locked - uses the position of the sun/moon to place tides realistically (presently rather easy as the sun and moon are always 180deg apart, but they might get unlocked from eachother later, extra suns/moons might also crop up long-term - presently it would be the same as Simple Periodic, but time-synced with whatever the day cycle is). Can day-cycles be enforced (or at least a default set) region-wide? Otherwise this would not be feasible.

===SL Client compatibility===

When the client sends a water-level request to the region, the region does one of two things:

* if the water level is -32768 (assuming this value is stored as signed32) or 65535 (if it is a u32) or whatever represents the most 'insane' value possible, then the region refers back upstream to the grid tide server, gets the present tide level, and returns that (sane) value to the client.
* if waterlevel set for the region is in the 'sane' range, that (region-local) value is returned without referring to the tide server.

(A region-server console command to set the water level outside what the current SL viewer allows is assumed).

===Updating the tides.===

(I assume the region is capable of informing attached clients when water level changes so that on-the-fly changes by region admins are reflected reasonably immediately in clients already).

* tide server periodically multicasts a tide update signal to all regions.
* if the region water level is in the 'insane' setting, it passes the update on to the attached (and neighbour-attached) clients.
* if the region water level is 'sane' it does nothing, leaving the region-manager's water-level alone.

==Client Side Weather System==
A client side based weather system would be a breath of fresh air to those who enjoy more realism (Graphically). An overall Grid Weather System could also be created, so that different parts of the grid will be experiencing different forms of weather e.g 4+ Regions more to the north of the Grid would be in the midst of a blizzard whilst several sims further to the south are enjoying clear blue skys, but with an onset of rain on the way.
A Server could be set up in order to simulate the overall GWS (Grid Weather System) and would shout to each region to simulate a specified weather type.
All the Client has to do is pick up on the Information being sent to the region from the GWS and simulate it on-screen for it's users.
Obviously this feature can be turned on and off at will, but it would be nice to not have to set up a particle weather system that cause's more lag than necessary. - Darakon Kayvon
<math>Insert formula here</math>

==Strong Identities==

Basically objects and users would have strong identities created using public key cryptography. A creator or user would create a public/private key pair and register it with a key server, along with a signed hash of their character name/UUID/whatever. This creates a strong identity associated with the user.

This creator key could be used to generate certificates associated with their objects (signing the UUID and a hash of the geometry of the object along with their key identity) and register along with the geometry hash in a database. They could also create 'ownership' certificates which would be a signature against a player's identity and the object hash.

One of the uses of this is to allow a sort of voluntary property enforcement. The way it would work is that when an object is transferred using an intergrid (HyperGrid) connection, the transferor would also send any certificates associated with the object. These certificates, if the receiving server wishes, could communicate ownership or copy/mod/no-transfer rights based on the certificate and checking against the public key servers and object registries; it may also simply communicate a sort of certificate status to the other clients such that it could be verified that these objects are indeed created or authorized copies owned by the client. This would of course be completely voluntary within the grid, but it could allow commercial grids to manage intergrid object moves strictly if they want to. It could also exist simply to increase the 'cachet of ownership' such that you can show that you indeed purchase this from the creator.

Some notes:
* It would be trivially easy for malicious clients to modify the object slightly in order to generate a new hash and register it with the object server. The point boils down to really more supporting the social movement of supporting artists you like and being able to show thus. Artists could publish their object UUIDs along with their owners so that they could be reverified orthogonally.
* It would be trivially easy for malicious clients to submit erroneous hashes for objects. This could be solved by transferring the object parameters (all of the prims, locations, and parameters, the object description) to the object registry and having it do the hashing.
* The creator keypair could be used for intergrid authentication also. Since it is a proper strong encryption keypair which is tightly associated to an avatar identity it could allow authenticated intergrid connections. It could also be used to encipher the communication between the client and the grid and authenticate messages back and forth.
* Strong identities for objects could include a keypair which allows real-world integration such as bank transactions and whatnot to have a physical metaphor.
* The point of the object certificates really isn't DRM (although in a limited sense it can be used for thus), but (partially) a way to show other players that an object was payed for and is original, that you willingly supported a creator voluntarily with your patronage.

--[[User:NickRusnov|NickRusnov]] 21:45, 28 November 2008 (UTC)

==Extend the form of the Sphere to a Superquadric Ellipsoid + Geodesic==

On the end of present sphere data definition add the fields...
*'''Sharpness''' - default to zero, meaning a regular sphere/ovoid and the sphere rendering path is to be used as per usual client-side (and the 'sides' field ignored).
*'''Sides''' - can be set to any valid geodesic shape (client-side renderer can clip this value if too high). Negative value indicates to use the geodesic's dual.

Client-side (eg HipoViewer) would then need to be altered to allow editing and rendering of these shapes. (Detecting full sharpness and full roundness and passing these to appropriate optimised renderers for these shapes likely a good idea).

Adding same values to the end of the Cylinder shape to make an extruded Superellipse would be nice too (and with full sharpness, arbitrary regular shape extrusions such as pentagonal/hexagonal/octagonal prism).

Then finish the set with a Superellipse-extended torus.

Texturing as per sphere/cylinder/torus, so this does not - even if maxed out to be sharp-edged - replace a real box which can have one texture per face.

==Simple Underwater Avatar Physics==

Simulator physics '''option''' for:

When Avatar_position+(Avatar_Height/2) (ie. their head) is below simulator water level, they are put into fly mode. When they are more than Avatar_position+(Avatar_Height/3) (approx shoulder level) below simulator water level, they get a low positive gravity value (buoyancy) applied to them (use the page-down key to swim down against it). 'Swim' into waist-shallow water and Page_Down into land to stand again. No special client-side swim animations, etc. - they would be nice, but fly mode animations are good enough for a start and don't require client-side changes.

(Yes, it can theoretically be done with scripted attachments, but I prefer the efficiency of the physics engine doing it directly).

OpenSimulator:Future Release Discussion

2014-06-09T05:00:12Z

LaeMing: feature request covered by hypergrid and above portal-prim request. Cleaned from request page

{{proposal}}
A collection of ideas for additional functionality in OpenSim. Please add your thoughts - anyone may contribute.

== 3D grid structure ==
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

I like the idea of a 3D Grid structure, along with that, the ability to turn off gravity, water and the terrain textures. It would be nice to set the region's background image to a starscape or something other than the default background.

User defined gravity fields. This would be useful in a grid environment that was space themed, certain areas could have defined gravity fields. The possibilities for this could be very interesting.

== 3D Security ==

At the end of the day, this technology is a new form of computer user interface, and mobile agent application server. We need to move away from the concept of land, in a 3D environment we could assign access rights to 3D volumes, call them security regions. These security regions would have permissions granted by access lists, ability to assign different rights to different users or groups. (if we did 3D grid structures this would be a must)

One security feature, is the ability to "hide" objects within a security region from users that don't have access rights. Much like barriers in SL, these 3D security regions would just not show up in the viewer, and the user would not have rights to enter the area. It would interesting if you could do this on a primative level, an object that is only viewable by people/objects with the proper permissions. (The engine could detect collision based on bounding box)

== Portal Primatives ==

I propose a "hyperlink" prim that would be configured with an URL to a destination region/grid. The prim would be like a phantom prim, and when looked at, the user would see the destination, a doorway, like a region boundry, when the avatar passes through the object, the avatar is handed off to the destination region. This would be very cool feature, a user/company could "rent" space on a popular grid a store front, in the back of the store is a "doorway" to the user/company's private region/grid server.

(Croquet is an excellent referral to this concept, since the developers devised Portal "primitives" that allow travel not only between different worlds, but to your own one aswell. Also, once your in your own world, you can create yet another Portal to a new world that you created and so on.) -Darakon Kayvon

== Governance System ==
The online world would have to provide a means for communities to develop legal and political systems of governance. I can think of voting systems as a start.

== Scripting ==
See the list of [[OSSL Proposals]].

== Payment System ==
OpenSim will need to support micropayment. See [[Money]] for details on how this could be achieved.

== Free-form Avatars ==
OpenSim should, at some point in time, support the design and animation of free-form avatars (e.g. animals, monsters, robots).

== In-World console maintenance ==
Terrain manipulations, statistics and some SIM administration related tasks are not available using the Viewer - they are only available on the command line application console where OpenSim is running. It would be nice to have this same console available in-world, using an Instant Messaging window with the simulator itself, the same way as we do with thoses old command line terminals.

== Externally Scripted Objects ==
A prim with the script contents something along the line of //external:somehost:someport.
Have the simulator connect to this host:port and relay data from it to the prim.
Example, have a simple library that maps the LSL functions to a simple binary protocol, which can be used from various programming languages, not neccessarily .NET, and have it act like a server.
This would allow scripts to be hosted outside the Simulator while adding security, as no code would be running on the Simulator. People could code Prim scripts using C if they wished, and the library would simply send the LSL commands to the server for relaying to the clients. If this could go straight to the client then even better. The next step after that would be for the script to be able to send Prim data aswell.
This also gives the possibility of using one running script on several different Simulators at once.
- HashBox

==Object Inventory Source Control==
* This wish list feature starts with the premise that "I HATE working on scripting and objects within SL". Basically, allow users to checkout an object and its contents to an SVN repository. Work on the object and contents locally in whatever application they wish. Later, they can checkin the changes, and update the object inside the simulator.
* [http://www.softec.st/en/OpenSource/ClrProjects/SubversionSharp/SubversionSharp.html SubversionSharp]

==The ability to set region bounderies==

Useful in adding a max ceiling to a region. If it was possible, ability to create a "region box" with as stated earlier, an arbitrary origin. Thinking a little further, a "region sphere" would be interesting.

==Grid to Grid Travel==

Going to each grid seems to require setting up an account there. Someone may specialize in 'passport authentication' allowing an avatar to hop from grid to grid (possibly with just a wallet and a small 'suitcase' inventory) as one would go from country to country in rl. Grids get control of who and how may pass through their grid.

==Universal Location Addressing==

As part of grid to grid travel, a common standard for a universal location address / coordinate will need to be defined and supported.

Proposal: opensim://sim.grid.domain.tld:x.y.z/named_location/?param=value (alternatively, could be osa:// or osl://, or sim://).

Examples of use:
* opensim://sim25.mygrid.mycompany.mycountry/
* opensim://shoppingcenter.gridprovider.mycountry/myshop/
* opensim://mysim.mygrid.mycompany.mycountry:100.75.80/
* opensim://closedgrid.myworld.business/entrance_hall/?userid=xxx&password=yyy

To avoid confusion, Opensim TLDs will need to be different from existing Internet TLDs.
A naming registrar (NIC) will need to be established that ensures uniqueness and proper handling of registrations. - Ezekiel

Proposal: <sim|grid>://<FQDN>[[:<[zonename,]x,y,z>] | [/<symbolic destination>]]

Examples:
* sim://www.mydomain.com
* sim://www.mydomain.com:0,0,0
* sim://www.mydomain.com/mycoolplace
* grid://www.mydomain.com
* grid://www.mydomain.com/mycoolplace
* grid://www.mydomain.com:Zone1,0,0,0

The client can then get the required information regarding port numbers, protocols, and so on from SVR records embedded in the FQDN DNS Zone. This way clients are immune to changes in the physical hosting of the simulators. The data encoded in the SVR record could also give clues as to the protocol versions, abilities and restrictions of the destination. -Kelannim

==Scriptable 'bodyparts' (Shape, Hair, Eyes etc)==

This relates to Shapes, Hair, Eyes etc which are not prims but 'bodyparts', and are not manipulatable via LSL.

Two script commands could be implemented, one to write say a vector to 'bodypart' parameters (the numbers one edits in 'Appearance...'), and another to read them. It would be interesting to be able to create 'bodyparts' from scripts, using data derived externally or calculated in a script, perhaps from other 'bodyparts' data....

Further, with an extension to the permission system (notifying user that a script wants to modify a Shape/Hair/Eyes/whatever of theirs), perhaps editing of existing 'bodypart's could also be available.

==Tide Server==

It might be interesting to support tides in OGS. It should be doable without any mods to the SL client and probably wouldn't be even a big project (possibly a good teeth-cutting project for someone who wants to get into OGS server coding but isn't confident to tackle parts of a big or critical server component).

A few things to consider:

* The tide server just periodically updates the water level in a grid's sims.
* Would need to be grid-wide or dis-synchronised tides would have ocean-edge alignment issues (so no rolling tides across huge grids, sorry) so it would be a server operating at the grid level talking to regions.
* Needs to be over-ridable as inland regions often use water level for things other than ocean and wouldn't want to follow the tides.
* By using plug-in servers, different complexities of tide can be implemented depending on grid needs.

===Some example tide servers===

* Null tide - simply a way to globally set sea-level in a grid. Takes a single sea-level value.
* Simple Periodic - set the max, min and period and starting time values and let it roll.
* Sun (and moon) locked - uses the position of the sun/moon to place tides realistically (presently rather easy as the sun and moon are always 180deg apart, but they might get unlocked from eachother later, extra suns/moons might also crop up long-term - presently it would be the same as Simple Periodic, but time-synced with whatever the day cycle is). Can day-cycles be enforced (or at least a default set) region-wide? Otherwise this would not be feasible.

===SL Client compatibility===

When the client sends a water-level request to the region, the region does one of two things:

* if the water level is -32768 (assuming this value is stored as signed32) or 65535 (if it is a u32) or whatever represents the most 'insane' value possible, then the region refers back upstream to the grid tide server, gets the present tide level, and returns that (sane) value to the client.
* if waterlevel set for the region is in the 'sane' range, that (region-local) value is returned without referring to the tide server.

(A region-server console command to set the water level outside what the current SL viewer allows is assumed).

===Updating the tides.===

(I assume the region is capable of informing attached clients when water level changes so that on-the-fly changes by region admins are reflected reasonably immediately in clients already).

* tide server periodically multicasts a tide update signal to all regions.
* if the region water level is in the 'insane' setting, it passes the update on to the attached (and neighbour-attached) clients.
* if the region water level is 'sane' it does nothing, leaving the region-manager's water-level alone.

==Client Side Weather System==
A client side based weather system would be a breath of fresh air to those who enjoy more realism (Graphically). An overall Grid Weather System could also be created, so that different parts of the grid will be experiencing different forms of weather e.g 4+ Regions more to the north of the Grid would be in the midst of a blizzard whilst several sims further to the south are enjoying clear blue skys, but with an onset of rain on the way.
A Server could be set up in order to simulate the overall GWS (Grid Weather System) and would shout to each region to simulate a specified weather type.
All the Client has to do is pick up on the Information being sent to the region from the GWS and simulate it on-screen for it's users.
Obviously this feature can be turned on and off at will, but it would be nice to not have to set up a particle weather system that cause's more lag than necessary. - Darakon Kayvon
<math>Insert formula here</math>

==Strong Identities==

Basically objects and users would have strong identities created using public key cryptography. A creator or user would create a public/private key pair and register it with a key server, along with a signed hash of their character name/UUID/whatever. This creates a strong identity associated with the user.

This creator key could be used to generate certificates associated with their objects (signing the UUID and a hash of the geometry of the object along with their key identity) and register along with the geometry hash in a database. They could also create 'ownership' certificates which would be a signature against a player's identity and the object hash.

One of the uses of this is to allow a sort of voluntary property enforcement. The way it would work is that when an object is transferred using an intergrid (HyperGrid) connection, the transferor would also send any certificates associated with the object. These certificates, if the receiving server wishes, could communicate ownership or copy/mod/no-transfer rights based on the certificate and checking against the public key servers and object registries; it may also simply communicate a sort of certificate status to the other clients such that it could be verified that these objects are indeed created or authorized copies owned by the client. This would of course be completely voluntary within the grid, but it could allow commercial grids to manage intergrid object moves strictly if they want to. It could also exist simply to increase the 'cachet of ownership' such that you can show that you indeed purchase this from the creator.

Some notes:
* It would be trivially easy for malicious clients to modify the object slightly in order to generate a new hash and register it with the object server. The point boils down to really more supporting the social movement of supporting artists you like and being able to show thus. Artists could publish their object UUIDs along with their owners so that they could be reverified orthogonally.
* It would be trivially easy for malicious clients to submit erroneous hashes for objects. This could be solved by transferring the object parameters (all of the prims, locations, and parameters, the object description) to the object registry and having it do the hashing.
* The creator keypair could be used for intergrid authentication also. Since it is a proper strong encryption keypair which is tightly associated to an avatar identity it could allow authenticated intergrid connections. It could also be used to encipher the communication between the client and the grid and authenticate messages back and forth.
* Strong identities for objects could include a keypair which allows real-world integration such as bank transactions and whatnot to have a physical metaphor.
* The point of the object certificates really isn't DRM (although in a limited sense it can be used for thus), but (partially) a way to show other players that an object was payed for and is original, that you willingly supported a creator voluntarily with your patronage.

--[[User:NickRusnov|NickRusnov]] 21:45, 28 November 2008 (UTC)

==Extend the form of the Sphere to a Superquadric Ellipsoid + Geodesic==

On the end of present sphere data definition add the fields...
*'''Sharpness''' - default to zero, meaning a regular sphere/ovoid and the sphere rendering path is to be used as per usual client-side (and the 'sides' field ignored).
*'''Sides''' - can be set to any valid geodesic shape (client-side renderer can clip this value if too high). Negative value indicates to use the geodesic's dual.

Client-side (eg HipoViewer) would then need to be altered to allow editing and rendering of these shapes. (Detecting full sharpness and full roundness and passing these to appropriate optimised renderers for these shapes likely a good idea).

Adding same values to the end of the Cylinder shape to make an extruded Superellipse would be nice too (and with full sharpness, arbitrary regular shape extrusions such as pentagonal/hexagonal/octagonal prism).

Then finish the set with a Superellipse-extended torus.

Texturing as per sphere/cylinder/torus, so this does not - even if maxed out to be sharp-edged - replace a real box which can have one texture per face.

==Simple Underwater Avatar Physics==

Simulator physics '''option''' for:

When Avatar_position+(Avatar_Height/2) (ie. their head) is below simulator water level, they are put into fly mode. When they are more than Avatar_position+(Avatar_Height/3) (approx shoulder level) below simulator water level, they get a low positive gravity value (buoyancy) applied to them (use the page-down key to swim down against it). 'Swim' into waist-shallow water and Page_Down into land to stand again. No special client-side swim animations, etc. - they would be nice, but fly mode animations are good enough for a start and don't require client-side changes.

(Yes, it can theoretically be done with scripted attachments, but I prefer the efficiency of the physics engine doing it directly).

OpenSimulator:Future Release Discussion

2014-06-09T04:58:12Z

LaeMing: feature provided - request cleaned from proposals page

{{proposal}}
A collection of ideas for additional functionality in OpenSim. Please add your thoughts - anyone may contribute.

== 3D grid structure ==
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

I like the idea of a 3D Grid structure, along with that, the ability to turn off gravity, water and the terrain textures. It would be nice to set the region's background image to a starscape or something other than the default background.

User defined gravity fields. This would be useful in a grid environment that was space themed, certain areas could have defined gravity fields. The possibilities for this could be very interesting.

== 3D Security ==

At the end of the day, this technology is a new form of computer user interface, and mobile agent application server. We need to move away from the concept of land, in a 3D environment we could assign access rights to 3D volumes, call them security regions. These security regions would have permissions granted by access lists, ability to assign different rights to different users or groups. (if we did 3D grid structures this would be a must)

One security feature, is the ability to "hide" objects within a security region from users that don't have access rights. Much like barriers in SL, these 3D security regions would just not show up in the viewer, and the user would not have rights to enter the area. It would interesting if you could do this on a primative level, an object that is only viewable by people/objects with the proper permissions. (The engine could detect collision based on bounding box)

== Portal Primatives ==

I propose a "hyperlink" prim that would be configured with an URL to a destination region/grid. The prim would be like a phantom prim, and when looked at, the user would see the destination, a doorway, like a region boundry, when the avatar passes through the object, the avatar is handed off to the destination region. This would be very cool feature, a user/company could "rent" space on a popular grid a store front, in the back of the store is a "doorway" to the user/company's private region/grid server.

(Croquet is an excellent referral to this concept, since the developers devised Portal "primitives" that allow travel not only between different worlds, but to your own one aswell. Also, once your in your own world, you can create yet another Portal to a new world that you created and so on.) -Darakon Kayvon

== Governance System ==
The online world would have to provide a means for communities to develop legal and political systems of governance. I can think of voting systems as a start.

== Scripting ==
See the list of [[OSSL Proposals]].

== Payment System ==
OpenSim will need to support micropayment. See [[Money]] for details on how this could be achieved.

== Free-form Avatars ==
OpenSim should, at some point in time, support the design and animation of free-form avatars (e.g. animals, monsters, robots).

== In-World console maintenance ==
Terrain manipulations, statistics and some SIM administration related tasks are not available using the Viewer - they are only available on the command line application console where OpenSim is running. It would be nice to have this same console available in-world, using an Instant Messaging window with the simulator itself, the same way as we do with thoses old command line terminals.

== Externally Scripted Objects ==
A prim with the script contents something along the line of //external:somehost:someport.
Have the simulator connect to this host:port and relay data from it to the prim.
Example, have a simple library that maps the LSL functions to a simple binary protocol, which can be used from various programming languages, not neccessarily .NET, and have it act like a server.
This would allow scripts to be hosted outside the Simulator while adding security, as no code would be running on the Simulator. People could code Prim scripts using C if they wished, and the library would simply send the LSL commands to the server for relaying to the clients. If this could go straight to the client then even better. The next step after that would be for the script to be able to send Prim data aswell.
This also gives the possibility of using one running script on several different Simulators at once.
- HashBox

==Object Inventory Source Control==
* This wish list feature starts with the premise that "I HATE working on scripting and objects within SL". Basically, allow users to checkout an object and its contents to an SVN repository. Work on the object and contents locally in whatever application they wish. Later, they can checkin the changes, and update the object inside the simulator.
* [http://www.softec.st/en/OpenSource/ClrProjects/SubversionSharp/SubversionSharp.html SubversionSharp]

==Ability to map standalone grid edges to other grid-edges==

The ability to have edges of a standalone region be mapped to other grids or other standalone regions. I'm thinking hyper-space, one-way doors to other places. It would be interesting for standalone private regions that have doors to other places like opengrid or osgrid or something like that.

==The ability to set region bounderies==

Useful in adding a max ceiling to a region. If it was possible, ability to create a "region box" with as stated earlier, an arbitrary origin. Thinking a little further, a "region sphere" would be interesting.

==Grid to Grid Travel==

Going to each grid seems to require setting up an account there. Someone may specialize in 'passport authentication' allowing an avatar to hop from grid to grid (possibly with just a wallet and a small 'suitcase' inventory) as one would go from country to country in rl. Grids get control of who and how may pass through their grid.

==Universal Location Addressing==

As part of grid to grid travel, a common standard for a universal location address / coordinate will need to be defined and supported.

Proposal: opensim://sim.grid.domain.tld:x.y.z/named_location/?param=value (alternatively, could be osa:// or osl://, or sim://).

Examples of use:
* opensim://sim25.mygrid.mycompany.mycountry/
* opensim://shoppingcenter.gridprovider.mycountry/myshop/
* opensim://mysim.mygrid.mycompany.mycountry:100.75.80/
* opensim://closedgrid.myworld.business/entrance_hall/?userid=xxx&password=yyy

To avoid confusion, Opensim TLDs will need to be different from existing Internet TLDs.
A naming registrar (NIC) will need to be established that ensures uniqueness and proper handling of registrations. - Ezekiel

Proposal: <sim|grid>://<FQDN>[[:<[zonename,]x,y,z>] | [/<symbolic destination>]]

Examples:
* sim://www.mydomain.com
* sim://www.mydomain.com:0,0,0
* sim://www.mydomain.com/mycoolplace
* grid://www.mydomain.com
* grid://www.mydomain.com/mycoolplace
* grid://www.mydomain.com:Zone1,0,0,0

The client can then get the required information regarding port numbers, protocols, and so on from SVR records embedded in the FQDN DNS Zone. This way clients are immune to changes in the physical hosting of the simulators. The data encoded in the SVR record could also give clues as to the protocol versions, abilities and restrictions of the destination. -Kelannim

==Scriptable 'bodyparts' (Shape, Hair, Eyes etc)==

This relates to Shapes, Hair, Eyes etc which are not prims but 'bodyparts', and are not manipulatable via LSL.

Two script commands could be implemented, one to write say a vector to 'bodypart' parameters (the numbers one edits in 'Appearance...'), and another to read them. It would be interesting to be able to create 'bodyparts' from scripts, using data derived externally or calculated in a script, perhaps from other 'bodyparts' data....

Further, with an extension to the permission system (notifying user that a script wants to modify a Shape/Hair/Eyes/whatever of theirs), perhaps editing of existing 'bodypart's could also be available.

==Tide Server==

It might be interesting to support tides in OGS. It should be doable without any mods to the SL client and probably wouldn't be even a big project (possibly a good teeth-cutting project for someone who wants to get into OGS server coding but isn't confident to tackle parts of a big or critical server component).

A few things to consider:

* The tide server just periodically updates the water level in a grid's sims.
* Would need to be grid-wide or dis-synchronised tides would have ocean-edge alignment issues (so no rolling tides across huge grids, sorry) so it would be a server operating at the grid level talking to regions.
* Needs to be over-ridable as inland regions often use water level for things other than ocean and wouldn't want to follow the tides.
* By using plug-in servers, different complexities of tide can be implemented depending on grid needs.

===Some example tide servers===

* Null tide - simply a way to globally set sea-level in a grid. Takes a single sea-level value.
* Simple Periodic - set the max, min and period and starting time values and let it roll.
* Sun (and moon) locked - uses the position of the sun/moon to place tides realistically (presently rather easy as the sun and moon are always 180deg apart, but they might get unlocked from eachother later, extra suns/moons might also crop up long-term - presently it would be the same as Simple Periodic, but time-synced with whatever the day cycle is). Can day-cycles be enforced (or at least a default set) region-wide? Otherwise this would not be feasible.

===SL Client compatibility===

When the client sends a water-level request to the region, the region does one of two things:

* if the water level is -32768 (assuming this value is stored as signed32) or 65535 (if it is a u32) or whatever represents the most 'insane' value possible, then the region refers back upstream to the grid tide server, gets the present tide level, and returns that (sane) value to the client.
* if waterlevel set for the region is in the 'sane' range, that (region-local) value is returned without referring to the tide server.

(A region-server console command to set the water level outside what the current SL viewer allows is assumed).

===Updating the tides.===

(I assume the region is capable of informing attached clients when water level changes so that on-the-fly changes by region admins are reflected reasonably immediately in clients already).

* tide server periodically multicasts a tide update signal to all regions.
* if the region water level is in the 'insane' setting, it passes the update on to the attached (and neighbour-attached) clients.
* if the region water level is 'sane' it does nothing, leaving the region-manager's water-level alone.

==Client Side Weather System==
A client side based weather system would be a breath of fresh air to those who enjoy more realism (Graphically). An overall Grid Weather System could also be created, so that different parts of the grid will be experiencing different forms of weather e.g 4+ Regions more to the north of the Grid would be in the midst of a blizzard whilst several sims further to the south are enjoying clear blue skys, but with an onset of rain on the way.
A Server could be set up in order to simulate the overall GWS (Grid Weather System) and would shout to each region to simulate a specified weather type.
All the Client has to do is pick up on the Information being sent to the region from the GWS and simulate it on-screen for it's users.
Obviously this feature can be turned on and off at will, but it would be nice to not have to set up a particle weather system that cause's more lag than necessary. - Darakon Kayvon
<math>Insert formula here</math>

==Strong Identities==

Basically objects and users would have strong identities created using public key cryptography. A creator or user would create a public/private key pair and register it with a key server, along with a signed hash of their character name/UUID/whatever. This creates a strong identity associated with the user.

This creator key could be used to generate certificates associated with their objects (signing the UUID and a hash of the geometry of the object along with their key identity) and register along with the geometry hash in a database. They could also create 'ownership' certificates which would be a signature against a player's identity and the object hash.

One of the uses of this is to allow a sort of voluntary property enforcement. The way it would work is that when an object is transferred using an intergrid (HyperGrid) connection, the transferor would also send any certificates associated with the object. These certificates, if the receiving server wishes, could communicate ownership or copy/mod/no-transfer rights based on the certificate and checking against the public key servers and object registries; it may also simply communicate a sort of certificate status to the other clients such that it could be verified that these objects are indeed created or authorized copies owned by the client. This would of course be completely voluntary within the grid, but it could allow commercial grids to manage intergrid object moves strictly if they want to. It could also exist simply to increase the 'cachet of ownership' such that you can show that you indeed purchase this from the creator.

Some notes:
* It would be trivially easy for malicious clients to modify the object slightly in order to generate a new hash and register it with the object server. The point boils down to really more supporting the social movement of supporting artists you like and being able to show thus. Artists could publish their object UUIDs along with their owners so that they could be reverified orthogonally.
* It would be trivially easy for malicious clients to submit erroneous hashes for objects. This could be solved by transferring the object parameters (all of the prims, locations, and parameters, the object description) to the object registry and having it do the hashing.
* The creator keypair could be used for intergrid authentication also. Since it is a proper strong encryption keypair which is tightly associated to an avatar identity it could allow authenticated intergrid connections. It could also be used to encipher the communication between the client and the grid and authenticate messages back and forth.
* Strong identities for objects could include a keypair which allows real-world integration such as bank transactions and whatnot to have a physical metaphor.
* The point of the object certificates really isn't DRM (although in a limited sense it can be used for thus), but (partially) a way to show other players that an object was payed for and is original, that you willingly supported a creator voluntarily with your patronage.

--[[User:NickRusnov|NickRusnov]] 21:45, 28 November 2008 (UTC)

==Extend the form of the Sphere to a Superquadric Ellipsoid + Geodesic==

On the end of present sphere data definition add the fields...
*'''Sharpness''' - default to zero, meaning a regular sphere/ovoid and the sphere rendering path is to be used as per usual client-side (and the 'sides' field ignored).
*'''Sides''' - can be set to any valid geodesic shape (client-side renderer can clip this value if too high). Negative value indicates to use the geodesic's dual.

Client-side (eg HipoViewer) would then need to be altered to allow editing and rendering of these shapes. (Detecting full sharpness and full roundness and passing these to appropriate optimised renderers for these shapes likely a good idea).

Adding same values to the end of the Cylinder shape to make an extruded Superellipse would be nice too (and with full sharpness, arbitrary regular shape extrusions such as pentagonal/hexagonal/octagonal prism).

Then finish the set with a Superellipse-extended torus.

Texturing as per sphere/cylinder/torus, so this does not - even if maxed out to be sharp-edged - replace a real box which can have one texture per face.

==Simple Underwater Avatar Physics==

Simulator physics '''option''' for:

When Avatar_position+(Avatar_Height/2) (ie. their head) is below simulator water level, they are put into fly mode. When they are more than Avatar_position+(Avatar_Height/3) (approx shoulder level) below simulator water level, they get a low positive gravity value (buoyancy) applied to them (use the page-down key to swim down against it). 'Swim' into waist-shallow water and Page_Down into land to stand again. No special client-side swim animations, etc. - they would be nice, but fly mode animations are good enough for a start and don't require client-side changes.

(Yes, it can theoretically be done with scripted attachments, but I prefer the efficiency of the physics engine doing it directly).

OpenSimulator:Future Release Discussion

2014-06-09T04:54:15Z

LaeMing: /* One known Client issue */

{{proposal}}
A collection of ideas for additional functionality in OpenSim. Please add your thoughts - anyone may contribute.

== 3D grid structure ==
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

I like the idea of a 3D Grid structure, along with that, the ability to turn off gravity, water and the terrain textures. It would be nice to set the region's background image to a starscape or something other than the default background.

User defined gravity fields. This would be useful in a grid environment that was space themed, certain areas could have defined gravity fields. The possibilities for this could be very interesting.

== 3D Security ==

At the end of the day, this technology is a new form of computer user interface, and mobile agent application server. We need to move away from the concept of land, in a 3D environment we could assign access rights to 3D volumes, call them security regions. These security regions would have permissions granted by access lists, ability to assign different rights to different users or groups. (if we did 3D grid structures this would be a must)

One security feature, is the ability to "hide" objects within a security region from users that don't have access rights. Much like barriers in SL, these 3D security regions would just not show up in the viewer, and the user would not have rights to enter the area. It would interesting if you could do this on a primative level, an object that is only viewable by people/objects with the proper permissions. (The engine could detect collision based on bounding box)

== Portal Primatives ==

I propose a "hyperlink" prim that would be configured with an URL to a destination region/grid. The prim would be like a phantom prim, and when looked at, the user would see the destination, a doorway, like a region boundry, when the avatar passes through the object, the avatar is handed off to the destination region. This would be very cool feature, a user/company could "rent" space on a popular grid a store front, in the back of the store is a "doorway" to the user/company's private region/grid server.

(Croquet is an excellent referral to this concept, since the developers devised Portal "primitives" that allow travel not only between different worlds, but to your own one aswell. Also, once your in your own world, you can create yet another Portal to a new world that you created and so on.) -Darakon Kayvon

== Governance System ==
The online world would have to provide a means for communities to develop legal and political systems of governance. I can think of voting systems as a start.

== Scripting ==
See the list of [[OSSL Proposals]].

== Payment System ==
OpenSim will need to support micropayment. See [[Money]] for details on how this could be achieved.

== Upload of existing 3D models ==
OpenSim should support common standards for 3D modelling. This would allow the upload of existing 3D models and make OpenSim immediately attractive for architects and project developers and their customers (walk through models).

== Free-form Avatars ==
OpenSim should, at some point in time, support the design and animation of free-form avatars (e.g. animals, monsters, robots).

== In-World console maintenance ==
Terrain manipulations, statistics and some SIM administration related tasks are not available using the Viewer - they are only available on the command line application console where OpenSim is running. It would be nice to have this same console available in-world, using an Instant Messaging window with the simulator itself, the same way as we do with thoses old command line terminals.

== Externally Scripted Objects ==
A prim with the script contents something along the line of //external:somehost:someport.
Have the simulator connect to this host:port and relay data from it to the prim.
Example, have a simple library that maps the LSL functions to a simple binary protocol, which can be used from various programming languages, not neccessarily .NET, and have it act like a server.
This would allow scripts to be hosted outside the Simulator while adding security, as no code would be running on the Simulator. People could code Prim scripts using C if they wished, and the library would simply send the LSL commands to the server for relaying to the clients. If this could go straight to the client then even better. The next step after that would be for the script to be able to send Prim data aswell.
This also gives the possibility of using one running script on several different Simulators at once.
- HashBox

==Object Inventory Source Control==
* This wish list feature starts with the premise that "I HATE working on scripting and objects within SL". Basically, allow users to checkout an object and its contents to an SVN repository. Work on the object and contents locally in whatever application they wish. Later, they can checkin the changes, and update the object inside the simulator.
* [http://www.softec.st/en/OpenSource/ClrProjects/SubversionSharp/SubversionSharp.html SubversionSharp]

==Ability to map standalone grid edges to other grid-edges==

The ability to have edges of a standalone region be mapped to other grids or other standalone regions. I'm thinking hyper-space, one-way doors to other places. It would be interesting for standalone private regions that have doors to other places like opengrid or osgrid or something like that.

==The ability to set region bounderies==

Useful in adding a max ceiling to a region. If it was possible, ability to create a "region box" with as stated earlier, an arbitrary origin. Thinking a little further, a "region sphere" would be interesting.

==Grid to Grid Travel==

Going to each grid seems to require setting up an account there. Someone may specialize in 'passport authentication' allowing an avatar to hop from grid to grid (possibly with just a wallet and a small 'suitcase' inventory) as one would go from country to country in rl. Grids get control of who and how may pass through their grid.

==Universal Location Addressing==

As part of grid to grid travel, a common standard for a universal location address / coordinate will need to be defined and supported.

Proposal: opensim://sim.grid.domain.tld:x.y.z/named_location/?param=value (alternatively, could be osa:// or osl://, or sim://).

Examples of use:
* opensim://sim25.mygrid.mycompany.mycountry/
* opensim://shoppingcenter.gridprovider.mycountry/myshop/
* opensim://mysim.mygrid.mycompany.mycountry:100.75.80/
* opensim://closedgrid.myworld.business/entrance_hall/?userid=xxx&password=yyy

To avoid confusion, Opensim TLDs will need to be different from existing Internet TLDs.
A naming registrar (NIC) will need to be established that ensures uniqueness and proper handling of registrations. - Ezekiel

Proposal: <sim|grid>://<FQDN>[[:<[zonename,]x,y,z>] | [/<symbolic destination>]]

Examples:
* sim://www.mydomain.com
* sim://www.mydomain.com:0,0,0
* sim://www.mydomain.com/mycoolplace
* grid://www.mydomain.com
* grid://www.mydomain.com/mycoolplace
* grid://www.mydomain.com:Zone1,0,0,0

The client can then get the required information regarding port numbers, protocols, and so on from SVR records embedded in the FQDN DNS Zone. This way clients are immune to changes in the physical hosting of the simulators. The data encoded in the SVR record could also give clues as to the protocol versions, abilities and restrictions of the destination. -Kelannim

==Scriptable 'bodyparts' (Shape, Hair, Eyes etc)==

This relates to Shapes, Hair, Eyes etc which are not prims but 'bodyparts', and are not manipulatable via LSL.

Two script commands could be implemented, one to write say a vector to 'bodypart' parameters (the numbers one edits in 'Appearance...'), and another to read them. It would be interesting to be able to create 'bodyparts' from scripts, using data derived externally or calculated in a script, perhaps from other 'bodyparts' data....

Further, with an extension to the permission system (notifying user that a script wants to modify a Shape/Hair/Eyes/whatever of theirs), perhaps editing of existing 'bodypart's could also be available.

==Tide Server==

It might be interesting to support tides in OGS. It should be doable without any mods to the SL client and probably wouldn't be even a big project (possibly a good teeth-cutting project for someone who wants to get into OGS server coding but isn't confident to tackle parts of a big or critical server component).

A few things to consider:

* The tide server just periodically updates the water level in a grid's sims.
* Would need to be grid-wide or dis-synchronised tides would have ocean-edge alignment issues (so no rolling tides across huge grids, sorry) so it would be a server operating at the grid level talking to regions.
* Needs to be over-ridable as inland regions often use water level for things other than ocean and wouldn't want to follow the tides.
* By using plug-in servers, different complexities of tide can be implemented depending on grid needs.

===Some example tide servers===

* Null tide - simply a way to globally set sea-level in a grid. Takes a single sea-level value.
* Simple Periodic - set the max, min and period and starting time values and let it roll.
* Sun (and moon) locked - uses the position of the sun/moon to place tides realistically (presently rather easy as the sun and moon are always 180deg apart, but they might get unlocked from eachother later, extra suns/moons might also crop up long-term - presently it would be the same as Simple Periodic, but time-synced with whatever the day cycle is). Can day-cycles be enforced (or at least a default set) region-wide? Otherwise this would not be feasible.

===SL Client compatibility===

When the client sends a water-level request to the region, the region does one of two things:

* if the water level is -32768 (assuming this value is stored as signed32) or 65535 (if it is a u32) or whatever represents the most 'insane' value possible, then the region refers back upstream to the grid tide server, gets the present tide level, and returns that (sane) value to the client.
* if waterlevel set for the region is in the 'sane' range, that (region-local) value is returned without referring to the tide server.

(A region-server console command to set the water level outside what the current SL viewer allows is assumed).

===Updating the tides.===

(I assume the region is capable of informing attached clients when water level changes so that on-the-fly changes by region admins are reflected reasonably immediately in clients already).

* tide server periodically multicasts a tide update signal to all regions.
* if the region water level is in the 'insane' setting, it passes the update on to the attached (and neighbour-attached) clients.
* if the region water level is 'sane' it does nothing, leaving the region-manager's water-level alone.

==Client Side Weather System==
A client side based weather system would be a breath of fresh air to those who enjoy more realism (Graphically). An overall Grid Weather System could also be created, so that different parts of the grid will be experiencing different forms of weather e.g 4+ Regions more to the north of the Grid would be in the midst of a blizzard whilst several sims further to the south are enjoying clear blue skys, but with an onset of rain on the way.
A Server could be set up in order to simulate the overall GWS (Grid Weather System) and would shout to each region to simulate a specified weather type.
All the Client has to do is pick up on the Information being sent to the region from the GWS and simulate it on-screen for it's users.
Obviously this feature can be turned on and off at will, but it would be nice to not have to set up a particle weather system that cause's more lag than necessary. - Darakon Kayvon
<math>Insert formula here</math>

==Strong Identities==

Basically objects and users would have strong identities created using public key cryptography. A creator or user would create a public/private key pair and register it with a key server, along with a signed hash of their character name/UUID/whatever. This creates a strong identity associated with the user.

This creator key could be used to generate certificates associated with their objects (signing the UUID and a hash of the geometry of the object along with their key identity) and register along with the geometry hash in a database. They could also create 'ownership' certificates which would be a signature against a player's identity and the object hash.

One of the uses of this is to allow a sort of voluntary property enforcement. The way it would work is that when an object is transferred using an intergrid (HyperGrid) connection, the transferor would also send any certificates associated with the object. These certificates, if the receiving server wishes, could communicate ownership or copy/mod/no-transfer rights based on the certificate and checking against the public key servers and object registries; it may also simply communicate a sort of certificate status to the other clients such that it could be verified that these objects are indeed created or authorized copies owned by the client. This would of course be completely voluntary within the grid, but it could allow commercial grids to manage intergrid object moves strictly if they want to. It could also exist simply to increase the 'cachet of ownership' such that you can show that you indeed purchase this from the creator.

Some notes:
* It would be trivially easy for malicious clients to modify the object slightly in order to generate a new hash and register it with the object server. The point boils down to really more supporting the social movement of supporting artists you like and being able to show thus. Artists could publish their object UUIDs along with their owners so that they could be reverified orthogonally.
* It would be trivially easy for malicious clients to submit erroneous hashes for objects. This could be solved by transferring the object parameters (all of the prims, locations, and parameters, the object description) to the object registry and having it do the hashing.
* The creator keypair could be used for intergrid authentication also. Since it is a proper strong encryption keypair which is tightly associated to an avatar identity it could allow authenticated intergrid connections. It could also be used to encipher the communication between the client and the grid and authenticate messages back and forth.
* Strong identities for objects could include a keypair which allows real-world integration such as bank transactions and whatnot to have a physical metaphor.
* The point of the object certificates really isn't DRM (although in a limited sense it can be used for thus), but (partially) a way to show other players that an object was payed for and is original, that you willingly supported a creator voluntarily with your patronage.

--[[User:NickRusnov|NickRusnov]] 21:45, 28 November 2008 (UTC)

==Extend the form of the Sphere to a Superquadric Ellipsoid + Geodesic==

On the end of present sphere data definition add the fields...
*'''Sharpness''' - default to zero, meaning a regular sphere/ovoid and the sphere rendering path is to be used as per usual client-side (and the 'sides' field ignored).
*'''Sides''' - can be set to any valid geodesic shape (client-side renderer can clip this value if too high). Negative value indicates to use the geodesic's dual.

Client-side (eg HipoViewer) would then need to be altered to allow editing and rendering of these shapes. (Detecting full sharpness and full roundness and passing these to appropriate optimised renderers for these shapes likely a good idea).

Adding same values to the end of the Cylinder shape to make an extruded Superellipse would be nice too (and with full sharpness, arbitrary regular shape extrusions such as pentagonal/hexagonal/octagonal prism).

Then finish the set with a Superellipse-extended torus.

Texturing as per sphere/cylinder/torus, so this does not - even if maxed out to be sharp-edged - replace a real box which can have one texture per face.

==Simple Underwater Avatar Physics==

Simulator physics '''option''' for:

When Avatar_position+(Avatar_Height/2) (ie. their head) is below simulator water level, they are put into fly mode. When they are more than Avatar_position+(Avatar_Height/3) (approx shoulder level) below simulator water level, they get a low positive gravity value (buoyancy) applied to them (use the page-down key to swim down against it). 'Swim' into waist-shallow water and Page_Down into land to stand again. No special client-side swim animations, etc. - they would be nice, but fly mode animations are good enough for a start and don't require client-side changes.

(Yes, it can theoretically be done with scripted attachments, but I prefer the efficiency of the physics engine doing it directly).

OpenSimulator:Future Release Discussion

2014-06-09T04:50:47Z

LaeMing: /* Grid to Grid Travel */

{{proposal}}
A collection of ideas for additional functionality in OpenSim. Please add your thoughts - anyone may contribute.

== 3D grid structure ==
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

I like the idea of a 3D Grid structure, along with that, the ability to turn off gravity, water and the terrain textures. It would be nice to set the region's background image to a starscape or something other than the default background.

User defined gravity fields. This would be useful in a grid environment that was space themed, certain areas could have defined gravity fields. The possibilities for this could be very interesting.

== 3D Security ==

At the end of the day, this technology is a new form of computer user interface, and mobile agent application server. We need to move away from the concept of land, in a 3D environment we could assign access rights to 3D volumes, call them security regions. These security regions would have permissions granted by access lists, ability to assign different rights to different users or groups. (if we did 3D grid structures this would be a must)

One security feature, is the ability to "hide" objects within a security region from users that don't have access rights. Much like barriers in SL, these 3D security regions would just not show up in the viewer, and the user would not have rights to enter the area. It would interesting if you could do this on a primative level, an object that is only viewable by people/objects with the proper permissions. (The engine could detect collision based on bounding box)

== Portal Primatives ==

I propose a "hyperlink" prim that would be configured with an URL to a destination region/grid. The prim would be like a phantom prim, and when looked at, the user would see the destination, a doorway, like a region boundry, when the avatar passes through the object, the avatar is handed off to the destination region. This would be very cool feature, a user/company could "rent" space on a popular grid a store front, in the back of the store is a "doorway" to the user/company's private region/grid server.

(Croquet is an excellent referral to this concept, since the developers devised Portal "primitives" that allow travel not only between different worlds, but to your own one aswell. Also, once your in your own world, you can create yet another Portal to a new world that you created and so on.) -Darakon Kayvon

== Governance System ==
The online world would have to provide a means for communities to develop legal and political systems of governance. I can think of voting systems as a start.

== Scripting ==
See the list of [[OSSL Proposals]].

== Payment System ==
OpenSim will need to support micropayment. See [[Money]] for details on how this could be achieved.

== Upload of existing 3D models ==
OpenSim should support common standards for 3D modelling. This would allow the upload of existing 3D models and make OpenSim immediately attractive for architects and project developers and their customers (walk through models).

== Free-form Avatars ==
OpenSim should, at some point in time, support the design and animation of free-form avatars (e.g. animals, monsters, robots).

== In-World console maintenance ==
Terrain manipulations, statistics and some SIM administration related tasks are not available using the Viewer - they are only available on the command line application console where OpenSim is running. It would be nice to have this same console available in-world, using an Instant Messaging window with the simulator itself, the same way as we do with thoses old command line terminals.

== Externally Scripted Objects ==
A prim with the script contents something along the line of //external:somehost:someport.
Have the simulator connect to this host:port and relay data from it to the prim.
Example, have a simple library that maps the LSL functions to a simple binary protocol, which can be used from various programming languages, not neccessarily .NET, and have it act like a server.
This would allow scripts to be hosted outside the Simulator while adding security, as no code would be running on the Simulator. People could code Prim scripts using C if they wished, and the library would simply send the LSL commands to the server for relaying to the clients. If this could go straight to the client then even better. The next step after that would be for the script to be able to send Prim data aswell.
This also gives the possibility of using one running script on several different Simulators at once.
- HashBox

==Object Inventory Source Control==
* This wish list feature starts with the premise that "I HATE working on scripting and objects within SL". Basically, allow users to checkout an object and its contents to an SVN repository. Work on the object and contents locally in whatever application they wish. Later, they can checkin the changes, and update the object inside the simulator.
* [http://www.softec.st/en/OpenSource/ClrProjects/SubversionSharp/SubversionSharp.html SubversionSharp]

==Ability to map standalone grid edges to other grid-edges==

The ability to have edges of a standalone region be mapped to other grids or other standalone regions. I'm thinking hyper-space, one-way doors to other places. It would be interesting for standalone private regions that have doors to other places like opengrid or osgrid or something like that.

==The ability to set region bounderies==

Useful in adding a max ceiling to a region. If it was possible, ability to create a "region box" with as stated earlier, an arbitrary origin. Thinking a little further, a "region sphere" would be interesting.

==Grid to Grid Travel==

Going to each grid seems to require setting up an account there. Someone may specialize in 'passport authentication' allowing an avatar to hop from grid to grid (possibly with just a wallet and a small 'suitcase' inventory) as one would go from country to country in rl. Grids get control of who and how may pass through their grid.

==Universal Location Addressing==

As part of grid to grid travel, a common standard for a universal location address / coordinate will need to be defined and supported.

Proposal: opensim://sim.grid.domain.tld:x.y.z/named_location/?param=value (alternatively, could be osa:// or osl://, or sim://).

Examples of use:
* opensim://sim25.mygrid.mycompany.mycountry/
* opensim://shoppingcenter.gridprovider.mycountry/myshop/
* opensim://mysim.mygrid.mycompany.mycountry:100.75.80/
* opensim://closedgrid.myworld.business/entrance_hall/?userid=xxx&password=yyy

To avoid confusion, Opensim TLDs will need to be different from existing Internet TLDs.
A naming registrar (NIC) will need to be established that ensures uniqueness and proper handling of registrations. - Ezekiel

Proposal: <sim|grid>://<FQDN>[[:<[zonename,]x,y,z>] | [/<symbolic destination>]]

Examples:
* sim://www.mydomain.com
* sim://www.mydomain.com:0,0,0
* sim://www.mydomain.com/mycoolplace
* grid://www.mydomain.com
* grid://www.mydomain.com/mycoolplace
* grid://www.mydomain.com:Zone1,0,0,0

The client can then get the required information regarding port numbers, protocols, and so on from SVR records embedded in the FQDN DNS Zone. This way clients are immune to changes in the physical hosting of the simulators. The data encoded in the SVR record could also give clues as to the protocol versions, abilities and restrictions of the destination. -Kelannim

==Scriptable 'bodyparts' (Shape, Hair, Eyes etc)==

This relates to Shapes, Hair, Eyes etc which are not prims but 'bodyparts', and are not manipulatable via LSL.

Two script commands could be implemented, one to write say a vector to 'bodypart' parameters (the numbers one edits in 'Appearance...'), and another to read them. It would be interesting to be able to create 'bodyparts' from scripts, using data derived externally or calculated in a script, perhaps from other 'bodyparts' data....

Further, with an extension to the permission system (notifying user that a script wants to modify a Shape/Hair/Eyes/whatever of theirs), perhaps editing of existing 'bodypart's could also be available.

==Tide Server==

It might be interesting to support tides in OGS. It should be doable without any mods to the SL client and probably wouldn't be even a big project (possibly a good teeth-cutting project for someone who wants to get into OGS server coding but isn't confident to tackle parts of a big or critical server component).

A few things to consider:

* The tide server just periodically updates the water level in a grid's sims.
* Would need to be grid-wide or dis-synchronised tides would have ocean-edge alignment issues (so no rolling tides across huge grids, sorry) so it would be a server operating at the grid level talking to regions.
* Needs to be over-ridable as inland regions often use water level for things other than ocean and wouldn't want to follow the tides.
* By using plug-in servers, different complexities of tide can be implemented depending on grid needs.

===Some example tide servers===

* Null tide - simply a way to globally set sea-level in a grid. Takes a single sea-level value.
* Simple Periodic - set the max, min and period and starting time values and let it roll.
* Sun (and moon) locked - uses the position of the sun/moon to place tides realistically (presently rather easy as the sun and moon are always 180deg apart, but they might get unlocked from eachother later, extra suns/moons might also crop up long-term - presently it would be the same as Simple Periodic, but time-synced with whatever the day cycle is). Can day-cycles be enforced (or at least a default set) region-wide? Otherwise this would not be feasible.

===SL Client compatibility===

When the client sends a water-level request to the region, the region does one of two things:

* if the water level is -32768 (assuming this value is stored as signed32) or 65535 (if it is a u32) or whatever represents the most 'insane' value possible, then the region refers back upstream to the grid tide server, gets the present tide level, and returns that (sane) value to the client.
* if waterlevel set for the region is in the 'sane' range, that (region-local) value is returned without referring to the tide server.

(A region-server console command to set the water level outside what the current SL viewer allows is assumed).

===Updating the tides.===

(I assume the region is capable of informing attached clients when water level changes so that on-the-fly changes by region admins are reflected reasonably immediately in clients already).

* tide server periodically multicasts a tide update signal to all regions.
* if the region water level is in the 'insane' setting, it passes the update on to the attached (and neighbour-attached) clients.
* if the region water level is 'sane' it does nothing, leaving the region-manager's water-level alone.

===One known Client issue===

The 'extended' water off the edge of actual regions is a problem, as this is probably hard-coded into the client. Probably should have its own setting which can be either fixed per grid (or region for stand-alone) or track the tide server as per region water level.

==Client Side Weather System==
A client side based weather system would be a breath of fresh air to those who enjoy more realism (Graphically). An overall Grid Weather System could also be created, so that different parts of the grid will be experiencing different forms of weather e.g 4+ Regions more to the north of the Grid would be in the midst of a blizzard whilst several sims further to the south are enjoying clear blue skys, but with an onset of rain on the way.
A Server could be set up in order to simulate the overall GWS (Grid Weather System) and would shout to each region to simulate a specified weather type.
All the Client has to do is pick up on the Information being sent to the region from the GWS and simulate it on-screen for it's users.
Obviously this feature can be turned on and off at will, but it would be nice to not have to set up a particle weather system that cause's more lag than necessary. - Darakon Kayvon
<math>Insert formula here</math>

==Strong Identities==

Basically objects and users would have strong identities created using public key cryptography. A creator or user would create a public/private key pair and register it with a key server, along with a signed hash of their character name/UUID/whatever. This creates a strong identity associated with the user.

This creator key could be used to generate certificates associated with their objects (signing the UUID and a hash of the geometry of the object along with their key identity) and register along with the geometry hash in a database. They could also create 'ownership' certificates which would be a signature against a player's identity and the object hash.

One of the uses of this is to allow a sort of voluntary property enforcement. The way it would work is that when an object is transferred using an intergrid (HyperGrid) connection, the transferor would also send any certificates associated with the object. These certificates, if the receiving server wishes, could communicate ownership or copy/mod/no-transfer rights based on the certificate and checking against the public key servers and object registries; it may also simply communicate a sort of certificate status to the other clients such that it could be verified that these objects are indeed created or authorized copies owned by the client. This would of course be completely voluntary within the grid, but it could allow commercial grids to manage intergrid object moves strictly if they want to. It could also exist simply to increase the 'cachet of ownership' such that you can show that you indeed purchase this from the creator.

Some notes:
* It would be trivially easy for malicious clients to modify the object slightly in order to generate a new hash and register it with the object server. The point boils down to really more supporting the social movement of supporting artists you like and being able to show thus. Artists could publish their object UUIDs along with their owners so that they could be reverified orthogonally.
* It would be trivially easy for malicious clients to submit erroneous hashes for objects. This could be solved by transferring the object parameters (all of the prims, locations, and parameters, the object description) to the object registry and having it do the hashing.
* The creator keypair could be used for intergrid authentication also. Since it is a proper strong encryption keypair which is tightly associated to an avatar identity it could allow authenticated intergrid connections. It could also be used to encipher the communication between the client and the grid and authenticate messages back and forth.
* Strong identities for objects could include a keypair which allows real-world integration such as bank transactions and whatnot to have a physical metaphor.
* The point of the object certificates really isn't DRM (although in a limited sense it can be used for thus), but (partially) a way to show other players that an object was payed for and is original, that you willingly supported a creator voluntarily with your patronage.

--[[User:NickRusnov|NickRusnov]] 21:45, 28 November 2008 (UTC)

==Extend the form of the Sphere to a Superquadric Ellipsoid + Geodesic==

On the end of present sphere data definition add the fields...
*'''Sharpness''' - default to zero, meaning a regular sphere/ovoid and the sphere rendering path is to be used as per usual client-side (and the 'sides' field ignored).
*'''Sides''' - can be set to any valid geodesic shape (client-side renderer can clip this value if too high). Negative value indicates to use the geodesic's dual.

Client-side (eg HipoViewer) would then need to be altered to allow editing and rendering of these shapes. (Detecting full sharpness and full roundness and passing these to appropriate optimised renderers for these shapes likely a good idea).

Adding same values to the end of the Cylinder shape to make an extruded Superellipse would be nice too (and with full sharpness, arbitrary regular shape extrusions such as pentagonal/hexagonal/octagonal prism).

Then finish the set with a Superellipse-extended torus.

Texturing as per sphere/cylinder/torus, so this does not - even if maxed out to be sharp-edged - replace a real box which can have one texture per face.

==Simple Underwater Avatar Physics==

Simulator physics '''option''' for:

When Avatar_position+(Avatar_Height/2) (ie. their head) is below simulator water level, they are put into fly mode. When they are more than Avatar_position+(Avatar_Height/3) (approx shoulder level) below simulator water level, they get a low positive gravity value (buoyancy) applied to them (use the page-down key to swim down against it). 'Swim' into waist-shallow water and Page_Down into land to stand again. No special client-side swim animations, etc. - they would be nice, but fly mode animations are good enough for a start and don't require client-side changes.

(Yes, it can theoretically be done with scripted attachments, but I prefer the efficiency of the physics engine doing it directly).

Dependencies

2014-06-09T03:26:55Z

LaeMing: /* Debian */

{{Quicklinks}}

= Note =

These instructions assume that OpenSimulator is running from the binary packages in standalone mode. If this is not the case or you have more complex requirements (e.g. you want to use the MySQL database rather than SQLite or you want to run in grid mode), then you will need to [[Configuration|configure]] OpenSimulator first.

= Dependencies =
In addition to the OpenSimulator code itself, certain other packages need to be installed on different platforms in order to get OpenSimulator binaries to run.

As well as the information on this page (which should be expanded), you may find more information on dependencies in [[Build Instructions]] though this will also contain dependencies required only for building. This are also more hints in [[Troubleshooting]].

After solving dependencies, you may need to configure the firewall installed in your system by default so that the viewers outside can access to OpenSimulator inside it. See [[Firewall Settings]] for more informations.

[[NAT Loopback Routers]] Router and Nat Loopback Information to help you configure your Router / Modem.

== Windows ==

OpenSimulator 0.7.6 requires '''.NET Framework 3.5''' when running under Windows. If you run OpenSimulator on '''Windows 7''' or '''Windows Server 2008 R2''', it is already bundled so you can run OpenSimulator 0.7.1 out-of-the-box. On '''Windows Vista''', '''Windows Server 2008''', '''Windows Server 2003''' or '''Windows XP''', you'll need to upgrade it to 3.5, downloading from [http://msdn.microsoft.com/en-us/netframework/cc378097 Microsoft .NET Framework Download Page@.NET Framework Developer Center]. Note that prior versions of Windows(ex. NT or 2000) are NOT supported.

If you run on Windows XP ensure it is updated to at least Service Pack 2 (SP2).

Current OpenSimulator development code requires .NET Framework 4.0, as will the next OpenSimulator release.

Double-click or execute on command prompt:
*32-bit version of Windows: '''OpenSim.exe'''
*64-bit version of Windows: '''OpenSim.32BitLaunch.exe'''
Depending on your installation, you may have to run the program as administrator(right click -> 'Run as administrator'). It will pop up a window asking permission, select "Allow".

== Linux and Mac OSX ==

OpenSimulator 0.7.6 requires Mono 2.4.3 or later. '''WARNING:''' OpenSimulator is known to have significant performance and scalability problems with Mono versions 2.8.x, 2.10.0 and 2.10.1. As of Mono 2.10.2, the scalability problems appear to have been resolved. Mono 2.6.x also appears to be fine, though the mono VM does seem to have some issues (crashing with a native stacktrace) on simulators running many regions or lots of users/prims. Therefore you should either use Mono 2.6.x or Mono 2.10.2 or later. You can also use Mono 2.4.3, but it is fairly old now.

There are also reports that anything between Mono 2.10.9 and 3.0.3 has major issues; 3.0.7 is supposedly OK.

OpenSimulator development code requires Mono 2.8 or later, with at least Mono 2.10.8 recommended.

To run OpenSimulator with mono, execute

mono --debug OpenSim.exe

This is the same for 32 bit and 64 bit systems. The --debug switch isn't strictly necessary, but it will insert line numbers for stack traces if you ever need to make a bug report, and the overhead of using it is very small.

=== Ubuntu ===

sudo apt-get install mono-complete

{{anchor|CentOS}}{{anchor|RedHat}}{{anchor|RHEL}}{{anchor|Fedora}}
=== RHEL, Fedora, CentOS or Any Other RedHat-based Distributions ===

First, run "yum info mono-core" to see the version of the mono packages in the core repository for your distribution. If it shows '''2.4.3''' or later, proceed to [[#Installing from Core Repository]]. If not, skip to [[#Installing from Mono Repository]]. Note that the current version you can get from yum repository for some distributions is lower than requirement (ex. '''1.2.4''' on CentOS). Unlike Ubuntu, RedHat-based distributions should be always conservative, therefore it is natural that they don't so often update their repository. What you can do to manage this problem is to add an extra repository for mono.

==== Installing from Core Repository ====

Just type:
<pre>
sudo yum install mono-core mono-data-sqlite mono-extras libgdiplus
</pre>
It will also install dependent modules. After that you can launch OpenSim.exe with mono out-of-the-box.

==== Installing from Mono Repository ====

This procedure is tested on CentOS 5.5 & 5.6 box with OpenSimulator 0.7.1.

Go to yum config file folder and create new one for mono.
<pre>
cd /etc/yum.repos.d
sudo vi mono.repo
</pre>

And then in mono.repo :
<pre>
[mono]
name = novell-mono
baseurl=http://ftp.novell.com/pub/mono/download-stable/RHEL_5/
enabled=1
gpgcheck=0
</pre>

Now, you can yum install the later version of mono from this repository. Additional note that make sure all of mono packages are i386(not IA64 build). If your box is 32bit, don't care and you can even install properly without ".i386" suffix.
<pre>
sudo yum install mono-addon-core.i386 mono-addon-data.i386 mono-addon-data-sqlite.i386 \
mono-addon-extras.i386 mono-addon-web.i386 mono-addon-winforms.i386 mono-addon-libgdiplus0.i386
</pre>

Yum will install mono into /opt/novell/mono, so you can create a symbolic link to /usr/bin :
<pre>
sudo ln -s /opt/novell/mono/bin/mono /usr/bin/mono
</pre>

After that, you should be able to launch OpenSim.exe without any errors.

=== Debian ===

Debian 4 (Etch) is no longer supported by debian.org. Update at least to 5 (Lenny) before running OpenSimulator. See [http://www.debian.org/releases/lenny/i386/release-notes/ch-upgrading.html Upgrades from previous release@debian.org] for detail.

For Debian 5 (Lenny) or later, just Type:
<pre>
sudo aptitude install mono-runtime mono-gmcs libmono-microsoft8.0-cil \
libmono-system-runtime2.0-cil libmono-i18n2.0-cil
</pre>

You can even use apt-get instead of aptitude. They both will also install dependent packages.

Tested on Debian 5(Lenny), Debian 6(Squeeze) and Debian 7(Wheezy) unstable.

=== openSuSE ===

Just type:
<pre>
sudo zypper install mono-core mono-data-sqlite mono-extras libgdiplus
</pre>
It will also install dependent modules. After that you can launch OpenSim.exe with mono out-of-the-box.

=== Mac OS X ===

All you have to do is to fetch Mono '''Runtime''' package from [http://www.go-mono.com/mono-downloads/download.html Mono Download Page] and install it. Alternatively, you can install mono with [http://mxcl.github.com/homebrew/ homebrew] with:
<pre>
brew install mono
</pre>

If you are using OS X 10.4, you should also install X11 from the OS X install CDs. In OS X 10.5, this is not required.

= Locales and Regional Settings =
OpenSimulator will only work properly when you run it with an English locale or regional setting. With other settings than English, you are likely to see a variety of issues, ranging from misbehaving scripts to crashes.

== Linux ==
In Linux, you can easily use the standard "C" locale just for running OpenSim.exe, as explained in [[Troubleshooting#ScriptEngine Issues]]:
<pre>
env LANG=C mono OpenSim.exe
</pre>

For information about changing your locale in a more general way, see [[Troubleshooting#Locales Issues]]

== Windows ==
If you are not using an English regional setting in Windows by default, then there is not a solution as easy as for Linux, unfortunately. I did it with an additional user account that I created just for OpenSimulator in which I set the regional setting to "English (US)". I run OpenSim.exe from my normal user account with "Run as..." (or check "Run with different credentials" in a shortcut's advanced properties) and specify the OpenSimulator account as the one to be used.

= Additional Resources =

OSGrid Technical Support Forum with many installation tutorials:  [http://osgrid.org/forums/viewforum.php?f=14 osgrid.org/forums/viewforum.php]

MONO Project:  [http://www.mono-project.com/Main_Page www.mono-project.com/Main_Page]

OpenSimulator Avatar

2013-07-03T08:34:53Z

LaeMing:

__NOTOC__
{{Quicklinks}}
<br />

This page is dedicated for creating a proposal that can act as a starting point for OpenSimulator avatars. The idea is to create one or more base models with blender which can be used as basis for Avatar modeling.

Avatar is one of the most important immersion factors. To help the community to start creating high quality avatars we need your help to get the effort started. If you have any improvement ideas or corrections please fix this page. You can join the project by registering to the following discussion group and requesting for content repository commit rights: [http://groups.google.com/group/open-content-for-metaverse Open Content for Metaverse]

Nice tutorials about using Blender to do avatar poses and animations. The biped model used in these tutorials is available as basis for further work at the model repository:

* [http://download.blender.org/demo/movies/dvd anim/Rattling Bones preview.mov Posing]
* [http://download.blender.org/demo/movies/dvd anim/Workflow preview.mov Animating]
* [http://wiki.blender.org/index.php/Doc:Tutorials/Animation/MoCap Creating an Animation Library from BVH files]

Oh and we want to figure out how to play these with our avies: [http://mocap.cs.cmu.edu/movies.php CMU Graphics Lab Motion Capture Database]

More bvh animations can be made with [http://www.qavimator.org/ Qavimator].

Make Human is a project which can be used to create human avatar models. Combination of non linden based clients and OpenSimulator could support MakeHuman avatars directly: [http://www.makehuman.org/ MakeHuman]

== Model Repository ==

Model repository is available as google project:

http://code.google.com/p/open-content-for-metaverse/source/browse/#svn/trunk/Models/Avatars/Biped/

* I added Nathan Vegdahl's [http://blenderartists.org/forum/showthread.php?t=131079 public domain biped].blend as starting point for Avatar Modeling. - Tommi
** Bone structure can be studied under overwiew/current scene/rig/armature
** IK stands for inverse kinematics.
** GZM stands for gizmo and refers to meshes which are helper clases for bone visualization.
[[Image:Biped.png‎]]

* Alice:

[[Image:Alice.jpg]]

== Best Practices ==

* Use blender to create the avatar.
* [http://en.wikipedia.org/wiki/Edge loops Edge loops] based topology.
* [http://zoomy.net/2008/04/02/modeling-with-edge-loops/ Modeling with Edge Loops] at Zoomy.net.
[[Image:edgeloops2.jpg]]
* Rational polygon count.
* Use the default bone structure or update the default bone structure.

== Default Bone Structure ==

If you need more bones to achieve good result feel free to insert them here. Not all bones are necessarily needed and custom bones may be added to models. Viewers are more likely to support steering default bones.

<pre>
Root
Pelvis
Spine
Spine1
Spine2
Spine3
Neck-Neck1-Neck2-Neck3-Head
LeftClavicle-LeftUpperArm-LeftForearm-LeftHand
LeftFinger0-LeftFinger01-LeftFinger02-LeftFinger0Nub
LeftFinger1-LeftFinger11-LeftFinger12-LeftFinger1Nub
LeftFinger2-LeftFinger21-LeftFinger22-LeftFinger2Nub
LeftFinger3-LeftFinger31-LeftFinger32-LeftFinger3Nub
LeftFinger4-LeftFinger41-LeftFinger42-LeftFinger4Nub
RightClavicle-RightUpperArm-RightForearm-RightHand
RightFinger0-RightFinger01-RightFinger02-RightFinger0Nub
RightFinger1-RightFinger11-RightFinger12-RightFinger1Nub
RightFinger2-RightFinger21-RightFinger22-RightFinger2Nub
RightFinger3-RightFinger31-RightFinger32-RightFinger3Nub
RightFinger4-RightFinger41-RightFinger42-RightFinger4Nub
LeftThigh-LeftCalf-LeftFoot-LeftToe0-LeftToe0Nub (Connected to Spine)
RightThigh-RightCalf-RightFoot-RightToe0-RightToe0Nub (Connected to Spine)
</pre>

== TODO ==

This task list contains tasks which need doing. Please add more tasks and claim tasks for yourself. If this list gets actively used we will probably move it to the google project issue tracking.

* Edit the biped.blend to follow the bone structure naming convention and possibly add missing bones. It is also possible to edit the default bone structure to better reflect the biped.blend if it is more reasonable. (Task not claimed.)

* LaeMing Ai has a rather involved wishlist page for OS avatars on her home site here: [http://home.exetel.com.au/impact/VRwishlist-avatarforms.shtml Proposal for new avatar body shapes]

== Exporting from Blender to OpenSimulator ==

The current proposal is that Blender files (.blend) will be exported to Collada format and stored as binary assets to OpenSimulator. Collada files can then be converted by client views or Viewers to browser specific formats.