Open 3D Engine (O3DE) is an Apache 2.0-licensed multi-platform AAA Open 3D Engine

Build url: https://jenkins.build.o3de.org/job/O3DE/job/development/1794/ Identified problems:

• Test error: Errors while running CTest
  • Indication 1: https://jenkins.build.o3de.org//job/O3DE/job/development/1794/consoleFull#-95944757160f5c32df5baa2a40af90ad8

Build url: https://jenkins.build.o3de.org/job/O3DE/job/development/1464/ Identified problems:

• Test error: Errors while running CTest
  • Indication 1: https://jenkins.build.o3de.org//job/O3DE/job/development/1464/consoleFull#-142152554260f5c32df5baa2a40af90ad8

implement manipulators for TransformMode. At the moment I'll just limit it to manipulate polygon faces. There are some things that can be added to improve this more but I'll just limit this change to just the faces to just get the basic functionality there.

Translation

Rotation

https://user-images.githubusercontent.com/854359/173252642-e6bc1dcc-238d-4ed7-b2cd-103e69fa9524.mp4

Scale

https://user-images.githubusercontent.com/854359/173252640-65ef0d33-2f7f-40a2-ab82-023ebe10e3d3.mp4

At the moment the selection is only limited to selecting faces only but I think can be be expanded to allow manipulating faces/edges/vertices. At the moment all the manipulation are in local space I can see this working in normal space i.e the normal of the selected polygon or the average if there are multiple. I can also see view space i.e from the perspective of the camera.

Signed-off-by: Michael Pollind [email protected]

[Migrated from JIRA LYN-12677]

Please see attached video regarding the current workflow on how to create, edit and remove node groups.

The whole Node Groups window shall be removed and all of its functionality shall move to the context menu of the graph window.

Acceptance Criteria:

• A new node group can be added when bringing up the context menu in empty graph space. A pop-up window will ask for the name as well as the color for the node group.
• Node groups can be deleted via the context menu. The "Node Groups" menu item currently can only be accessed when having a node selected that is part of the group. This needs to be changed and that menu item needs to be accessible any time. Each node group can get a sub-element to remove it.

• The same sub menu (Node Group -> NodeGroup2 -> X) can be removed to also provide an option to:
  • Change its color
  • Rename it
  • ~~Show/hide it (change visibility flag)~~
• The code for EMStudio::NodeGroupWindow including the whole NodeGroupWindow.h/.cpp files are removed from the project

Additional Info:

https://user-images.githubusercontent.com/82228511/181769114-37cd1952-d095-45ac-a147-a98681a607a1.mp4

Describe the bug When the user changes the Viewport layout so it displays 3 or more windows simultaneously, the Editor crashes.

Error logs for this issue were not created.

Steps to reproduce Steps to reproduce the behavior:

1. Open Viewport Configure Layout menu.
2. Select any option with 3 or more Viewports.

Expected behavior The Editor remains stable and the Viewport is displayed correctly.

Actual behavior The Editor crashes.

Screenshots/Video

https://user-images.githubusercontent.com/86952591/164718043-cc1c0754-7888-47a8-a852-5119b654ca9d.mp4

Found in Branch Stabilization_2205 (7c5da98)

Desktop/Device: Device: PC OS: Linux Version Ubuntu 20.04.3 LTS CPU AMD Ryzen 5 3600 GPU Nvidia Geforce RTX 2060 SUPER Memory 16GB

Additional context Editor.log AP_GUI.log

Is your feature request related to a problem? Please describe. We need to optimize the priority order of the shader options in the core material types so that the highest priority, highest impact options appear closest to the root of the shader variant tree. That way, if a requested shader variant is not available and a fallback is selected instead, there is a high chance that the fallback variant will still have baked the most impactful shader options. And in order to determine the optimal order, we need to do some investigation to determine which shader options have the most impact on performance when they are baked vs dynamic.

