Introdution

justincc's notes on alternative possibility for materials implementation

Background

Materials are serialized OSD.

Approaches

Store materials data as temporary assets until persistence definitely required

Materials are kept as temporary assets and only made persistent 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 (really 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

• region cross
• teleport (if on attachments)
• IAR saving
• OAR saving
• simulator shutdown

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.