Note that the Reset button will move the camera to the auto framing pose, which we try to avoid defining the initial camera pose. This reset behavior seems not very logical in this case.
The question: what is the best way to make Reset button to move the camera to the initial specified camera pose?
camera-orbit and camera-target is separate from the default camera. Reason-being is these values could be dynamic/optional on user side. It is like an extra feature.
camera-orbit and camera-target override the initial default camera state as the current behaviour is. The user should currently be able to create a new button to re-target. @labris do you want to see an example of this?
The default camera should be the first camera found in the model, if there are no cameras then it defaults to creating a camera with default values of camera-orbit and camera-target. If these properties are undefined then carry-on current behaviour of calculating it with bounding box.
We could introduce a new attribute camera-override=true which changes the default camera, to behave as @labris wants as can see this handy for other situations like when we want to ignore model cameras.
Note the above are just my thoughts, not necessarily what is implemented. I haven’t checked if Viewer looks at cameras in GLB models.
Not yet found a sensible observable for once the camera has finished (hence used timeout) but you can use a reference to the attribute values which would be better.
Yes, we’ve had some discussion around this scenario. It’s a little tricky, but we’re open to any ideas/preferences from the community. Where it gets tricky is when you have a model with multiple animations. When the viewer first loads the model, it will set the configured camera-orbit and camera-target and selected-animation. But when you switch to a different animation, we reframe the camera, because the bounding box can be wildly different between different animation groups. So if you then reset the camera, and we re-apply the initial camera-orbit/camera-target, the camera pose will likely be very undesirable relative to the selected animation.
One possible improvement would be to have the reset camera button behave differently depending on what animation group is selected. If the initial selected-animation is active, then the camera-orbit/camera-target make sense and could be applied. Otherwise if you have a different selected-animation, then we could do the current reframing behavior. Thoughts?
This is something we considered a fair bit. Currently for simplicity and to focus on the common model viewing scenario, the viewer api assumes an ArcRotateCamera. The only time we look at the cameras within the glb is if you set cameras-as-hotspots attribute, in which case we convert cameras in the glb to hotspots. Trying to balance simplicity and flexibility.
I think there is no need to make the logic automatically be dependent on any animations.
For example, if you have a house interior model with no animations but with some hotspots inside, and you never want to show the house from outside (like it will be with current default settings).
I think the most flexible and probably the best solution could be additional attribute which defines the Reset button behaviour. Either it could be a flag like
or it could have some parameters, for example: auto (default), camera (which is specified in camera-orbit and camera-target), animation (so the Reset pose depends on the selected-animation and its bounding info).
The Reset button is too nice to override it! We just need more settings for it.
Yes I think something like this should work. I’d like to reframe it slightly, and think of it more like that “reset” button in the Viewer’s toolbar performs a reset action, and that reset action is customizable. So, very similar to what you and @j-te said above, we can add an attribute called reset-mode that can have some values like auto, camera, reframe, animation, materials, all. Just want to double check this meets your needs!
Hey folks - I started doing some work on this yesterday, but realized that as simple as it sounds, it gets complicated with the way things currently work. Since we are trying to get our 8.0 release stabilized, I don’t want to make any big changes right now. My preference is to return to this in a couple weeks after the release is done. Does this work for your timeline?
Hey folks - configuring the reset behavior is now supported as of 8.1.1. Specifically, there is now a reset-mode attribute that can be set to the following:
auto: This is the default and the behavior I described above - it will reset the camera to the initial pose, respecting the camera-orbit and camera-target attributes, unless other viewer state makes this “dangerous” (e.g. a different animation is selected and the model might be out of view).
reframe: The previous behavior (that is, reframe the camera regardless of initial state, ignoring the camera-orbit and camera-target attributes).
camera: Resets the camera to the initial state, respecting camera-orbit and camera-target, regardless of other viewer state (e.g. use this if you want to restore the initial camera state and you know that other animations will not cause the model to be out of view of the camera). This mode is actually part of a larger mode where you can use a space separated list of the different viewer state groups that you want to reset, including "source" | "environment" | "camera" | "animation" | "post-processing" | "material-variant". For example, the attribute could be set to "camera animation" if you wanted the reset button to reset both camera state and animation state to the configured initial state.
The reload button is different from the reset button… hopefully you don’t see the reload button often, but it basically replaces the html element content with a single button if the context is lost, and pressing it will reload the Viewer. This would most likely only happen if many instances of the viewer are used on the same page.
I’m guessing what you are wanting here is to have slots for the icons used in some of the buttons?