Describe the solution you'd like Run some manual testing to see if we can figure out which shader options have the biggest performance impact, and document whatever improvement is observed. The general idea is to create a scene that forces lots of overdraw, to tax the main material and lighting shader code, so that any performance gains will be quite obvious. Then systematically change the baking of individual shader options and note the change in performance.

1. Create a test material, using EnhancedPbr.material type, that avoids depth testing. The reason we want EnhancedPbr is that uses the most shader options, including all options that are available in StandardPbr. There are a couple ways to set up the material to avoid depth testing (ideally we would test both, and compare the results).
   1. Set the opacity mode to "Blended". This will disable depth-write, so the entities using it will not cull any other entities. This disadvantage to this approach is the shader won't be exactly the same as the typical forward pass shader, especially around IBL code (see "isTransparent" in Ibl.azsli).
   2. Edit EnhancedPBR_ForwardPass_EDS.shader and EnhancedPBR_ForwardPass.shader to set the depth "WriteMask" to 0, and then you can test with opacity mode "Opaque" and/or "Cutout" to test the actual forward pass shaders.
2. Set up a .shadervariantlist file with only one variant in it, which exactly matches the test material. Apply the test material to an object in the editor, and use the new material details tool to confirm which variant is being requested. You can even copy the JSON from the material details tool, and paste it directly into the .shadervariantlist file. https://github.com/o3de/o3de/pull/11623
3. Create a scene with lots of overdraw: Make a new level, assign your test material to the ground plane, and look down at the ground so the plane fills the screen. Duplicate the plane many times (100? 1000?) until the frame time drops significantly, to maybe 1 FPS.
4. Open the material details tool so you can monitor the changes to the shader variants
5. Note the frame time, this is the optimal frame time since all shader options are baked.
6. Test changing each shader option from baked to dynamic. For each shader option
   1. Edit the .shadervariantlist to delete that shader option from the variant
   2. Wait for the Editor to hot reload the changes. You should see the active shader option value change to -1.
   3. Note the new frame time.
   4. Edit the .shadervariantlist to restore the shader option that you deleted
7. Consider doing a similar test where all shader options are dynamic except for one.

Describe alternatives you've considered Going through shader options one at a time is a good start, and is hopefully enough to give us the results we need. But @antonmic had an idea for a hydra script that will automate a more exhaustive search of the shader option permutation space, running a scenario like what's described above, repeatedly with all kinds of different combinations of shader options baked in. This could be run overnight for multiple nights if necessary, to search for possible combinations of multiple shader options that are significant. This could be done as a separate task if this investigation proves insufficient.

Additional context Add any other context or screenshots about the feature request here.

there were a couple compile errors that I had to resolve but beyond that this seems to work mostly out of the box. the stl methods didn't compile correctly so I just reworked them to work with AzSTL.

https://user-images.githubusercontent.com/854359/139184532-f122e4c8-db6f-4fbf-a1a5-4808ce5e731b.mp4

Only thing left would be to setup a build for a openmesh 3rd party dependency?

Signed-off-by: Michael Pollind [email protected]

Describe the bug When unloading and reloading meshes for a while, there is a texture flickering problem appearing like below:

This is one of the frame of the flicker above:

Then, it transitions to this frame:

This happens not often when using StandardPBR to load material. However; when using StandardMultilayerPBR, it happens right away. I use PIX to see if the textures and UVs are sent to the shader, and it's indeed there.

The GPU driver is updated to the latest 471.11 NVidia driver, but the flickering doesn't disappear

To Reproduce This is a small sample code to reproduce the behavior in AtomSampleViewer:

MeshExampleComponent.cpp.txt MeshExampleComponent.h.txt

This sample generates 100 grids using StandardMultilayerPBR material. Pix shows texture is successfully uploaded to GPU, but flickering still happens:

No texture frame:

Texture frame:

Expected behavior Mesh displays texture correctly

Desktop/Device (please complete the following information):

• Device: PC
• OS: Windows
• Version: 10
• CPU: Intel core i7
• GPU: NVidia GTX 1650
• Memory: 32 GB

