* A bit of Generic DOM tidying/fixup
- Refactor out a test fixture for all DOM tests / benchmarks
- Optimize `GetType` implementation to not use `AZStd::variant::visit` (benchmark included to A/B the implementations)
- Tag a few more mutating Value functions with "Mutable" to avoid astonishing copy-on-writes
Benchmark results for GetType implementation:
```
DomValueBenchmark/AzDomValueGetType_UsingVariantIndex 18.2 ns 18.0 ns 40727273 items_per_second=443.667M/s
DomValueBenchmark/AzDomValueGetType_UsingVariantVisit 32.2 ns 32.2 ns 21333333 items_per_second=248.242M/s
```
Signed-off-by: Nicholas Van Sickle <nvsickle@amazon.com>
Fixed issue with Android NDK r23 native only builds where the platform version was ignored
Bumped the default ANDROID_NATIVE_API_LEVEL to 24 so it matches the Android project generator scripts
Removed some unnecessary information from message strings
Signed-off-by: AMZN-ScottR <24445312+AMZN-ScottR@users.noreply.github.com>
* Added a helper class for a group containing several histograms.
* The group is shown using collapsible header.
Signed-off-by: Benjamin Jillich <jillich@amazon.com>
Consolidated duplicate asset browser code from multiple tools into single class in atom tools framework
Moved creation of asset browser and Python terminal windows into base main window class
Fixed docked window orientations
Added checks to asset browser to prevent crashes if tree state saver was null
Signed-off-by: Guthrie Adams <guthadam@amazon.com>
Atom tools are set up to inherit and automatically load all of the gems used by the game project. This is a great simplification that saves us from having to manually update cmake settings for every game project to push dependencies to every tool. The tradeoff is that some dependencies will be added to certain tools that have no relevance whatsoever, potentially wasting initialization time, memory utilization, and some processing. This change follows an existing example to update a couple of tools to forego initializing unused gems. They can easily be reenabled as needed.
Signed-off-by: Guthrie Adams <guthadam@amazon.com>
Thumbnails for the AtomLyIntegration common feature gem were no longer being rendered. The setup code was modified to initialize the thumbnail system after receiving a new event that critical assets finished compiling. This event was being sent and handled correctly in the main editor. This process was failing in other tools because the event was sent before systems were registered to listen for it.
To resolve the problem, atom tools application now explicitly connects to the asset processor and processes critical assets after the base application StartCommon function is called. This ensures that the connection is established and the event gets sent after all of the system components have been activated.
Signed-off-by: Guthrie Adams <guthadam@amazon.com>
In some cases it may be acceptable to do non-const things in a const function as long as it is only manipulating internal data, and the public facing API returns the same values as before. But in this case, the IsFinalized function is a public facing API that would have a different result after GetPropertyValues was called.
I also updated a couple other minor things from code review feedback.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
I found a mistake where MaterialAssetCreator needs to clear the raw data when configured to finalize the material asset.
Since MaterialSourceData no longer relies on the material type source file at all, I was able to change MaterialSourceDataTest to avoid saving the source data to disk.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
I made MaterialAsset::Finalize private so I could add some parameters specifically for MaterialAssetCreator to use. Now MaterialAssetCreator::Begin has an option to finalize the material or not.
Moved MaterialAssetCreatorCommon::ValidateDataType to MaterialPropertyDescriptor as "ValidateMaterialPropertyDataType" so that MaterialAsset::Finalize could use it too
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
Before, the material builder was loading the MaterialTypeAsset and doing some processing with it, but was avoiding declaring job dependencies that would cause reprocessing lots of assets when a shader or .materialtype file changes. Reading the asset data isn't safe when not declaring a job dependency (or when declaring a weak job dependency like OrderOnce which is the case here). This caused to several known bugs.
The main change here is it no longer loads the MaterialTypeAsset at all; all other changes flow from there.
The biggest changes (when deferred material processing is enabled) are ...
1) MaterialSourceData no longer loads MaterialTypeAsset. All it really needs is to determine whether a string is an image file reference or an enum value, which is easy to do by just looking for the "." for the extension.
2) MaterialAssetCreator no longer produces a finalized material asset. It no longer uses MaterialAssetCreatorCommon because that only produces a non-finalized MaterialAsset, which has very different needs for the SetPropertyValue function. (We could consider merging MaterialAssetCreatorCommon into MaterialTypeAssetCreator since that's the only subclass at this point). And it doesn't do any validation against the properties layout since that can be done at runtime.
3) Moved processing of enum property values from MaterialSourceData to MaterialAsset::Finalize (this was the only thing being done in the builder that actually needed to read the material type asset data).
Also...
- Updated the MaterialAsset class mostly to clarify and formalize the two different modes it can be in: whether it is finalized or not.
- Merged the separate "IncludeMaterialPropertyNames" registry settings from MaterialConverterSystemComponent and MaterialBuilder into one "FinalizeMaterialAssets" setting used for both.
- Removed MaterialSourceData::ApplyVersionUpdates. Now the flow of data is the same regardless of whether the materials are finalized by the AP or at runtime. Version updates are always applied on the MaterialAsset.
- Added a validation check to MaterialTypeAssetCreator ensuring that once a property is renamed, the old name can never be used again for a new property. This assumption was already made previously, but not formalized, in that Material::FindPropertyIndex does not expect every caller to provide a version number for the material property name, also the material asset's list of raw property names was never versioned. The only way for this to be a safe assumption is to prevent reuse of old names.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
Gene Walters
jromnoa
Vincent Liu
Karl Berg
Nicholas Van Sickle
dmcdiarmid-ly
Mike Balfour
Junbo Liang
Danilo Aimini
Gene Walters
Scott Romero
Ignacio Martinez
Benjamin Jillich
Guthrie Adams
greerdv
santorac
Guthrie Adams
Luis Sempé
Chris Galvan
AMZN-byrcolin
jckand-amzn