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

SkinnedMeshRenderer bounds are incorrect #397

Closed
hybridherbst opened this issue May 9, 2022 · 2 comments
Closed

SkinnedMeshRenderer bounds are incorrect #397

hybridherbst opened this issue May 9, 2022 · 2 comments
Labels
bug Something isn't working

Comments

@hybridherbst
Copy link
Contributor

Describe the bug
While trying to debug

I found that a similar (but different) issue happens when importing the file via glTFast - when playing back the contained animation the skinned mesh is only sometimes visible, sometimes not, and it looks like the bounds are incorrectly updated.

This could well be a Unity bug, but the original comes from Unity and plays just fine, so I'm not sure...

Files

SkinningCullingBug-truncated.zip

To Reproduce
Steps to reproduce the behavior:

  1. Import the above file at edit time (drop it in Unity)
  2. Place in scene, add a PlayableDirector, make a timeline, add the clip so you can scrub it
  3. Scrub through the clip and move around in the scene view
  4. Note that the mesh isn't always visible, it seems whenever the transform root is outside the scene view bounds the mesh is culled away.

Expected behavior
SkinnedMeshRenderer should have correct bounds to prevent this from happening I guess

Screenshots

20220509-142736-ISur-Unity_F6Tf.mp4

20220509-142820-vbFZ-Unity_FmZS

@hybridherbst hybridherbst added the bug Something isn't working label May 9, 2022
@atteneder
Copy link
Owner

glTFast cannot calculate the animated bounding box (yet; see #301 ), so updateWhenOffscreen is enabled by default, meaning the bounds are calculated by Unity each frame.

Observation: The bounds seem to be invalid whenever the scale of LOD0 is animated to 0/0/0. I guess the bounds are calculated correctly, but then the 0/0/0 scale jams it.

Is that the same for the original?

Also: RootNode scale in Z is -1. Shouldn't be a problem, just logging the observation.

@hybridherbst
Copy link
Contributor Author

Interesting: I wasn't aware that LOD0 is scaled to 0 in some of these frames, that definitely contributes to the issue, and it's not the same as in the original!
Also it seems something else on my end has set "Update when offscreen" to false, so I'd say glTFast behaves correctly here. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants