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.

Sign up for GitHub

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

HYDRA-687 : fix a test related to Usd Ufe lights #12

Closed
wants to merge 1 commit into from
+1 −1
Closed

HYDRA-687 : fix a test related to Usd Ufe lights #12

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion test/lib/mayaUsd/render/mayaToHydra/cpp/testMayaUsdUfeItems.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,7 @@ bool IsUfeLight(const HdSceneIndexBasePtr& sceneIndex, const SdfPath& primPath)
}
// The shape prim is used to display the light's wireframe and is the only prim we want to allow
// for UFE lights
bool isShapePrim = primPath.GetElementString().find("ufeLightProxyShape") < std::string::npos;
bool isShapePrim = primPath.GetElementString().find("ufeLightProxy") < std::string::npos;
Copy link
Collaborator

@debloip-adsk debloip-adsk Nov 16, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

This seems wrong : if a prim comes in named ufeLightProxy, this method will now return false when it should return true. The original bug that this test looks for is that previously, MayaUSD added its lights both through UFE and through its UsdStageSceneIndex, which led to the light being present twice. The fix I did was to filter out the UFE light (ufeLightProxy), but not its wireframe display (ufeLightProxyShape). So conceptually, this method returns primPath == "ufeLightProxy" (I can't recall if there was a reason I didn't do this directly and instead used find calls). So if this test fails, to me this points to a different issue.

Copy link
Collaborator

@debloip-adsk debloip-adsk Nov 16, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

Follow-up : I've taken a look at this and it seems that even though we still filter the UFE lights correctly, the ufeLightProxyShape prims now have a parent ufeLightProxy prim which is essentially just an empty prim that has the shape prim as its child. But there is still no actual light prim being created, which is good. We just need to adjust the test accordingly. I've opened #14 to change the check to a more robust one than the one I previously did. As for the reason I used std::string::find, it's because the prim names contain id numbers (e.g. ufeLightProxy1).

return !isShapePrim;
}

Expand Down