R&D try basic theatre.js + A-Frame integration

[kfarr]

https://github.com/theatre-js/theatre

mvp to build from

• https://twitter.com/kfarr/status/1712183871188717716
• https://aframe-theatre-demo.glitch.me/
• https://glitch.com/edit/#!/aframe-theatre-demo?path=index.html%3A5%3A9

next steps

• product: as a user I want a mechanism to indicate items that I can animate
• as a user I'd like to enter "animation mode" to animate those things
• I'd like to be able to share my animation with other people

implementation Q&A from theatre discord

KF

• Now I'm considering integrating with an existing app that has a lot of entities in a scene (for example https://3dstreet.app/#/scenes/709f1093-073d-4570-908c-631754928d29.json) very curious to see "best practices" examples of how people choose to expose object properties for end-users. Do you iterate through all your objects in a scene and add x/y/z position and euler rotation for example?
• Also will this method of using onValuesChange be worse in the long-term compared to creating an a-frame patch so we can add a three.js render tick handler (rafDriver?) for theatre?

donmccurdy

• Glitch is giving me an error trying to open the code, but – i think this could work very similarly to A-Frame Physics, where a custom system or component is responsible for advancing the theatre.js sequence and applying all the onValuesChange updates before A-Frame draws.
• I've made this opt-in - users select the objects to animate, the project infers some common default properties of those objects (translation, rotation, scale, opacity, visible, ...) and then there's an escape hatch for users to add more properties for animation, like .roughness if they need them. Very easy to make the theatre.js studio get a bit overwhelming with too many objects and properties i think.