--------
Integrated using branch UE4-to-UE4-Fortnite-Simple (reversed) of change#2696404 by Geremy.Mustard on 2015/09/17 20:13:36.
[CL 2696406 by Geremy Mustard in Main branch]
#UE4 Deleting FBackgroundAssetData as it is not really needed anymore. All instances were replaced with FAssetData.
#RB Ben.Zeigler
--------
Integrated using branch Ue4-To-UE4-Fortnite-Simple (reversed) of change#2664545 by Bob.Tellez on 2015/08/21 12:03:24.
[CL 2664727 by Bob Tellez in Main branch]
FAssetRegistry::DependencyDataGathered was potentially replacing hard asset dependencies with soft asset dependencies, but the hard asset dependencies need to take precedence.
[CL 2654899 by Jamie Dale in Main branch]
The CachePath function of FPathTree (formerly FPathTreeNode) used to always test each component part of a path to ensure that the path was available in the tree. This not only involved always performing an FName -> FString conversion for each path that was found by the asset registry, but it also resulted in repeated work being performed when the path was already fully cached.
The new FPathTree contains a map of full parent paths to full child paths (all using FName), which allows it to early out if it's already cached the path in question. This not only avoids the repeated work, but also avoids several FName -> FString -> FName conversions that used to happen between adding a path, and then retrieving it again later (the path would previously be rebuilt from its component FString parts, and then converted back into an FName - now it just uses the FName that we already have in the map).
These changes can dramatically improve the asset registry processing performance for large projects.
[CL 2654839 by Jamie Dale in Main branch]
- Friendly name will no longer be serialized
- Reduced memory footprint of friendly names
- Faster custom version look up when serializing many custom versions
[CL 2646438 by Robert Manuszewski in Main branch]
Previously, the file discovery phase of the asset gathering process would block the entire process until it had found all of the files it needed to test.
This can take quite some time for projects with a large amount of assets, so this change adjusts the process so that discovered paths will be reported back to the asset registry while the file discovery is on-going. This allows you to prioritize the scanning of certain folders before the initial discovery phase has finished.
To account for the fact that the asset registry will be reporting process of an unknown range, the asset discovery indicator has been updated to display a marquee bar until the initial file discovery has finished.
It will now show you the following messages:
- "Initializing Asset Discovery" - Loading the cached asset registry data and waiting for the file scan to start. The progress bar will marquee while this is happening.
- "Discovering Asset Files" - Shows an increasing count of the number of asset files that have been discovered on disk. The progress bar will marquee while this is happening.
- "Discovering Asset Data" - Shows a decreasing count of assets that need to have their asset data either read from disk, or copied from the cache file. The progress bar will show the percentage of the assets processed by the asset registry compared to the total number of assets to load and process.
- "Processing Asset Data" - Shows a decreasing count of assets that the asset registry still needs to process the gathered asset data for. The progress bar will show the percentage of the assets processed by the asset registry compared to the total number of assets to load and process.
One side effect of having the discovery phase scan go wide (rather than deep - to allow you to prioritize the scanning of certain folders) is that it may now report back folders that don't contain any assets. This essentially addresses a long time complaint from users, whereby the Content Browser wouldn't show empty folders.
This change also has the cached asset registry file write out for every 50,000 files that are read from disk. This avoids you needing to perform repeated work if you restart the editor before the entire scan has finished.
[CL 2644762 by Jamie Dale in Main branch]
#UE4 Fix non-monolithic builds. Moved asset registry tag whitelisting logic out of FAssetData and into FAssetRegistry::SaveRegistryData
--------
Integrated using branch Ue4-To-UE4-Fortnite-Simple (reversed) of change#2643049 by Bob.Tellez on 2015/08/04 00:03:19.
[CL 2643050 by Bob Tellez in Main branch]
#UE4 Asset registry tags are now excluded from builds unless they are added to the CookedTagsWhitelist which can be configured in BaseEngine.ini. For full backward compatability add +CookedTagsWhitelist=(Class=*,Tag=*), but it will bloat your memory usage.
--------
Integrated using branch Ue4-To-UE4-Fortnite-Simple (reversed) of change#2642971 by Bob.Tellez on 2015/08/03 22:46:20.
[CL 2642973 by Bob Tellez in Main branch]
FPackageName::IsValidLongPackageName would fail for the root paths as the mount path roots all end with a trailing slash, however FPackageName::IsValidLongPackageName doesn't accept paths that end in a trailing slash (as it's expected to be working with names, not paths).
This change updates FAssetDataGatherer::PrioritizeSearchPath to use FPackageName::TryConvertLongPackageNameToFilename instead (which will gracefully fail on an invalid path), and SPathView makes sure that it appends a trailing slash to the path it gives to FAssetDataGatherer::PrioritizeSearchPath.
[CL 2642169 by Jamie Dale in Main branch]
The discovery phase now uses the fact that the stat data for a file is available up-front to perform the check against the cached timestamp immediately. On Windows, and for the cases where most or all of the data is cached, this can significantly improve the asset registry gathering time as it avoids performing a second scan of the file-system for the majority of the files.
[CL 2634348 by Jamie Dale in Main branch]
All changes regarding e-mail discussion titled "Asset registry shenanigans".
Changes:
1. Engine now actively is getting rid of short asset paths in FStringAssetReference during saving (for all packages) and loading (only for older packages).
2. Deprecated direct access to FStringAssetReference.AssetLongPathname and exposed it via ToString and SetPath -- SetPath is making sure the path is in correct format. If the path can't be found on disk, the path is cleared.
3. Also access to FStringAssetReference.AssetLongPathnam via Blueprints is guarded using custom Make node function that uses SetPath instead of simple assign.
4. StringAssetReferenceMap will now contain only paths to packages (not objects) and ini references
5. GetDependencies now has additional parameter that lets you chose if it should resolve ini references or not. It was left not as default to keep old behaviour.
[CL 2630589 by Jaroslaw Palczynski in Main branch]
#UE4 Softer error handling when reading the asset registry cache. All errors will just cause the cache to regenerate.
--------
Integrated using branch Ue4-To-UE4-Fortnite-Simple (reversed) of change#2622128 by Bob.Tellez on 2015/07/15 14:34:24.
[CL 2622133 by Bob Tellez in Main branch]
It would previously find an FAssetData in the cached asset registry, and then pass it to FBackgroundAssetData which would copy the tags and values map, and perform at least 6 FName -> FString conversions, before ultimately converting all of these FStrings back to FNames when FBackgroundAssetData::ToAssetData was called.
This change makes FBackgroundAssetData implement an interface (IGatheredAssetData), and adds FAssetDataWrapper to more efficiently wrap up an FAssetData that was read from the cached asset registry.
This saved 2-3 seconds when loading the largest project I have available (previously ~18 seconds, now ~15 seconds).
[CL 2620726 by Jamie Dale in Main branch]
