Maintenance gestalt-asset-core

[Immortius]

Name: gestalt-asset-core
Summary: Core asset system library
Scope: Engine
Current Goal: Integration into Terasology
Phase: Integration
Curator: Immortius

The goal of this body of work is extracting out, cleaning up and improving the core asset system. This includes the management of assets and support for defining types and formats. It does not include any actual asset types - this will be a future piece of work (probably a gestalt-asset-game for defining the general game assets, and gestalt-lwjgl for the lwjgl implementation of those assets. gestalt-entity-system would include some assets too).

Key Improvements planned at this stage:
* Support for registering new asset types at runtime
* Cleaner support for asset formats.
* Improved support for asset deltas.
* Support for Supplemental Asset Formats - like texture's metadata files. These will apply across all formats.
* Better integration with gestalt-module.
* Support for auto-reloading assets when they change on disk.

Also brought across will be:
* Support for procedural assets though the AssetData system
* AssetResolvers to allow plugging in procedural sources of assets, and assets producing other assets (e.g. texture atlases)
* Overrides
* The asset lifecycle, such as caching and disposal.

 

[Florian]

I am looking forward to it. Some further asset library features you may want to keep in mind while desiging how it works:

1. "Preloading" of Assets to avoid game slowdowns at the start of a game:
   • e.g. the framework scans a module for asset usages and loads them either while the game loads or after the game has started in the background.
2. Auto disposal of assets when their "Context" becomes invalid.
   
   • I think there is already something in this direction, but I am not familiar with the details. One nice way of archiving this is to have a kind of "factory/asset loader" that has a life time. When the assset factory/loader gets disposed, all assets loaded with it get disposed. If a module has no other way to obatin assets, then it is guranteed that all used assets get disposed when a game ends without the need o manual disposal calls.

 

[Immortius]

I am looking forward to it. Some further asset library features you may want to keep in mind while desiging how it works:

1. "Preloading" of Assets to avoid game slowdowns at the start of a game:
   • e.g. the framework scans a module for asset usages and loads them either while the game loads or after the game has started in the background.

This probably falls outside the framework itself (since the framework doesn't know about "start of the game") - but should be achievable in Terasology by having some sort of preload asset list somewhere - possibly on a component in an auto-entity. Or possibly we just need something else that does this.

1. Auto disposal of assets when their "Context" becomes invalid.
   • I think there is already something in this direction, but I am not familiar with the details. One nice way of archiving this is to have a kind of "factory/asset loader" that has a life time. When the assset factory/loader gets disposed, all assets loaded with it get disposed. If a module has no other way to obatin assets, then it is guranteed that all used assets get disposed when a game ends without the need o manual disposal calls.

This is a fair request, and I am working in this direction. What I have in mind is:

• When the module environment changes, all assets from modules that are no longer available will be disposed. Assets from modules that are in both the old and new environment will either be reloaded or disposed based on their presence in the new environment - they have to be reloaded in case the version changes (and to remove any procedural changes).
• When an asset type is removed, its assets will be disposed. This would typically be part of Terasology's transitioning between module environments (as asset types would be added/removed by modules).
• When the factory is changed, all assets need to be disposed, since the factory ties the assets to implementation (and the new factory may use a new implementation). In practice you probably wouldn't allow these to be changed without restarting the game (so no switching between lwjgl and something else at runtime) because it would be difficult to replace the disposed asset instances with new ones. Could address by adding another layer between asset interface and implementation, probably not worth it?
• No assets will be disposed with format support being added or removed. Assets are not linked to their format of origin, so nothing to be done here.

 

[Immortius]

gestalt-asset-core is done and it plus updates to gestalt-module have been released as 2.3.0 release candidate 1 (2.3.0-RC1).

The next step is to integrate it with Terasology, catching any bugs in the process. This will also involve updating Terasology to use Java 8.

 

[Immortius]

Integration progress report:

For the first phase I'm just going for getting the framework integrated, compiling and basically working. This is taking a while, because there is a lot of code to update. Mostly it is simple, but there are a couple of tricker parts.

• AssetUri is replaced by ResourceUrn. This are quite similar, except that ResourceUrn doesn't require an AssetType and has a couple of extra features. This is mostly a simple change. For subtextures in assets the urns do need to be adapted for the new fragment syntax (e.g. 'engine:icons#axe')
• Asset retrieval. The new framework makes heavy use of java.util.Optional wherever something may be returned as null. This means that code requesting assets needs to be adapted to check whether the object is present rather than null, and get the value out. Generally I've just been getting them out without adding additional checks. (I'm also tempted to set up the Assets helper class to provide default assets when a requested asset is not found, like the default texture (cyan and magenta checkerboard) when a texture is not found).
• Asset Loaders, Resolvers. These aren't hard to update, just a bit of a different syntax and throwing an annotation on them so they are automatically loaded.
• Assets. For the moment I'm skipping adding direct copying support for them, or addressing threading concerns (the new asset system is thread safe, but the assets need to be thread safe to work with this - meaning lwjgl assets will need a bit of work to be loadable on any thread).
• NUI. NUI is generally fine with the new asset system, but previously we were sometimes loading just the UI Data rather than the full element, so that unique instances of the same UI Element could be loaded. The new framework doesn't allow AssetData to be retrieved any more, but the new asset instancing support provides the same capability. (e.g. if ("engine:menuScreen!instance" is requested, a new asset is created with the data of engine:menuScreen). This needs some tweaking in places.
• Blocks are the real issue. The current block implementation was an abuse of the asset system and needs a rework.

Some things to do in second phase and beyond:

• Thread support for assets
• Ensure correct auto-reload behavior for all assets - particularly block tiles will need some work to update the terrain atlas.
• Implement copy support for some assets. By default asset instances create new copies from the original source data, but if an asset provides direct copy support than an instance will be a copy of the asset the instance was taken from, which is nicer.
• General cleanup.