Viewer: add a way to match POV of other cameras (from gltf file loaded for example) #16076
Conversation
cournoll
force-pushed
the
viewer-select-cameras
branch
from
1a18638 to
471b841
Compare
|
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
|
Snapshot stored with reference name: Test environment: To test a playground add it to the URL, for example: https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/16076/merge/index.html#WGZLGJ#4600 Links to test babylon tools with this snapshot: https://playground.babylonjs.com/?snapshot=refs/pull/16076/merge To test the snapshot in the playground with a playground ID add it after the snapshot query string: https://playground.babylonjs.com/?snapshot=refs/pull/16076/merge#BCU1XR#0 |
|
WebGL2 visualization test reporter: |
|
Visualization tests for WebGPU (Experimental) |
|
I was thinking from our initial discussions that we would simply translate these cameras directly to hotspot entries on the element (rather than adding a new cameras concept). Any reason not to go that route? If we do, then I think a few changes to this PR would be good:
|
Not really any specific reason. Initially, during development, I wanted a distinct visual indication so the user could understand that this behavior in the viewer was tied to the cameras in the scene. But once I finished my code and realized that focusing on a hotspot or matching a camera’s POV ultimately relies on the same principle (an interpolation) I understood that we could merge the two. :) That said, I’m still wondering how we could clarify for users where the names and values of these "undeclared hotspots" originate. |
I had a similar feeling about that, so it works perfectly for me.
Yes, yes, yes! Having the bounding info in
We will aiming for behavior 4, so i'll try to do something that stay consistent with the Babylon viewer approach and let us fit with our needed 👍 |
Ok, I guess in this case we can just check |
Remove useless ray parameters Factor code on radius calculation Use _tempVectors for computation Handle mesh predicate as parameter of function getArcRotateCameraInfos
Add property camerasAsHotSpots to active cameras hot spots Fix camera forward ray
Add bounding infos into the model
Improve type ModelBoundingInfo and mode bounding infos Move getArcRotateCameraInfos into viewerElement and switch it to private Split basic hot spots to hot spots from cameras
Rename _getArcRotateCameraInfos into _cameraToHotSpot
Factorise the code to add or remove a camera hot spot
Rename _updateModelBoundingInfo into computeBoundingInfos
Now worldBounds array is a function getWorldBounds Add resetWorldBounds function in case of model transformations Remove camerasHotSpots
Fix _toggleCamerasAsHotSpots Factorise code for toggle cameras as hot spots
|
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
|
Snapshot stored with reference name: Test environment: To test a playground add it to the URL, for example: https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/16076/merge/index.html#WGZLGJ#4600 Links to test babylon tools with this snapshot: https://playground.babylonjs.com/?snapshot=refs/pull/16076/merge To test the snapshot in the playground with a playground ID add it after the snapshot query string: https://playground.babylonjs.com/?snapshot=refs/pull/16076/merge#BCU1XR#0 |
|
WebGL2 visualization test reporter: |
|
Visualization tests for WebGPU |
|
WebGL2 visualization test reporter: |
|
Visualization tests for WebGPU |
|
Visualization tests for WebGPU |
|
WebGL2 visualization test reporter: |
|
Visualization tests for WebGPU |
|
WebGL2 visualization test reporter: |
This change introduces a way to interpolate the viewer's default camera to other existing cameras in the scene. The primary goal of this feature is to enable matching the POV of cameras defined in a GLTF file, without switching the active camera to try to keep a "simple" experience for non-expert users.
_cameraToHotSpotfunction compute thealpha,beta, andradiusangles, as well as the target point for a camera that is not anArcRotateCamera.meshesfromAssetContaineris found, the first hit point is used as the target. If no intersection is detected, a fallback target is calculated by projecting the distance between the camera and theAssetContainerworld center along the forward ray.