Should we apply matrix optimizations to superthree?

[diarmidmackenzie]

trafficstars

Description:

See background here: https://github.com/mrdoob/three.js/issues/25115

Based on feedback received here, it looks like neither #25114 or 25142 is going to be accepted into THREE.js due to unavoidable API changes. https://github.com/mrdoob/three.js/pull/25142#issuecomment-1357345258

Specifically, these changes require that we don't allow sub-classes of Object3D to override updateMatrixWorld(), instead providing a alternative API for sub-classes to extend updateMatrixWorld() processing.

THREE.js maintainers see that as an unacceptable level of API change.

For A-Frame, I think there may be a different balance:

• I think this restriction on the THREE.js API is far less problematic
• Due to the way A-Frame models a-entitys with multiple THREE.Object3Ds, the potential performance gains are more substantial
• As a platform that targets VR, and hence frame rates of 72fps+, A-Frame likely cares more about performance than THREE.js.

Hence might be worth considering taking these changes into superthree.

I'd be happy to do a PR for that if it's wanted.

Thoughts / feedback?

[dmarcos]

It could be interesting. It seems as is the optimization is enabled by default and can opt-out. Can be disabled by default and then make it opt-in for devs? Concern is backwards compat, diverging from THREE and devs need to do extra work to integrate stuff with A-Frame.

[dmarcos]

We could also do a custom build for moonrider. Or even a custom build of A-Frame with the optimization