Describe the bug

"After user adding the RV mesh into the O3DE scene, the RV entity instantiated with two Mesh components. This isn't allowed, so the second mesh component was disabled due to conflict with first mesh. Possible issue - why were there two mesh components in the first place? This happened again when loading another model that has multiple models within it. This was a more complex model, so when loading it to the Editor, the entity contains 4+ more Mesh components than needed."

I did a repo of this issue and duplicated the results.

Steps to reproduce Steps to reproduce the behavior:

1. Drag in an .FBX with 1 mesh node.
2. This will add more than 1 Mesh Component to the Entity.

Expected behavior

Above is the source mesh structure, there is just 1 mesh.

Actual behavior Adding static meshes, and even meshes with bones (Actors) will result in adding many mesh components even when only 1 mesh is in the .fbx file.

Assets required Just dragging a simple box .fbx from Blender will produce this: Here is the test file: SimpleBox.zip

Found in Branch Nightly 6-2-2022

Desktop/Device (please complete the following information):

• PC
• OS: Windows
• Version 10
• CPU Intel I9-9900k
• GPU NVidia RTX 2080ti
• Memory [e.g. 16GB]

Additional context Add any other context about the problem here.

rough implementation of a way to allow the cursor to wrap viewport when using manipulators.

https://user-images.githubusercontent.com/854359/146664874-28871cab-5a39-4dfe-b466-804a14b5877a.mp4

Describe the bug OnCatalogLoaded is a runtime notification for when catalog is loaded and it's possible to resolve asset Ids. Some systems listen to this notification to start loading and resolving their assets, but this notification is never broadcast if the editor is run without having run Asset Processor first (which is the default case when creating a project and open editor from Prism tool), leading to some systems (like PhysXSystem) not loading and resolving their assets, causing crashes when editor is used (for example #6027)

When the editor is launched first, the asset processor will open and start processing assets, the editor will hold until SOME (not all) assets are processed, then open the editor, but the notification OnCatalogLoaded will NEVER be called, even after Asset Processor fully finished.

In the case of launching asset processor first, then wait until all assets are finished, then launch the Editor, the notification OnCatalogLoaded will be called correctly.

Steps to reproduce Steps to reproduce the behavior:

1. Build O3DE with AutomatedTesting project in debug configuration
2. Delete o3de\AutomatedTesting\Cache folder if exists.
3. Put a breakpoint in visual studio in AssetCatalog::LoadBaseCatalogInternal() function in the line InitializeCatalog(baseCatalogName.c_str());
4. Run Editor from visual studio in debug

Expected behavior At some point during editor initialization it should hit the breakpoint to load the catalog and broadcast the OnCatalogLoaded notification.

Actual behavior Breakpoint never hits, meaning InitializeCatalog is never called and therefore OnCatalogLoaded notification never broadcasted.

Found in Branch Development build (3922280) and Stabilization/2110 (6480041)

Describe the bug The O3DE Editor built in debug can easily crash after saving scene settings changes. I was able to get the same crash when I modified the .assetinfo file on disk manually with the Editor running.

Assets required https://github.com/o3de/o3de/blob/development/AutomatedTesting/Assets/ap_test_assets/default_mat.fbx (This is an LFS pointer file. Make sure that you pull the actual asset before testing)

Steps to reproduce Steps to reproduce the behavior:

1. Set AutomatedTesting as the active project and build the Editor in debug
2. Search for default_mat.fbx in the Asset Browser and edit its scene settings from the right click menu (You may need to double click on the fbx to open the menu, which seems like another bug)
3. Add a new mesh group under the Meshes tab in the Scene Settings UI
4. Save the scene settings

Expected behavior Settings are saved successfully and the Editor is stable

Actual behavior Editor crashes

Screenshots/Video

Found in Branch Name of or link to the branch where the issue occurs.

Commit ID from o3de/o3de Repository 3fc63a84876b227e39625fda79630b0e331433de

