[RFC] AssetID #7
Conversation
| # Guide-Level Explanation | ||
| [guide-level-explanation]: #guide-level-explanation | ||
|
|
||
| AssetID is an identifier for loadable assets. It is a name and enum for any of three variants. |
There was a problem hiding this comment.
I thought that we've got rid of the enum here. The ID was supposed to be unique and ideally every asset should have only one.
If you want to preserve the possibility to query by path, i'd say we could add a separate AssetQuery type that can hold either an ID or an alias. Dealing with OS paths in general is hard, and i'd leave that out completely if possible.
There is also no word about querying with static type in mind. Can i do import::<Texture>(assetAlias)? Or is the returned type always an opaque dyn Asset? It's especially noteworthy when you consider potential errors.
| Once the Asset Pipeline proposal is fully realized, the AssetID will be used in various parts of the engine/asset pipeline. I don't believe there is value in implementing it before other parts of the Asset Pipeline is ready. | ||
|
|
||
| ### Import | ||
| Each source file can be imported independently in parallel. When importing a single source file, possibly multiple resulting assets will be assigned an AssetUUID each and they may have AssetID dependencies of three kinds: Build, load and instantiate. |
There was a problem hiding this comment.
The dependency kinds are a bit ambiguous for me. What does instantiate do?
|
|
||
| ### Import | ||
| Each source file can be imported independently in parallel. When importing a single source file, possibly multiple resulting assets will be assigned an AssetUUID each and they may have AssetID dependencies of three kinds: Build, load and instantiate. | ||
| In some cases these dependencies will be defined with the FilePath variant. After the import completes but before persisting metadata, the Asset Pipeline will attempt to resolve the FilePath dependencies of these assets to their AssetUUID equivalents. If the path cannot be resolved, the import will result in an error. This will ensure that the Asset Pipeline and all tools only have to handle stable AssetUUID references that map to specific assets regardless of the filesystem state. |
There was a problem hiding this comment.
In some cases these dependencies will be defined with the FilePath variant
This sentence is contradictory to the rest of this paragraph. I was actually a bit surprised until i've read the rest of it. I'd actually avoid the FilePath name specifically here, as it might be confusing. There is nothing special about filesystem paths really.
How about that?
In some cases, the asset source file might specify dependencies in any way, e.g. relative paths or other format-specific methods. After the import completes but before persisting metadata, the Asset Pipeline will attempt to resolve the dependencies of these assets to their AssetUUID equivalents in a format-specific way. If the dependency cannot be resolved, the import will result in an error.
| # Unresolved Questions | ||
| [unresolved-questions]: #unresolved-questions | ||
|
|
||
| An unresolved question I have is whether URI should be included at all (not needed for most common use case, but has been requested previously) and if it is to be included, which URI library should be used. |
There was a problem hiding this comment.
if we leave the special cases of paths or uris out of the system, this solves itself.
| If a user created a prefab using a prefab editor and references an asset in a file that was later renamed or moved, it would be unexpected for the reference to no longer resolve since the user did not specify a path in the prefab editor. In the case of loading an asset by file path in code, it would be be expected behaviour for the load to fail if a file is removed however. | ||
|
|
||
| URI is a general way of referencing an asset that does not exist in the filesystem and was not imported by the asset pipeline. An example of this could be an asset stored in a database somewhere that is specific to the game it is resolved in. URIs are included in AssetID as a point of further extension for game developers and will not be used by any of the initial Asset Pipeline systems. | ||
| The intention is to provide traits that can be implemented to make it easier to integrate custom IDs into the asset loading process. |
There was a problem hiding this comment.
This custom trait (let's name it AsessetAlias) is redundant with everything except the raw UUID. This reinforces my point of dropping other representations (or simply refactor the existing enum into a AsessetAlias trait with bunch of impls)
Rendered