Effect registry needs a revamp

[einarf]

The effect registry was mainly there to initialize effects during the loading stage by creating a single instance of each effect found in the effect module. This has worked so far with relativelt simple projects, but it doesn't really cover more complex cases. Single instances doesn't get you very far.

The purpose of the Effect class is:

• To provide users a simple way to have local resources
• Give simple access to resource loading through get_* methods.
• Give simple access to the moderngl context and window properties
• Having a standard way for the system to deal the concept of something drawable (eg. draw(...))

This also brings up the fact that effect.py containing one effect really should be effects.py containing multiple effects. The main purpose of registering an effect now is really to support the local resource folders.

In addition this questions what role EffectManager have in this whole system. It's all simple and well when we run a single effect, but what happens in more complex cases?

Effect Plugins

Let's say we have an external package containing postprocessing effects demosys-postprocessing. It has an effects.py module containing multiple effects with different techniques/effects. Possibly also classes or functions that are not actual effects.

We want users to freely instantiate these effects or classes somewhere be it a single or multiple instances.

Conclusion

It looks like for more complex projects we need some mecahnism to describe the project in detail giving the user full control over resource and effect instances. The suggestion so far is to introduce a project.py module in the root of the project were detailed initialization code can be written. This module will be used when then run command is issued. The runeffect command will be unchanged, but great care has to be taken to make the two commands compatible. We still want to be able to run a single effect and ONLY load the resources this single effect requires if even possible.

What is also more obvious here is that we are missing a crucial component. What effect instance is supposed to be rendered at what time? We are missing a way to defined a timeline. In our own demosys we had a built in timeline editor that appeared when pressing TAB drawn as an overlay. This worked just like a tracker. Each effect instance was displayed horizontally in tracker rows where we defined intervals for when the effect should be active and what the render target should be.

This could be done in the following ways:

1. Introduce a simple timeline.py module in the root of the project what is reloadable runtime
2. Create an overlay editor for timeline editing saving the data data to json or a binary format
3. Rely on the rocket editor to deal with both timeline and keyframe data putting the timeline data in a separate category.

[einarf]

This was covered in #46 since these topics are so closely tied together.

[einarf]

Done in the 2.0 branch