EtherealEngine
Michael/ir 2665 triggers
Summary
Added trigger components
- camera trigger: take over camera and focus on a transform on trigger
- video trigger: play a video on trigger
- animation trigger: play an animation on trigger
Subtasks Checklist
Breaking Changes
References
closes #insert number here
QA Steps
I synced up with Josh on how we are utilizing components in this setup and he confirmed my suspicions. Due to the nature of the ECS adding a Component adds a lot of storage overhead when we should be able to combine all these features into a single design. @HexaField, @speigg, You, anyone else, and I should get together and consider a way to generalize.
Furthermore, these seem very much like specific use cases of the underlying systems, which the engine itself should try not to implemented. These seem like a great use case for very basic Visual Script components, or something a specific application/game would implement, rather than what the engine should provide.
Adding these to the engine itself brings a lot of overhead for testing and maintenance, while not providing any value to the engine as an engine, since they are so use case dependent.
The point of the trigger is to trigger events, it should and can be used. If tween animations are to be used, we want to implement an API for that, and an animation or sequence generator. These are ideas we've had for implementing features like this, which avoid the need to add new ECS components (thus also GLTF extensions) for individual use cases (you could easily imagine dozens more variations of the components introduced in this PR).
I synced up with Josh on how we are utilizing components in this setup and he confirmed my suspicions. Due to the nature of the ECS adding a Component adds a lot of storage overhead when we should be able to combine all these features into a single design. @HexaField, @speigg, You, anyone else, and I should get together and consider a way to generalize.
Furthermore, these seem very much like specific use cases of the underlying systems, which the engine itself should try not to implemented. These seem like a great use case for very basic Visual Script components, or something a specific application/game would implement, rather than what the engine should provide.
Adding these to the engine itself brings a lot of overhead for testing and maintenance, while not providing any value to the engine as an engine, since they are so use case dependent.
The point of the trigger is to trigger events, it should and can be used. If tween animations are to be used, we want to implement an API for that, and an animation or sequence generator. These are ideas we've had for implementing features like this, which avoid the need to add new ECS components (thus also GLTF extensions) for individual use cases (you could easily imagine dozens more variations of the components introduced in this PR).
@DanielBelmes @HexaField There's not time right now for a more robust camera system, so for now these components are just a start. This whole week Michael was communicating that if anyone had a better immediate solution than creating components to explain, and nobody did. I don't think it's productive to turn around now, after an implementation has been completed, and say that we should scrap this for a larger and more time consuming alternative. It was always the plan to use this as a starter fix and roll this into visual scripting and a camera system as that gets developed. Let's just get this in for now so enterprise has something to use at all while we catch up with tech debt.
