* Add instanceToIgnore to calls leading to instances being added to the queue for propagation.
* Change PrefabUndoEntityUpdate to make it so that the instance triggering the prefab template change is not reloaded on propagation, since it will already be up to date due to the way we generated the patch to begin with.
* Add FindPrefabDomValue utility function for paths
* Expose the level root prefab template id in the Prefab EOS Interface
* Fix Instance Alias Path generation to work with the new FindValueInPrefabDom function
* Stop reloading ancestors on propagation, and fix instance reloading so that the level dom is used (and overrides are preserved)
* Remove commented out code, refactor FindPrefabDomValue for paths (was handling an edge case incorrectly, and it's not even triggered)
* Fix issue with PathView reference - with PathView already being a reference, this resulted in a copy and triggered a warning during automated review builds.
* Additional fix to the build warning, remove redundant error message
* Revert changes to Instance::GetAbsoluteInstanceAliasPath(), as they were impacting serialization.
* Remove the dependency to the level root prefab template in the propagation code, climb up the hierarchy instead. This allows tests to work despite not using the EOS properly.
Also use PrefabDomPaths to retrieve the instance dom from the root dom instead of iterating.
* Remove now unused PrefabDomUtils function, extend optimization to link updates.
* Trigger a full instance propagation to correctly refresh alias references.
This is an issue in the test because some operations are called from the backend API and will not trigger propagation properly. Tests will soon be rewritten to more properly represent frontend workflows.
* Fixes lingering issues with propagation:
- Restores code that fixes the selection if entityIds have changed;
- Fixes Do() function on link update. Prefab containers will propagate correctly while still being stable during editing.
* Remove GetRootPrefabInstanceTemplateId (no longer necessary after the code has been rewritten)
* Fix optimization code to account for instances being removed and propagation being run out of order in Create Prefab undo.
* Renamed variable, added comments for clarity.
* Restore asserts on instance not being found; Rename Do to Redo for clarity; Add comments.
* Fixed incomplete comment.
* formatting changes to AzToolsFramework viewport related types + API comment style updates
* minor format change - include ordering
* improve formatting by moving comment
* fix compile error and switch to use AZ_Printf
* small polish changes after review feedback
There are already APIs for getting a relative product path from an absolute source path, or getting a relative source path for an *existing* source file, but there were no APIs for getting a relative source path for a *new* source file. Prefabs will need this ability to be able to correctly generate a relative source path inside the prefab file before the file has been saved.
The logic for relative source paths is a little bit tricky because the paths are relative to the watch folders, and the watch folders can be nested, with different priorities to explain which should take precedence. The input paths can also include specifiers like "." and "..", which need to be reconciled before creating the final correct relative path. The included unit tests test all of the tricky edge cases that I was able to identify.
* add find entity in viewport functionality to new camera
* fix AZ_CVAR usage
* updates following review feedback
- updated comment styles from /// to //!
- retrieve fov of camera (add test for fov access)
* update namespace naming, fix AZ_CVAR usage
* update missed namespace and use AZ::Transform::CreateLookAt
* add missing include
* move EditorViewportSettings to EditorLib
* update DLL import/export API and rename namespace usage
* use new ViewportContext interface to set camera transform on load
* WIP fixes for camera viewport handler callbacks
* disable synchonization with old camera when new camera system is enabled
* further updates to camera-input
* ensure event is signalled when camera transform is set
* updates to ModernViewportCameraController
* fix for right click menu appearing with camera
* updates following review feedback
* convert std:: usage to AZStd::
* 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
srikappa-amzn
sconel
Danilo Aimini
Tom Hulton-Harrop
rgba16f
AMZN-koppersr
greerdv
Terry Michaels
Mike Balfour
SJ
Chris Galvan
Hasareej
karlberg
chiyenteng
lumberyard-employee-dm
guthadam
hultonha
Chris Burel
Esteban Papp