Michael Gutensohn
Michael Gutensohn
> Related to rendering performance, Three.js doesn't seem to support multiview extension but a PR is opened [mrdoob/three.js#25981](https://github.com/mrdoob/three.js/pull/25981) I'm not really sure when and whether Three.js will support it. If...
This aligns with my own thoughts. I'm open to exploring a fork, but only once we've optimized every where else. We could also try to upstream the changes from our...
I left a comment on the PR https://github.com/mrdoob/three.js/pull/25981#issuecomment-1958530030
It appears that EtheralEngine and AFrame came to the same conclusion. I'm more open to it if the performance gains are significant, but I'd much rather push for it to...
Yeah forking is a last resort. let's work with what we have.
> If acceptable, using different light for shadow can speed up the app by reducing the GPU memory usage. This is a good idea. Didn't realize how big the map...
> If we cannot reach 60 FPS due to the hardware limitations of Quest 3 (and not due to the inefficiency of MRjs), there is little point in trying to...
Unfortunately we can't tune depth sensing to only occlude the body. This breaks a lot of our MR features, so we'll need to hold off on the integration.
Hmm that's interesting. It would have to be at the OS level in that case because we're not touching any of the room geometry. We're accomplishing the selective occlusion by...
This would also boil down to a per-entity debug experience, adding the debug attribute to an element rather than at the app level, rather than rendering the whole physics scene.