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?
