Closed omgitsraven closed 5 years ago
It is a known constraint of THREE that it uses one eye Frustum for culling: https://github.com/mrdoob/three.js/issues/13236
ah, fair enough!
Probably worth leaving open here too until it's resolved there and pulled in (if only for the next person to come along and try to report it here)
actually wait, I just realised, it looks like that thread says the issue is fixed in r91? When is A-Frame planning on targeting that version?
@omgitsraven commented on https://github.com/mrdoob/three.js/issues/13236
Very noticeable after upgrading to A-Frame 0.8.x. Going back to 0.7.x not really an option either, as VR has become very unstable in the newest version of Firefox with 0.7.x. Anything I can do to help move this forward?
I've looked into this, and the offending line of code is https://github.com/mrdoob/three.js/blob/dev/src/renderers/webvr/WebVRManager.js#L195.
Fixing this seem be stuck on the WebXR API exposing a combined frustum for both eyes, as described in https://github.com/immersive-web/webxr/issues/203. However, this issue has seen no activity for nearly a year.
I think this is too big of an issue to just wait for something to happen in the WebXR API, which Three.js can then adapt to the benefit of A-Frame. I don't know enough about frustum calculations, but if I did I would submit a PR to Three.js that applied a combined frustum of both eyes at least until it can be fixed in the WebXR API.
Anyone know how to do this?
This should be fix by https://github.com/mrdoob/three.js/pull/14950
Description:
It seems like the frustum used for frustum culling isn't set right? In VR mode, no matter where I turn my head, I always see objects flicking in and out of existence along the right edge of my field of view. (The example I've linked is a room built out of individual colored tiles, to show the problem clearly.)