You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe bounds is usually a better option as it could let us easily adapt the real viewport size when resizing the window or when changing between different RenderTargets (as we do on WebVR or when using Multiview FBOs).
@mrdoob do you mind clarifying this, if both options should be supported, or are you switching to use just one of them? Thanks!
The text was updated successfully, but these errors were encountered:
As far as I remember... I added implemented bounds mainly influenced by the WebVR API. Then the WebXR API decided to provide absolute coordinates and that made me add viewport.
I agree that bounds is nicer conceptually. However, the benefit of viewport is that we can control at a pixel level every view. With bounds there were always gaps in-between views:
On the
ArrayCamera
documentation currently we can read the following requirement:https://github.com/mrdoob/three.js/blob/dev/docs/api/en/cameras/ArrayCamera.html#L17
But I just noticed that the
webgl_array_camera
example has changed from usingbounds
toviewport
:7a4c962#diff-4922b91cfbe857ae22c8196e08f64f00L40
While on
WebVRManager
we still usebounds
to define each camera's viewport:https://github.com/mrdoob/three.js/blob/dev/src/renderers/webvr/WebVRManager.js#L45-L49
I believe
bounds
is usually a better option as it could let us easily adapt the real viewport size when resizing the window or when changing between different RenderTargets (as we do on WebVR or when using Multiview FBOs).@mrdoob do you mind clarifying this, if both options should be supported, or are you switching to use just one of them? Thanks!
The text was updated successfully, but these errors were encountered: