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

Jump to bottom

UsdView renders Mesh with Blendshapes in wrong place when using GPU vs CPU implementation #2425

Closed
talislfb opened this issue May 4, 2023 · 4 comments
Closed

UsdView renders Mesh with Blendshapes in wrong place when using GPU vs CPU implementation #2425

talislfb opened this issue May 4, 2023 · 4 comments

Comments

@talislfb
Copy link

talislfb commented May 4, 2023 •
edited
Loading

Description of Issue

Having a prim Mesh with BlendShapes, but no UsdSkel joints associated with it causes UsdView to render the mesh wrongly at the origin UsdView with CPU vs GPU.

Expected result achieved by running the UsdSkel.BakeSkinning(usdviewApi.stage.Traverse())
image

Current default results
image

As you can see, from the images above, the sphere is rendered at the origin (even though the actual prim location hasn't changed).
@cameronwhite
Copy link
Contributor

cameronwhite commented May 5, 2023 •
edited
Loading

Attaching the example from the mailing list: shapes.usd.gz

The different behaviour can be observed by comparing against env USDSKELIMAGING_FORCE_CPU_COMPUTE=1 usdview shapes.usd, or applying the BakeSkinning operation mentioned above

My comments from mailing list:

From a quick glance, if there are only blendshapes (no skinning) then the deformed point positions are already in the prim's local space.
These transforms shouldn't be necessary in this scenario since they're expecting the points to be in the skeleton's space after skinning:
https://github.com/PixarAnimationStudios/USD/blob/b53573ea2a6b29bc4a6b129f604bbb342c35df5c/pxr/usdImaging/usdSkelImaging/shaders/skinning.glslfx#L227
(and the geomBindXform earlier on also looks unnecessary when no skinning is being applied?)

@tallytalwar
Copy link
Contributor

Filed as internal issue #USD-8311

@FlorianZ
Copy link
Contributor

FlorianZ commented Sep 6, 2023

Great find, @cameronwhite. Would you be up for contributing a fix for this? Thank you!!

@cameronwhite cameronwhite mentioned this issue Sep 15, 2023
Merged
2 tasks
@cameronwhite
Copy link
Contributor

Great find, @cameronwhite. Would you be up for contributing a fix for this? Thank you!!

Yep! I've submitted PR #2696

marktucker pushed a commit to sideeffects/USD that referenced this issue Feb 8, 2024
@cameronwhite @marktucker
Fix incorrectly transformed points for GPU blendshapes with no skinning.
bec511a 
When the mesh only has blendshapes (no skinning), the deformed point
positions are already in the prim's local space so it's simplest to just
skip applying any additional transforms.

The previous behaviour was incorrect because the final skel space ->
world space -> model space transform expected the points to be in skel
space, which was not the case when only blendshapes were present.
Similarly, the bind transform is only required when skinning is enabled.

The results are now consistent with the CPU skinning computation.

Fixes: PixarAnimationStudios#2425
robp-sidefx pushed a commit to sideeffects/USD that referenced this issue Mar 28, 2024
@cameronwhite @robp-sidefx
Fix incorrectly transformed points for GPU blendshapes with no skinning.
962b223 
When the mesh only has blendshapes (no skinning), the deformed point
positions are already in the prim's local space so it's simplest to just
skip applying any additional transforms.

The previous behaviour was incorrect because the final skel space ->
world space -> model space transform expected the points to be in skel
space, which was not the case when only blendshapes were present.
Similarly, the bind transform is only required when skinning is enabled.

The results are now consistent with the CPU skinning computation.

Fixes: PixarAnimationStudios#2425
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@cameronwhite @tallytalwar @FlorianZ @talislfb