Desktop/Device (please complete the following information):

• Device: PC
• OS: Windows
• Version 10

Additional context Callstack attached: callstack.txt

What does this PR do?

Without this change, when you add a default prefab group to a scene manifest in the scene settings UI, it didn't automatically update the interface to show the read-only mesh groups used by that.

With this change, the read only mesh groups are added when you add a default prefab group.

The mesh groups are actually added when processing the scene manifest based on the default prefab group being enabled, but they're useful in the UI to provide a breadcrumb trail back to why product assets are generated.

How was this PR tested?

Manual testing, plus new automated test

Signed-off-by: Junbo Liang [email protected]

What does this PR do?

This PR changes the behavior for loading selected/unselected node lists from scene settings. It addresses a few existing issues:

• Issue 1: All the nodes are selected by default when the selected node list contains part of all nodes and the unselected node list is missing.
  • After this change, only the nodes included in the selected node list (and their children) will be selected by default.
• Issue 2: All the nodes are selected by default when both of the selected and unselected node lists are empty (e.g. by default, a new LOD slot will say "All lod meshes selected" even if nothing is selected).
  • After this change, no nodes will be selected by default when add a new LOD.
• Behavior Update: If both of the selected and unselected node lists are empty (or don't exist), all the nodes will be selected by default.
  • After this change, no nodes will be selected by default under this scenario.

How was this PR tested?

• All the existing and new unit tests passed
• All the existing python automation tests for FBX and SceneSettings passed
• Removed the selected/unselected node list from scene settings file. FBX could be processed successfully and proper nodes are selected in the Scene Settings UI
• Added a new LOD in the Scene Settings UI, no node is selected by default

Example 1: .assetinfo file:

...
{
    "$type": "{6E796AC8-1484-4909-860A-6D3F22A7346F} LodRule",
    "nodeSelectionList": [
        {
            "selectedNodes": [
                "RootNode.RootNode.LOD_Group_1.LOD_1.Alpha_Joints",
                "RootNode.RootNode.LOD_Group_1.LOD_1.Alpha_Surface"
            ]
        }
    ]
}
...

SceneSettings:

Example 2: .assetinfo file:

...
{
    "$type": "{6E796AC8-1484-4909-860A-6D3F22A7346F} LodRule",
    "nodeSelectionList": [
        {
            "unselectedNodes": [
                "RootNode.RootNode.LOD_Group_1.LOD_1.Alpha_Joints",
                "RootNode.RootNode.LOD_Group_1.LOD_1.Alpha_Surface"
            ]
        }
    ]
}
...

SceneSettings:

Example 3: .assetinfo file:

...
{
    "$type": "{6E796AC8-1484-4909-860A-6D3F22A7346F} LodRule",
    "nodeSelectionList": [
        {
        }
    ]
}
...

SceneSettings:

Example 4: Add new LOD mesh:

Note

This PR doesn't change some of the existing behaviors below:

• There're conflicts in the selected and unselected node lists (i.e. same node appear in both list). The node will be unselected by default in this case

What does this PR do?

Please describe your PR. For a bug fix, what was the old behavior, what is the new behavior?

Please add links to any issues, RFCs or other items that are relevant to this PR.

How was this PR tested?

Please describe any testing performed.

Signed-off-by: Michael [email protected]

What does this PR do?

Moves the QtPy files from the editor_python_test_tools folder into a sub folder.

Please describe your PR. For a bug fix, what was the old behavior, what is the new behavior? general file organization. keeping the automated testing folder a bit tidier

What does this PR do?

Allows box manipulators to edit individual box faces independently.

How was this PR tested?

Manual testing in the editor with box shape, axis-aligned box shape and PhysX box collider. Updated/added unit tests for both symmetrical and asymmetrical editing.

https://user-images.githubusercontent.com/82226198/211045942-c0a0f2e3-1c18-4197-b419-95ddfc1e32cd.mp4