Made Model Material Conversion Optional
Added a new registry setting that disables automatic conversion of materials from model files like FBX.
By default, processing of model files (like FBX) automatically convert the included materials to Atom materials, using StandardPBR. This adds a job dependency on StandardPBR.materialtype, which propagates to any related azsl files as well. Thus any change to azsl code will cause all model files in the project to rebuild.
Some game teams have no interest in using the auto-converted materials; they always use a Material Component to apply material overrides for every mesh. This new setting allows teams to disable material auto-conversion for the entire project, thus removing the job dependency on StandardPBR.materialtype. Instead, every mesh will be assigned the same default material. Any change to azsl code will cause that one default material to rebuild, but this will not trigger any models to rebuild.
Details:
- Added /O3DE/SceneAPI/MaterialConverter registry settings for configuring the scene material converter. It includes an enable flag, and a default material to use when conversion is disabled.
- Added SceneBuilderDependencyRequests::AddFingerprintInfo which allows SceneAPI components to modify the scene builder analysis fingerprint. We use this to reprocess scene files when the material converter settings change.
- Updated SceneAPI's material asset builder to skip the StandardPBR dependency when material conversion is disabled.
- Added some code to MaterialComponentController to handle an edge case that may when disabling material conversion on an existing project, and assigned materials disappear.
Testing:
- Changing the registry setting does trigger a rebuild of the fbx files.
- When material conversion is disabled, changing an azsl file does not cause fbx files to rebuild, but the shader still reloads as expected.
- Made a test level using multiple models with multiple meshes, made various adjustments to the material slots for each mesh, and tried switching the material conversion registry setting from true to false. (Details below)
- Merged this change to a customer's fork and tested on their existing content.
Details about my test level:
- Made a new test level AtomTest project
- Added two entities, both using multi-mat_mesh-groups_1m_cubes.fbx
- Added a material component to both entities
- Entity 1 material assignments
- Blue_Zaxis: left as-is
- Green_Yaxis: exported the material
- Red_Xaxis: exported the material, and changed the material instance color to pink
- StingrayPBS1: exported the material, scaled the UVs in the exported material source, and changed the material instance color to green.
- With_Texture: selected an existing brick material, changed the material instance color to red.
- Entity 2 material assignments
- Default Material: set to an existing brick material
- Blue_Zaxis: manually assigned built-in material that was converted from fbx
- Green_Yaxis: manually assigned built-in material that was converted from fbx, and changed the material instance color to orange
Change all name parameters to use standard string so that they could be headed in in script canvas nodes and RPE
Added explicitly type functions for getting and saving property overrides
Signed-off-by: Guthrie Adams <guthadam@amazon.com>
By default, processing of model files (like FBX) automatically convert the included materials to Atom materials, using StandardPBR. This adds a job dependency on StandardPBR.materialtype, which propagates to any related azsl files as well. Thus any change to azsl code will cause all model files in the project to rebuild.
Some game teams have no interest in using the auto-converted materials; they always use a Material Component to apply material overrides for every mesh. This new setting allows teams to disable material auto-conversion for the entire project, thus removing the job dependency on StandardPBR.materialtype. Instead, every mesh will be assigned the same default material. Any change to azsl code will cause that one default material to rebuild, but this will not trigger any models to rebuild.
Details:
- Added /O3DE/SceneAPI/MaterialConverter registry settings for configuring the scene material converter. It includes an enable flag, and a default material to use when conversion is disabled.
- Added SceneBuilderDependencyRequests::AddFingerprintInfo which allows ScenePI components to modify the scene builder analysis fingerprint. We use this to reprocess scene files when the material converter settings change.
- Updated SceneAPI's material asset builder to skip the StandardPBR dependency when material conversion is disabled.
- Added some code to MaterialComponentController to handle an edge case that may when disabling material conversion on an existing project, and assigned materials disappear.
Testing:
- Changing the registery setting does trigger a rebuild of the fbx files.
- When material conversion is disabled, changing an azsl file does not cause fbx files to rebuild, but the shader still reloads as expected.
- Made a test level using multiple models with multiple meshes, made various adjustments to the material slots for each mesh, and tried switcihng the material conversion registry setting from true to false. (Details below)
- TODO: Will merge this change to a customer's fork and test on their existing content.
Details about my test level:
- Made a new test level AtomTest project
- Added two entities, both using multi-mat_mesh-groups_1m_cubes.fbx
- Added a material component to both entities
- Entity 1 material assignments
- Blue_Zaxis: left as-is
- Green_Yaxis: exported the material
- Red_Xaxis: exported the material, and changed the material instance color to pink
- StingrayPBS1: exported the material, scaled the UVs in the exported material source, and changed the material instance color to green.
- With_Texture: selected an existing brick material, changed the material instance color to red.
- Entity 2 material assignments
- Default Material: set to an existing brick material
- Blue_Zaxis: manually assigned built-in material that was converted from fbx
- Green_Yaxis: manually assigned built-in material that was converted from fbx, and changed the material instance color to orange
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
Removed code that was intended to handle duplicate default material assignments, but duplicacate default material assignments aren't possible yet.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
Also, I'm going back on what I said in my last commit, and removing the converter for version 3 in EditorMaterialComponent::ConvertVersion. The code that I had put in before wouldn't work because it was relying on the new m_defaultMaterialAsset which will be empty for old data. The only way we could support version conversion is if we preserve legacy versions of multiple types like EditorMaterialComponentSlot and MaterialAssignmentId. Since this serialization version is old and pre-dates the public release of O3DE, it's unlikely that we need to continue supporting this version so isn't worth maintaining.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
Updated OpenMaterialExporter() to account for the fact that multiple material slots can have the same default material asset.
Updated the material inspector to sort material slots by name to match the order in the Material Component.
Updated ExportItem to protect its data members, which makes it more clear that assetId and materialSlotName are readonly inputs.
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
Here we inttroduce a new struct ModelMaterialSlot which formalizes the concept of material slot, with an ID, display name, and default material assignment. The ID still comes from the MaterialUid like before. The display name is built-in, rather than being parsed out from the asset file name. And the default material assignment can be any material asset, it doesn't have to come from the FBX (or other scene file).
This commit is just the preliminary set of changes. Cursory testing shows that it works pretty well but more testing is needed (and likely some fixes) before merging.
Here is what's left to do...
Add serialization version converters to preserve prior prefab data.
See if we can get rid of GetLabelByAssetId function only rely on the display name inside ModelMaterialSlot.
I'm not sure if the condition for enabling the "Edit Material Instance..." context menu item is correct.
Test actors
Lots more testing in general
Signed-off-by: santorac <55155825+santorac@users.noreply.github.com>
* Final update copyright headers to reference license files at the repo root
Signed-off-by: spham <spham@amazon.com>
* Fix copyright validator unit tests to support the stale O3DE header scenario
Signed-off-by: spham <spham@amazon.com>
The clear material override properties button was not sending the notification to update the entity or undo state.
Signed-off-by: guthadam <guthadam@amazon.com>
- Renamed "Details" group to "Overview".
- Renamed "UV Names" group to "UV Sets".
- Renamed "General" group to "General Settings".
- Renamed "Parallax" group to "Displacement".
- Renamed "Texture Map" properties to just "Texture". In cases where a specific type of texture is mentioned like "roughness texture map" I called this "roughness map" (which is more common according to google).
- Renamed "Heightmap" to "Height map" (which is more common according to google).
ATOM-14002 [Material Editor] Revisit user facing organization and layout of material types
There were two issues fixed here. First, I broke the material inspector with my changes at 53188a12da which added support for hiding entire property groups. I'm not sure how this happened because I definitely tested the MaterialComponent's material inspector. Perhaps there was a bad merge or something otherwise got clobbered after testing and before committing. Anyway, this issue was I accidentally delete the code that prepared the list of material properties for functor processing.
The second issue was the MaterialFunctor class needs to return null when metadata can't be found; it was proceeding to dereference an end iterator.
Testing:
Successfully opened the material inspector through the MaterialComponent. Was able to change property flags in the inspector and see other properties change visibility as expected.
The structure of InspectorWidget::m_groups changed, so I had to update my new code accordingly.
Updated the InspectorWidget::m_groups code a bit to be more readable.
Discovered the initial property group visiblity state wasn't being set correctly when a material was first opened, so groups weren't initially hidden when they should have been. This had to be fixed in different ways for MaterialEditor's inspector and MaterialComponent's inspector.
ATOM-14688 Disable Individual Layers
ATOM-14688 Disable Individual Layers
- Added new SetMaterialPropertyGroupVisibility functions to the material functors.
- Updated the MaterialFunctor::EditorContext to include parameters for handling material property group metadata.
- Updated the material inspector(s) to apply the property group visiblity changes from the material functor, to hide or show the property groups.
- Moved some code from MaterialPropertyDescriptor.h/cpp to a new MaterialDynamicMetadata.h/cpp, since these aren't really related to the MaterialPropertyDescriptor code. It's more for material functors to use.
- Also fixed the casing for the "GetMaterialPropertyValue_Image" lua function, since I was already in this code (ATOM-14793 "Fix Inconsistent Casing For LuaMaterialFunctorRuntimeContext")
Tested in MaterialEditor and in in the main Editor's MaterialComponent property override inspector.
Saving main window fancy docking state so all of the dock widgets save/restore visibly and positioning
Added window decoration wrapper inside material editor main window for saving/restoring window position, size, state
Added object names to several QT widgets so that their state could be captured and restored
Moved the code that automatically appended a script variable name to a property description out of the dynamic property class and into the material property conversion utility functions.
Added proper descriptions for the material type and parent material placeholder properties
https://jira.agscollab.com/browse/ATOM-14065
This replaces grid hub usage in the material editor. It allows material editor and other tools to intercommunicate on the local host. This will allow enforcing that there is only one instance of the material editor running. Opening a second instance will forward command line options to the first instance running a local server.
https://jira.agscollab.com/browse/ATOM-15439https://jira.agscollab.com/browse/ATOM-13742
* LYN-2537 Moved the Engine and Editor folder to be within the EngineAssets folder
* Fixed Documentation in bootstrap.cfg to correct the path to the user project specific registry file
* Adding a newline to the output of AssetCatalog 'Registering asset..., but type is not set' message
* Updating the AssetProcessorPlatformConfig.setreg Scan Folder to detect
the @ENGINEROOT@/EngineAssets/Engine path for engine runtime assets and
@ENGINEROOT@/EngineAssets/Editor path for engine tool assets
* Updating references to Icons and other assets to account for moving the
Engine and Editor folder under a single EngineAssets folder
* Moving the Engine Settings Registry folder from Engine/Registry -> Registry
* Removed the LY_PROJECT_CMAKE_PATH define as it is not portable to other locations. It is hard coded to the project location that was used for the CMake configuration. Furthermore it paths with backslashes within it are treated as escape characters and not a path separator
* Updated the LyTestTools asset_processor.py script to copy the exclude.filetag from the EngineAssets/Engine directory now
* Fixed Atom Shader Preprocessing when running using an External Project
* Updated the TSGenerateAction.cpp to fix the build error with using a renamed variable
* Updated the Install_Common.cmake ly_setup_others function to install the
EngineAssets directory and the each of the Gem's Assets directory while
maintaining the relative directory structure to the Engine Root
Also updated the install step to install the Registry folder at the
engine root
* Fixed the copying of the Registry folder to be in the install root, instead of under a second 'Registry' folder
* Moving the AssetProcessorPlatformConfig.setreg file over to the Registry folder
* Updated the LyTestTools and C++ code to point that the new location of
the AssetProcessorPlatformConfig.setreg file inside of the Registry
folder
* Renamed Test AssetProcessor*Config.ini files to have the .setreg extension
* Converted the AssetProcessor test setreg files from ini format to json
format using the SerializeContextTools convert-ini command
* Updated the AssetProcessor CMakeLists.txt to copy over the test setreg files to the build folder
* Updated the assetprocessor test file list to point at the renamed AsssetProcessor*Config setreg filenames
* Removed the Output Prefix code from the AssetProcessor. The complexity that it brought to the AP code is not needed, as users can replicate the behavior by just moving there assets underneath a another folder, underneath the scan folder
* Adding back support to read the AssetProcessorPlatformConfig.setreg file from the asset root. This is only needed for C++ UnitTests as they run in an environment where the accessing the Engine Settings Registry is not available
* Updating the Install_common.cmake logic to copy any "Assets" folder to
the install layout.
The Script has also been updated to copy over the "Assets" folder in the
Engine Root to the install layout instead of an "EngineAssets" folder
* Updating References to EngineAssets source asset folder in code to be the Assets source folder
* Moved the Engine Source Asset folder of 'EngineAssets' to a new folder name of 'Assets'. This is inline with the naming scheme we use for Gem asset folders
* Adding the EngineFinder.cmake to the AutomatedTesting project to allow it to work in a project centric manner
* Updating the LyTestTools copy_assets_to_project function to be able to copy assets with folders to the temporary project root
Fixed an issue in LyTestTools where the temporary log directory could have shutil.rmtree being called twice on it leading to an exception which fails an automated test
Updated the asset_procesor_gui_tests_2 AddScanFolder test to not use the
output prefix, but instead place the source asset root into a
subdirectory
* Correct the AssetProcessorPlatformConfig Scan Folders for the EngineAssets directory to point at the Assets directory
* Updated the asset procesor batch dependency test scan folder to point at the 'Assets' folder instead of 'EngineAssets'
TLDR
Thumbnails size will be removed from the system.
Each thumbnail class is responsible for determining its stored size.
Images and other thumbnail types can be scaled up or down within reason without blurring.
The thumbnail system uses the concept of context and size organize thumbnails by size based on their intended use. However, most of the thumbnail classes do not respect or use the specified size, which is 16 by 16 pixels and really only usable for small icons.
The thumbnails are currently being used in the asset browser tree control, the larger asset browser previews, the material component property asset controls, the material component inspector for the large preview, and other places. Each of these places use completely different sizes, some of which are large and change dynamically. Whenever the thumbnails are painted they are scaled to the desired size.
Material and mesh thumbnails were always being captured at 512x512 regardless of what the rest of the thumbnail system said. Source, product, and folder thumbnails would be stored at the original asset size. The loading movie thumbnail was always drawn at 16 by 16 and scale up so it was always blurry. Image thumbnails were always scaled down to 16 by 16 and scale up for larger previews.
Rather than worrying about the size of each context, each thumbnail class will store the image at whenever it deems to be a large enough size that can be scaled down when used.
This may eliminate the need for multiple thumbnail contexts which are not being used anyway.
https://jira.agscollab.com/browse/ATOM-15370
santorac
Esteban Papp
Guthrie Adams
pappeste
Guthrie Adams
Chris Santora
sphrose
Steve Pham
Twolewis
AMZN-stankowi
Terry Michaels
mnaumov
lumberyard-employee-dm
AMZN-mnaumov
alexpete