Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With some recent refactoring I broke
animation-auto-play
. Previously it was doing some juggling with responsibilities split across theViewer
and theViewerElement
. With this change, I moved all the responsibility to theViewer
, dependent on load options. This makes it much simpler to ensure the logic is correct. An alternative would be to make theViewerElement
entirely responsible, and have it sequentially load the model, then set the selectedAnimation, then play the animation. The only reason I don't want to do it this way is because changing the selectedAnimation animates the camera pose (based on computed bounds), and when the model is first being loaded, we don't want this animation. So it's either add load options for the Viewer, or expose theselectAnimation
function so theViewerElement
can select an animation without animating the camera pose. But since other view framework layers would want the same behavior, I think it's better to do it in theViewer
.