Consider implementing dynamic Apertures on the ModifierSet

[chriswmackey]

For the PR that I am about to send, I am implementing the ability to assign an array of modifiers to an Aperture to represent different states. However, I am going to keep the Aperture modifiers on the ModifierSet as static now for simplicity.

However, I can see that, at some point, we may want to allow for states in the ModifierSet if someone wants to make a ModifierSet for a building that has electrochormic for all of its windows. It seems like this will probably be a desired feature but I think we should first work it out with states assigned on an Aperture-by-Aperture basis.

[mostaphaRoudsari]

I can see that, at some point, we may want to allow for states in the ModifierSet if someone wants to make a ModifierSet for a building that has electrochormic for all of its windows

That's a great point. Making a dynamic material as a standard object will go a long way. I think we should think about it more than just a list of modifiers.

[chriswmackey]

Agreed. Having a special type of DynamicModifer was also similar to how I was thinking about implementing a similar feature on the honeybee_energy end. I agree this merits a longer discussion.

[chriswmackey]

Now that I see that a state needs to be an entire object like an Aperture or Shade that replaces another object (complete with its own modifier, geometry and children objects), it's looking like dynamic modifiers on the ModifierSet will be much more difficult to implement. Maybe we just leave this idea on the back burner as a wish/discussion.

[chriswmackey]

Now that I have gone through the whole implementation of dynamic objects, I see that there's a major flaw in the idea of a "dynamic modifier" that can be assigned to a ModifierSet. This is that the logic for how different apertures are grouped is not inherent in the dynamic modifier and any default behavior that we could think of (like exporting each aperture geometry with a dynamic modifier into a separate group) is rarely desired.

So, if we end up implementing something like this, there will have to be some rules that govern when the dynamic modifier takes effect like:

1. All apertures that are assigned the dynamic modifier will only be dynamic if they have a dynamic_group_identifier. Otherwise, they will be static and just have the modifier of the first state of the the dynamic modifier.
2. If someone actually assigned specific states to an aperture with a dynamic modifier assigned to it, the specifically-assigned states take precedence over those of the dynamic modifier.