MaterialsImplDiscussion
From OpenSimulator
(Difference between revisions)
| Line 10: | Line 10: | ||
If materials data needs to be explicitly persisted rather than always done when changed, then this needs to be done at the following 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 user inventory | ||
* copy taken into prim inventory (could be delayed further but would require deep inspection of a prim's inventory items via UuidGatherer). | * copy taken into prim inventory (could be delayed further but would require deep inspection of a prim's inventory items via UuidGatherer). | ||
| Line 16: | Line 17: | ||
* IAR saving | * IAR saving | ||
* OAR saving | * OAR saving | ||
| − | * simulator shutdown | + | |
| + | '''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 in a prim's dynamic attributes== | ||
| + | Materials are stored in the prim's [[Dynamic_Attributes_in_Scene_Objects|dynamic attributes]] whenever changed. | ||
| + | |||
| + | === Pros === | ||
| + | * All mechanisms required to | ||
| + | |||
==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 persisted when required. | Materials are kept as temporary assets and only persisted when required. | ||
Revision as of 12:25, 4 July 2014
Contents |
Introdution
justincc's notes on alternative possibility for materials implementation
Background
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
Store materials data in a prim's dynamic attributes
Materials are stored in the prim's dynamic attributes whenever changed.
Pros
- All mechanisms required to
Store materials data as temporary assets until persistence definitely required
Materials are kept as temporary assets and only persisted when required.
Cons
- All possible persistence triggers need to be hooked by the module. It might be possible to simplify this by hooking at the point where existing code asks for an object to be serialized, though this won't cover the case of simulator shutdown.
- Temporary assets don't need to be managed but have the potential to flood the simulator's disk asset cache.
- Materials still suffer an extra serialization cost, though this may be negligible (requires benchmarking).
Pros
- Materials can be rapidly changed without persistent asset storage overhead.
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
Cons
- All possible persistence triggers need to be hooked by the module. It might be possible to simplify this by hooking at the point where existing code asks for an object to be serialized, though this won't cover the case of simulator shutdown.
- Cache needs to be managed (chiefly removal of items when no longer required).
Pros
- Materials can be rapidly changed without [de]serialization or asset storage overhead.
