-
Notifications
You must be signed in to change notification settings - Fork 202
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
MAYA-122104 ProxyShapeSceneSegmentHandler and UsdCameraHandler::findCameras. #2307
Conversation
lib/mayaUsd/ufe/UsdCameraHandler.cpp
Outdated
@@ -52,5 +56,25 @@ Ufe::Camera::Ptr UsdCameraHandler::camera(const Ufe::SceneItem::Ptr& item) const | |||
return UsdCamera::create(usdItem); | |||
} | |||
|
|||
#if defined(UFE_V4_FEATURES_AVAILABLE) && (UFE_PREVIEW_VERSION_NUM >= 4008) | |||
Ufe::Selection UsdCameraHandler::findCamerasInSceneSegment(const Ufe::Path& path) const |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Native USD search for cameras.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. I'm only wondering how much faster is this approach compared to just traversing Ufe::Hierarchy. In the end we still have to traverse USD hierarchy in search of cameras.
You are right in that the complexity of the algorithm is the same. The speed difference comes from eliminating the overhead of calls to Ufe during the traversal. Using Ufe::Hierarchy to traverse means creating many additional Ufe::SceneItems, Ufe::Paths and Ufe::Hierarchy objects, which means allocating a bunch of std::vector<>, std::shared_ptr<> etc. Doing the iteration with USD means we don't do any allocation when the object is not a gateway item or a camera (which is most objects). Avoiding the overhead of Ufe when doing the hierarchy traversal ends up saving a significant amount of time. This version is something like 10x faster then the original code. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs a test.
949b990
to
0142456
Compare
These changes are already merged on top of @JGamache-autodesk work for #2315, so merge that one first. The only thing I'm missing is a test for SceneSegmentHandler. I forgot the Ufe::RunTimeMgr Python API that I need to write the test, so it is going to come in another PR. |
I added the label "do not merge yet" as a reminder to myself to merge #2315 first. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the tests. Would be great if you could adjust the test conditionals to follow the pattern we've done in the past, makes it easier to remove these obsolete conditionals at the next Maya preview release.
Was quite confusing to review your changes and Jerry's changes in the same pull request. Can't we just merge in Jerry's changes first, then you can update from dev and rebase your commits on top?
lib/mayaUsd/ufe/CMakeLists.txt
Outdated
) | ||
endif() | ||
|
||
if (${UFE_PREVIEW_VERSION_NUM} GREATER_EQUAL 4010) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ouch. Can't we just settle on GREATER_EQUAL 4010?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're in kind of a strange state because we've had a bunch of UFE preview versions go by without getting them into Maya. Everyone is building locally slightly differently. But no QA-testable build with Ufe 0.4.9 is ever going to exist, which means these could all be testing for 0.4.10 (or 0.4.11 if my extra python API changes are merged). That simplifies the cmake. But we don't know which version to check for until something gets merged into Maya, and we can't merge into Maya until this gets merged...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems to me we can merge this with GREATER_EQUAL 4010 (or 4011) at any time. Local developer builds will have 0.4.10 (or 0.4.11, as the case may be), so maya-usd will work with the newer version, as well as with the older UFE version. Am I missing something?
result = ufe.CameraHandler.findAll(proxyShapeParentItem) | ||
self.assertTrue(result.contains(camera1Path)) | ||
self.assertTrue(result.contains(camera2Path)) | ||
self.assertEqual(len(result), 2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So why aren't we finding Maya cameras?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Maya camera handler is not implemented, and there are no cameras that are children of proxyShapeParentItem. If we had the Maya camera handler and we had searched the Maya root path then we'd find front, side, top and persp.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, so do we plan on leaving the Maya camera handler unimplemented, because there is no demonstrated need for it? If so, would be nice to add a comment to that effect in the test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure I'll add a comment.
test/lib/ufe/testSceneSegment.py
Outdated
# Load plugins | ||
self.assertTrue(self.pluginsLoaded) | ||
|
||
def _StartTest(self, testName): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this different from setUp()?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not really sure. I copied most of the test from testCamera.py and it has this pattern too. Probably I copied it for testCamera from somewhere else.
I guess if all the tests are running with the same USD file (which for testCamera and testSceneSegment they are running with the same USD file, then the file could get loaded in setUp and each test could re-use it? That would make the test run faster. That should work relatively easily here because I'm not actually modifying the file at all.
I'll try it and see how it goes.
d32acd0
to
34cd739
Compare
The new changes were around the feedback provided by @ppt-adsk on the tests for CameraHandler and SceneSegementHandler. I also re-based on top of dev to eliminate merge conflicts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a big deal, but it feels like the tests could have some fat trimmed off, sorry for noticing this late. Otherwise looks great!
test/lib/ufe/testCamera.py
Outdated
camera2Path = ufe.Path([mayaPathSegment, cam2UsdPathSegment]) | ||
|
||
# Test that the camera handlers can find USD cameras in a scene segment | ||
proxyShapeParentSegment = mayaUtils.createUfePathSegment('|stage') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder about these single-use UFE path segments --- can't we just use ufe.PathString.path() to create them out of concatenated strings? E.g.
mayaPathSegmentStr = '|stage|stageShape'
camerasParentPath = ufe.PathString.path(mayaPathSegmentStr+'/cameras/cam2')
I get that you're re-using the Maya path segment, and in real code there may be a performance benefit to doing this, but in a test it seems so verbose.
test/lib/ufe/testCamera.py
Outdated
geoPath = ufe.Path([mayaPathSegment, geoPathSegment]) | ||
camera1Path = ufe.Path([mayaPathSegment, camera1PathSegment]) | ||
|
||
proxyShapeItem = ufe.Hierarchy.createItem(proxyShapePath) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have a look at ufeUtils.createItem(). It will create a ufe.SceneItem directly out of a path string, I think this is what you want, and will remove a lot of boiler-plate code from your test.
… the CameraHandler and SceneSegment interfaces.
Updated the tests to create the required paths in a more concise way. Updated the Ufe preview version checks to the latest. Don't merge until the Ufe PR is merged. |
No description provided.