MaterialsImplDiscussion
From OpenSimulator
(Difference between revisions)
(→=Store materials data as temporary assets until persistence definitely required) |
(→Cons) |
||
| (12 intermediate revisions by one user not shown) | |||
| Line 6: | Line 6: | ||
Materials are serialized OSD. | Materials are serialized OSD. | ||
| + | |||
| + | == Persistence points == | ||
| + | If materials data needs to be explicitly persisted rather than always done when changed, then this needs to be done at the following points. | ||
| + | |||
| + | '''Serialization points''' | ||
| + | * copy taken into user inventory | ||
| + | * copy taken into prim inventory (could be delayed further but would require deep inspection of a prim's inventory items via UuidGatherer). | ||
| + | * region cross | ||
| + | * teleport (if on attachments) | ||
| + | * IAR saving | ||
| + | * OAR saving | ||
| + | |||
| + | '''Region data points''' (i.e. writing to columns in the region database). | ||
| + | * simulator shutdown. | ||
| + | * periodic persistence. At the current time, prim attributes are periodically persisted to the database to avoid too much loss on simulator crash or unclean shutdown for other reasons (somebody accidentally hits ctrl-c, power goes out, etc.). | ||
= Approaches = | = Approaches = | ||
| + | ==Store materials data as persistent assets when changed== | ||
| + | Whenever a material is set or changed, a new persistent asset is generated. | ||
| + | |||
| + | === Pros === | ||
| + | * No need to worry about persistence points. | ||
| + | |||
| + | === Cons === | ||
| + | * Rapid materials change leads to generation of a large number of assets that are never used again. | ||
| + | * Extra loading on asset service. | ||
| + | |||
| + | ==Store materials data in a prim's dynamic attributes== | ||
| + | Materials are stored in the prim's [[Feature_Proposals/Dynamic_Attributes_in_Scene_Objects|dynamic attributes]] whenever changed. | ||
| + | |||
| + | === Pros === | ||
| + | * All mechanisms required to persist dynamic attributes to both serialization and region database are already implemented and active. | ||
| + | |||
| + | === Cons === | ||
| + | * Duplication of data if multiple prims have the same material. | ||
| + | * CPU cost of [de]serialization. Whether this is a significant impact requires measurement, not assumption. | ||
| + | |||
==Store materials data as temporary assets until persistence definitely required== | ==Store materials data as temporary assets until persistence definitely required== | ||
| − | Materials are kept as temporary assets and only | + | Materials are kept as temporary assets and only persisted when required. |
=== Cons === | === Cons === | ||
| − | * | + | * Persistence triggers need to be hooked by the module. In time critical cases (e.g. region crossing) one would have to be very careful not to unnecessarily delay other code. The module needs to be careful not to generate corrupt or inconsistent data if there is a simultaneous change to the material at the time of persistence. |
| − | * Temporary assets | + | * Temporary assets have the potential to flood the simulator's disk asset cache. This needs to be prevented (which may be a general requirement to improve the simulator cache) and managed (to remove temporary assets when no longer needed). |
| − | + | ||
=== Pros === | === Pros === | ||
| Line 21: | Line 55: | ||
==Store materials data in memory cache until persistence definitely required== | ==Store materials data in memory cache until persistence definitely required== | ||
Materials are kept in a purely in memory cache and only added to the asset service when required | Materials are kept in a purely in memory cache and only added to the asset service when required | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
=== Cons === | === Cons === | ||
| − | * | + | * Persistence triggers need to be hooked by the module. In time critical cases (e.g. region crossing) one would have to be very careful not to unnecessarily delay other code. The module needs to be careful not to generate corrupt or inconsistent data if there is a simultaneous change to the material at the time of persistence. |
| − | * Cache needs to be managed (chiefly removal of items when no longer required). | + | * Cache needs to be managed (chiefly removal of items from memory when no longer required). |
=== Pros === | === Pros === | ||
* Materials can be rapidly changed without [de]serialization or asset storage overhead. | * Materials can be rapidly changed without [de]serialization or asset storage overhead. | ||
Latest revision as of 12:49, 4 July 2014
Contents
|
[edit] Introdution
justincc's notes on alternative possibility for materials implementation
[edit] Background
Materials are serialized OSD.
[edit] Persistence points
If materials data needs to be explicitly persisted rather than always done when changed, then this needs to be done at the following points.
Serialization points
- copy taken into user inventory
- copy taken into prim inventory (could be delayed further but would require deep inspection of a prim's inventory items via UuidGatherer).
- region cross
- teleport (if on attachments)
- IAR saving
- OAR saving
Region data points (i.e. writing to columns in the region database).
- simulator shutdown.
- periodic persistence. At the current time, prim attributes are periodically persisted to the database to avoid too much loss on simulator crash or unclean shutdown for other reasons (somebody accidentally hits ctrl-c, power goes out, etc.).
[edit] Approaches
[edit] Store materials data as persistent assets when changed
Whenever a material is set or changed, a new persistent asset is generated.
[edit] Pros
- No need to worry about persistence points.
[edit] Cons
- Rapid materials change leads to generation of a large number of assets that are never used again.
- Extra loading on asset service.
[edit] Store materials data in a prim's dynamic attributes
Materials are stored in the prim's dynamic attributes whenever changed.
[edit] Pros
- All mechanisms required to persist dynamic attributes to both serialization and region database are already implemented and active.
[edit] Cons
- Duplication of data if multiple prims have the same material.
- CPU cost of [de]serialization. Whether this is a significant impact requires measurement, not assumption.
[edit] Store materials data as temporary assets until persistence definitely required
Materials are kept as temporary assets and only persisted when required.
[edit] Cons
- Persistence triggers need to be hooked by the module. In time critical cases (e.g. region crossing) one would have to be very careful not to unnecessarily delay other code. The module needs to be careful not to generate corrupt or inconsistent data if there is a simultaneous change to the material at the time of persistence.
- Temporary assets have the potential to flood the simulator's disk asset cache. This needs to be prevented (which may be a general requirement to improve the simulator cache) and managed (to remove temporary assets when no longer needed).
[edit] Pros
- Materials can be rapidly changed without persistent asset storage overhead.
[edit] Store materials data in memory cache until persistence definitely required
Materials are kept in a purely in memory cache and only added to the asset service when required
[edit] Cons
- Persistence triggers need to be hooked by the module. In time critical cases (e.g. region crossing) one would have to be very careful not to unnecessarily delay other code. The module needs to be careful not to generate corrupt or inconsistent data if there is a simultaneous change to the material at the time of persistence.
- Cache needs to be managed (chiefly removal of items from memory when no longer required).
[edit] Pros
- Materials can be rapidly changed without [de]serialization or asset storage overhead.
