* Implemented the RFC to allow projects to need to specify the Gems
Projects no longer need to specify CMake Targets to associate a Gem
variant with.
In order to associate a CMake Target with a gem variant a new
`ly_set_gem_variant_to_load` function has been added that maps CMake
Targets -> Gem Variants.
This allows CMake Targets to self describe which gem variants they
desire to build and load
This implementation is backwards compatible:
The `ly_enable_gems` function still accepts the TARGETS and VARIANTS
arguments which it will forward to the new `ly_set_gem_variant_to_load`
function to allow the input Targets to be associated with input Gem
Variants
This changes fixes the issue with gems that are required by an
Application regardless of the Project in use, not replicating it's
"requiredness" to the SDK layout
Fixes#3430
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Added an LY_PROJECT_NAME property to the Launcher targets
The `ly_enable_gems_delayed` now command queries the LY_PROJECT_NAME property
associated with each target to determine if the gems being enabled are
match the project the target is associated with.
In this case the target only adds dependencies if the gems is being enabled
without a specific project or if the gems is being enabled for the
matching project.
If the LY_PROJECT_NAME property is not set for target, it indicates the
gems for each project can be added as dependencies to the target.
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* The INSTALL step now forwards the LY_PROJECT_NAME property for a target
The Install_common.cmake has been updated to support configuring
TARGET_PROPERTIES into the generated CMakeLists.txt for install targets.
Furthermore the indentation of the generated CMakeLists.txt has been
normalized to help with readability
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Updating the Atom_Bootstrap CMakeLists.txt to enable the Atom_Bootstrap Gem
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Added a deprecation message to ly_enable_gems when supplying TARGETS and
VARIANTS
Added a define_property call for the LY_PROJECT_NAME target property
Removed the .Builders alias for the PrefabBuilder and renamed the
GEM_MODULE target o PrefabBuilder.Builders.
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Removed superflous space from AutomatedTesting Gem CMakeLists.txt
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
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
Moved BuildDebugSceneGraph out of SceneProcessing gem and into DebugOutput class to allow the function to be shared, which ensures the same dbgsg format is outputted among any calls to the function.
* Move BuildDebugSceneGraph function, update all calls to this function
Signed-off-by: Victor Huang <huavicto@amazon.com>
* Remove unused includes
Signed-off-by: Victor Huang <huavicto@amazon.com>
* Remove z
Signed-off-by: Victor Huang <huavicto@amazon.com>
These changes allow for usage of different asset import SDKs to process scene files.
Move AssImp specific code out of node, scene & material wrapper parent classes and into child wrapper classes (AssImpNodeWrapper, etc.), allowing child classes to expose import SDK code. Allows for more convenient implementation of other import SDK's elsewhere (such as in a gem).
Add a loadingComponentUuid parameter to LoadSceneFromVerifiedPath to allow for usage of different loading components. Changed tests and all calls to this function accordingly.
* Move AssImp specific code out of wrapper parent classes and into child classes for gem usage
Signed-off-by: Victor Huang <huavicto@amazon.com>
* Add loadingComponentUuid parameter to LoadSceneFromVerifiedPath function
Signed-off-by: Victor Huang <huavicto@amazon.com>
* Make wrapper members protected, change pointer cast
Signed-off-by: Victor Huang <huavicto@amazon.com>
* Adding spaces to fix style
Signed-off-by: Victor Huang <huavicto@amazon.com>
* Fix for pointer cast causing test failures
Signed-off-by: Victor Huang <huavicto@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>
* Added TSpace method setting which is only visible for MikkT generation.
* Fixed a bug with generating tangents for blend shapes.
* Renamed tangent space into generation method.
* Some code cleaning
Signed-off-by: Benjamin Jillich <jillich@amazon.com>
The previous version returned the incorrect size from the position map when
blendshapes are present in the model. When there are blendshapes, the
vertex welding is disabled, and nothing is inserted into the position map.
However, the position map's size was being used to dictate how many
elements to create in the skinning info. The skinning info tries to
compensate for an incorrect max vertex index by resizing its underlying
vector when adding an influence, but that was using the index as the new
size of the vector, so it was off by one. This fixes both errors.
Signed-off-by: Chris Burel <burelc@amazon.com>
* Default setting when no tangents rule: MikkT tangents.
* Calculates tangents/bitangents for all available uv sets.
* Creates tangent/bitangent data in in case they are not existing yet (as in: the source scene contains tangents/bitangents)
* Overwrites the tangent/bitangent data from the source scene in case MikkT is wished.
* Added helper functions to create tangent/bitangent scene nodes, finding tangent/bitangent data for a given uv layer and calculating the number of uv layers provided by the mesh scene node.
Signed-off-by: Benjamin Jillich <jillich@amazon.com>
This fixes a bug where a Python script file would be run on a scene file
that didn't have a script file set.
Added a general case version to SceneBuilderWorker.cpp, to make it easy
to mark all scene files as dirty.
Automated tests for this will come in a separate pull request.
Signed-off-by: stankowi <4838196+AMZN-stankowi@users.noreply.github.com>
The thought behind Array2D was that it would be more efficient from a
memory allocation perspective to have one fixed buffer that grows than
it would be to have a vector of vectors. In reality, the runtime of
inserting into the middle of one large buffer, and shifting all the
resulting elements, ends up far outweighing any memory allocation
overhead.
In the mesh optimizer, things are added to the end of each sub-vector
one by one. It isn't known up front how many elements each sub-vector
will have. With vertex welding enabled, it is far more likely that a
given vertex will be influenced by a large number of joints. When using
the Array2D to store the influences, and a vertex with a low index has
more than 4 influences, those influences have to be inserted into close
to the front of the big vector, and all the other elements shifted.
Array2D was doing this with a linear shift, shifting the elements by 1
at a time, and not providing any exponential growth on the amount of
elements reserved by each sub-vector. The result is a linear insertion
time.
By contrast, using vector<vector<Influence>> instead gives us back the
amortized constant insertion time. Since the skin influences are just
added to the end of each sub-vector, no shifting of the elements is
necessary. And since the amount of original vertex indices is known up
front, the number of sub-vectors can still be pre-created, so the
sub-vectors themselves never need to shift.
Signed-off-by: Chris Burel <burelc@amazon.com>
The Assimp library does not expose the FBX control point indices. This
change causes vertices that are close enough in their position to be
considered as coming from the same control point. This allows the mesh
optimizer to consider vertices with the same control point index (or
"original vertex index" as it is called in the code) for deduplication.
Signed-off-by: Chris Burel <burelc@amazon.com>
* Determine the original vertex index based on the position
The Assimp library does not expose the FBX control point indices. This
change causes vertices that are close enough in their position to be
considered as coming from the same control point. This allows the mesh
optimizer to consider vertices with the same control point index (or
"original vertex index" as it is called in the code) for deduplication.
Signed-off-by: Chris Burel <burelc@amazon.com>
* Use a filter view instead of reimplementing a filter view
Signed-off-by: Chris Burel <burelc@amazon.com>
* Don't attempt to weld similar vertices if there's blendshapes
Signed-off-by: Chris Burel <burelc@amazon.com>
* Add test for the mesh optimizer's ability to weld nearby vertices
Signed-off-by: Chris Burel <burelc@amazon.com>
* Add logging call to show mesh optimizer effect on vertex count
Signed-off-by: Chris Burel <burelc@amazon.com>
* Use a bunch of temporaries in order to make `position` `const`
Signed-off-by: Chris Burel <burelc@amazon.com>
* Supply the vertex index remapping to the optimized skin weights
This ensures that the optimized skin weights use the vertex indexes from
the optimized mesh
Signed-off-by: Chris Burel <burelc@amazon.com>
* Update the Mac Editor plist application bundle identifier to be different than Lumberyard
Fix the editor to have runtime dependencies on the scene modules.
Signed-off-by: rgba16f <82187279+rgba16f@users.noreply.github.com>
* Fix Metal RHI calling unsupported timestamp query api on M1 Macs.
Add Query for Timestamps supported on device initialization.
Signed-off-by: rgba16f <82187279+rgba16f@users.noreply.github.com>
* Remove AZ::Scene* runtime dependencies from EmotionFX gem and add AZ::SceneUI as a runtime dependency of SceneProcessing::Editor module.
Signed-off-by: rgba16f <82187279+rgba16f@users.noreply.github.com>
* Determine the original vertex index based on the position
The Assimp library does not expose the FBX control point indices. This
change causes vertices that are close enough in their position to be
considered as coming from the same control point. This allows the mesh
optimizer to consider vertices with the same control point index (or
"original vertex index" as it is called in the code) for deduplication.
Signed-off-by: Chris Burel <burelc@amazon.com>
* Use a filter view instead of reimplementing a filter view
Signed-off-by: Chris Burel <burelc@amazon.com>
* Don't attempt to weld similar vertices if there's blendshapes
Signed-off-by: Chris Burel <burelc@amazon.com>
* Add test for the mesh optimizer's ability to weld nearby vertices
Signed-off-by: Chris Burel <burelc@amazon.com>
* Add logging call to show mesh optimizer effect on vertex count
Signed-off-by: Chris Burel <burelc@amazon.com>
* Use a bunch of temporaries in order to make `position` `const`
Signed-off-by: Chris Burel <burelc@amazon.com>
* First pass FBX -> Scene File conversion.
This is the simple pass, minimizing code changes and focused on comments.
Signed-off-by: stankowi <4838196+AMZN-stankowi@users.noreply.github.com>
* Step 1 of part 2 of the FBX -> Scene rename
Signed-off-by: stankowi <4838196+AMZN-stankowi@users.noreply.github.com>
* Renaming FbxSceneBuilder folder to SceneBuilder
Signed-off-by: stankowi <4838196+AMZN-stankowi@users.noreply.github.com>
* Renamed files
Signed-off-by: stankowi <4838196+AMZN-stankowi@users.noreply.github.com>
* More FBX -> Scene
Signed-off-by: stankowi <4838196+AMZN-stankowi@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>
* Fixed organization of the AssetProcessor SourceAssetBrowser
Assets within the Engine Root were grouped under a '/' entry.
That has been fixed to use the relative path within the engine root for
those assets
Assets outside of the Engine Root, but on the same drive were using
absolute paths before. Now there are child entries that navigate up the
directory hierarchy to those asset locations
* Added ly_enable_gems call to Atom gems targets that are required
The DefaultLevel.prefab contains several Atom components, that require
the Atom RHI, RPI, Common_Feature, ShaderBuilder and AtomLyIntegration CommonFeatures
gems to be enabled in order to successfully process in the
AssetProcessor.
* Added ly_enable_gems call to make the Camera gem required in Tools,
Builders and Clients.
This is needed as the DefaultLevel.prefab contains an Editor Camera
Component
* Adding the ly_enable_gem call to make the Maestro gem required
CrySystem currently requires Maestro to be enabled in order to
initialize
* Added ly_enable_gems call to the SceneProcessing gem to make it required
The SceneCore and SceneData libraries that are part of the core engine
Code folder requires the SceneProcessing gem to be enabled in order to
invoke the InitializeDynamicModule hooks in DllMain.cpp in order to
initialize those libraries.
* Fixed bad argument in comment for Prefab CMakeLists.txt
* Fixed Assert in Asset Builders due to the Atom RPI Builder
The Atom RPI Builder was enabling the Asset Catalog for the ScriptAsset a second time
The Atom Feature Common EditorSystemCommonComponent.cpp which also loads
in the AssetBuilder is enabling the Asset Catalog for the ScriptAsset
Added BehaviorContext reflection to the OutputDeviceTransformType enum
to fix the BehaviorContext errors about reflecting a method that returns
such an enum
* Added TypeId output to the JsonDeserializer report message about missing
ClassData
Previously the report callback would indicate that the target type was
missing Serialization class data, but didn't indicate the TypeId of the
target type
* Added support to the ly_enable_gems function to be able to support
0 gems being enabled.
Updated the Install step for CMake to propagate any ly_enable_gems
within a CMakeLists.txt for a target into the generated CMakeLists.txt
that is made for each installed IMPORTED target
* Adding newline to the end of the Camera Gem CMakeLists.txt
* Fixing target TYPE parameter for actual Gem Modules to use the GEM_MODULE tag instead of MODULE
* Reverting change to the DESTINATION directory for the installed CMakeLists.txt to use the relative path to the installed directory
* Adding the Atom_Bootstrap gem as a required gem
The Client and GameLaunchers required the Atom_Bootstrap gem in order to create the NativeWindow
Added Atom_Feature_Common client module as a runtime dependency of the AtomLyIntegration CommonsFeature client module
* Fixed register.py --all-projects-path and --all-gems-path arguments to
NOT register projects or gems that are within a template folder
Fixed reading of old pre-1.0 o3de_manifest.json files where the
"engines" key was a json array
* Changed how the relative target source directory is calculated when that source directroy resides outside of the engine root.
The final dirname component is used with a unique SHA256 has to form a <dirname>-<8 char SHA256> folder for installing files into
* Adding newline to the end of Atom_Bootstrap CMakeLists.txt
* Moving ly_enable_gems variants for Tools and Builders inside of PAL_TRAIT_BUILD_HOST_TOOLS block
* Adding a comment to AWSCore.ResourceMappingTool target to indicate that it is not a GEM_MODULE.
Furthermore it cannot be loaded with the Gem system because the library is in a different directory the executable
lumberyard-employee-dm
Chris Galvan
santorac
Esteban Papp
Jeremy Ong
amzn-victor
Benjamin Jillich
Chris Santora
pappeste
Chris Burel
Benjamin Jillich
AMZN-stankowi
Steve Pham
hultonha
rgba16f