Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: remove unused call GetSandboxObject #17756

Conversation

pollend
Copy link
Member

@pollend pollend commented Apr 17, 2024

What does this PR do?

I can't find where ComponentEntityEditorRequests gets bound to, looks like this EBus should be removed at some point. I was going to start with removing GetSandboxObject and just remove this call. also helps that CEntityObject constructor is never called.

@pollend pollend requested review from a team as code owners April 17, 2024 00:49
camObjId = pEditorEntity->GetId();
}
}

// Switch camera in active rendering view.
if (GetIEditor()->GetViewManager())
{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do we confirm that this is no longer having an effect? If we don't need the camera object id, and it is always null, can the rest of the function be removed?

Copy link
Member Author

@pollend pollend Apr 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like it, GetSandboxObject is never connected to so there is nothing for ebus to call so yea it will always be null

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the other call from viewManager for CameraObjectId checks for null and its always null so it will set the value is the registry for radians. I think i can safety remove the logic from the viewmanager.

image

Copy link
Member Author

@pollend pollend Apr 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems like this is done to avoid setting the value in the registry when the animation is playing or is this a different path for the fov to change? might want to verify changing the fov of the camera and see if its updating the value in the setting registry? kind of hard to say without any kind of historical context?

I feel we might want to have an animation with the fov and look at the registry settings sounds like this is a regression unrelated to this change?

@pollend pollend requested review from a team as code owners April 18, 2024 00:42
Comment on lines -490 to -503
// If looking through camera object and recording animation, do not allow camera shake
if ((GetIEditor()->GetViewManager()->GetCameraObjectId() != GUID_NULL) && GetIEditor()->GetAnimation()->IsRecording())
{
if (GetIEditor()->GetMovieSystem())
{
GetIEditor()->GetMovieSystem()->EnableCameraShake(false);
}
}
else
{
if (GetIEditor()->GetMovieSystem())
{
GetIEditor()->GetMovieSystem()->EnableCameraShake(true);
}
}
Copy link
Member Author

@pollend pollend Apr 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this was easy to remove the camera shake is unused code so its better to just remove it then keep faulty logic.

Comment on lines -790 to -793
if (pRenderViewport->GetViewManager()->GetCameraObjectId() == GUID_NULL)
{
SandboxEditor::SetCameraDefaultFovRadians(fovRadians);
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this looks like something to investigate further looks like this is done to prevent the setting from getting saved to settings registry. if its always null them maestro might just save it anyways. might add a breakpoint here and mess with the fov and see if this logic gets called.

@byrcolin byrcolin added the sig/core Categorizes an issue or PR as relevant to SIG Core label Apr 23, 2024
@pollend pollend force-pushed the feat/remove-GetSandboxObject-ComponentEntityEditorRequests branch 2 times, most recently from df88a73 to 67af223 Compare May 8, 2024 04:28
@gadams3
Copy link
Contributor

gadams3 commented May 10, 2024

failed to build in release

 D:/workspace/o3de/Code/Editor/EditorViewportWidget.cpp(1187,70): error C2220: the following warning is treated as an error [D:\workspace\o3de\build\windows\Code\Editor\EditorLib.vcxproj]
14:55:51    void EditorViewportWidget::SetViewTM(const Matrix34& camMatrix, bool bMoveOnly)
14:55:51                                                                         ^

@pollend pollend force-pushed the feat/remove-GetSandboxObject-ComponentEntityEditorRequests branch from 67af223 to a63328d Compare May 10, 2024 22:34
@pollend pollend force-pushed the feat/remove-GetSandboxObject-ComponentEntityEditorRequests branch from a63328d to 108dfa7 Compare May 14, 2024 23:42
Copy link
Contributor

@nick-l-o3de nick-l-o3de left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

red code is best code

@pollend pollend merged commit 0c8ea3b into o3de:development May 23, 2024
3 checks passed
@pollend pollend deleted the feat/remove-GetSandboxObject-ComponentEntityEditorRequests branch May 23, 2024 04:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sig/core Categorizes an issue or PR as relevant to SIG Core
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants