MLSCC (Magic Light Show Creator Center)
MLSCC is a powerful tool for creating light shows, consisting primarily of two major modules: light group creation and management, and lighting performance arrangement and control. It can achieve complex and diverse lighting effects, offering immense creative space. My demonstration scenario only showcases a small fraction of the achievable performance effects.
However, MLSCC is also a rather challenging plugin, with the difficulty mainly lying in understanding its control logic and working mechanism. After all, designing a light show requires not only good creativity but also comprehensive consideration and proper control of various performance details. This determines that MLSCC cannot be a simple plugin with a low entry threshold. Therefore, I will introduce MLSCC to you from the perspective of concept explanation and logical relationship clarification as much as possible.
Section 1: Creation and Management of Light Groups (MLSLightGroup.cs)
When setting up a light show stage, it is often necessary to create numerous empty atoms and utilize the HPVL plugin to achieve volumetric lighting effects. Creating and organizing these empty atoms can be time-consuming and labor-intensive, leading to a large list of scene atoms that are inconvenient to search and manage.
MLSLightGroup.cs effectively addresses the issue of light group creation. MLSLightGroup.cs needs to be loaded onto an empty atom. Each empty atom loaded with MLSLightGroup.cs serves as a light group, and the name of the empty atom serves as the light group name. You can create multiple light groups in the scene based on your needs.
MLSLightGroup.cs supports the creation of rectangular and circular (or arcuate) arrays, allowing customization of parameters such as the number of lights (rows and columns) and spacing.
After setting these parameters, you need to click "Build Light Group" to create the light group. Each time you modify the parameters, you need to click "Clear Light Group" first to remove the existing light group and then click "Build Light Group" to complete the creation. The created lights are named with the "light group name" followed by a "_four-digit sequence number", such as "LightGroupA_0001". You can click the "Show Light Atoms" button in the plugin's operation panel to view the names of all the lights within the light group. Knowing the names of the lights will be helpful when setting up triggers later.
Each light group atom should not only load MLSLightGroup.cs but also the HPVL plugin. Due to plugin compatibility considerations, I have made some modifications to the HPVL plugin with the permission of PluginIdea. Please load the modified HPVL (MLSCC VAR package's \Custom\Scripts\PluginIdea\HPVL\HPVL_For_MLSCC.cslist) onto the light group.
After creating a light group, remember to perform the following two steps: 1) Reload HPVL_For_MLSCC.cslist (click the green "Reload" button); 2) Click the green "Initialize HPVL (After Reloaded)" button on the MLSLightGroup.cs operation panel to re-activate HPVL.
You may need to adjust some parameters of the HPVL plugin on the light group, such as "Independent Control," "Noise," "Y-axis Scale," etc. It's important to note that these manually set HPVL parameters are saved together with the parameters of MLSLightGroup.cs. If you have loaded MLSCC.cslist in the scene, the HPVL parameters will be automatically saved every 5 seconds. If MLSCC.cslist is not loaded in the scene, you need to click the green "Manually Save HPVL Settings" button on the MLSLightGroup.cs operation panel to save the parameters. Remember, if you ultimately do not save the scene file, all previous saves will be meaningless.
Additionally, during the stage setup process, you may still need to use HPVL independently. However, due to game mechanism limitations, HPVL plugins from different VAR packages cannot be used simultaneously (which will result in errors). Therefore, I have also included the original version of HPVL in the MLSCC VAR package (\Custom\Scripts\PluginIdea\HPVL\HPVL.cslist) for independent invocation.
Both the modified and original versions of HPVL are copyrighted by PluginIdea.
Section 2: Choreography and Control of Light Shows (MLSCC.cslist)
Firstly, it's important to understand some basic concepts when controlling lights.
1. AGroup (Action Group): A collection of one or more performance actions (Actions). You can think of it as a "performance segment" and the basic unit for directing and scheduling light shows. Typically, during a light show, only one AGroup is performing at a given time. For more complex light shows, it is also allowed to have multiple AGroups performing simultaneously, But this requires a higher standard for creators, due to the more complex scheduling and control involved to achieve the desired performance effect. In terms of plugin functionality, all of these are fully supported.
2. Action: This refers to the arrangement of action instructions for specific light groups and individual lights. Within the same Action, all designated light groups and lights perform the same action (even though the specific instruction parameter values can be different for different light groups and lights, such as incremental changes or random values. Don't worry if this doesn't make sense right now, you'll quickly understand it during actual use).
Note: In a "performance segment", it is often necessary for different lights to perform different actions and cooperate with each other to achieve the desired performance effect. This is why the concept of AGroup exists.
An Action can not only operate multiple light groups and lights simultaneously, but also multiple attributes at the same time. Detailed explanations of attributes are provided below.
3. Property: The essence of a light show is to present colorful and vibrant performance effects through changes in the attribute values of light groups and individual lights. Properties are divided into two main types:
a) Group Properties: These properties are essentially some of the parameters of the HPVL plugin in a light group atom. Changes in these properties will affect all the lights within the light group. They include: "Angle", "Intensity", "Radius", "FadeEnd", and "Color".
b) Light Properties: These control the attributes of each light atom within a light group. They include: "Pitch", "Yaw", "YawAlt", "Switch" for toggling the atom on or off, and "Lightness" for independent brightness control.
Within an Action, you can initiate control of one or multiple properties, specify whether each property should perform in a loop, and set their movement patterns, which include: "Process" for continuous gradual changes, "Event" for non-continuous changes, and "Fellow" to follow external variables. You can also specify their waiting time (no action, waiting for the performance to start), warm-up time (entering the initial state of the performance), and cool-down time (waiting after the performance is completed, before entering the next loop if needed).
All time settings support three modes:
• "Fixed" (applicable to all objects affected by the current property)
• "Random" (for each object affected by the current property, a random value is taken within the given range)
• "Incremental" (for each object affected by the current property, whether it's a light group or an individual light, a certain amount is added to the given initial value).
4. MNode (Motion Node): As we know, the core of a light show performance based on properties is the change in attribute values. The role of the Motion Node (MNode) is to describe the process of how attribute values change. You can think of an MNode as a keyframe in a timeline, which describes the time point and the value to be reached (like time, the setting of values also supports the three modes of fixed, random, and incremental). Additionally, when the movement pattern of a property is set to "Process" for continuous gradual changes, you can also specify the way of entering the current motion node (including "Normal" for constant speed, "Accelerate" for increasing speed, and "Decelerate" for decreasing speed).
You can also set triggers on motion nodes, which is a very useful feature. Triggers can be used to achieve transitions between multiple performance segments and any other instructions you desire. To do this, you first need to determine a tracking target atom within the scope of the current property's action. If the current property is a group property, the target atom should be a light group; if it's a light property, the target atom should be a light. When specifying the tracking target atom, you need to enter the full name of the atom. This is where the significance of viewing the names of lights within a light group comes into play. When the cumulative count of the tracked atom reaching the current motion node reaches the threshold you have set, the trigger will be activated. You can specify whether the trigger is a one-time activation or can be repeatedly triggered. After each trigger, the previous cumulative count will be reset.
In summary, an Action Group (AGroup) comprises one or multiple Actions, serving as the basic unit for directing and scheduling a light show performance. An Action, in turn, consists of one or several Property animations, specifying the scope of these animations (which light groups and individual lights they operate on). Each Property animation is described by one or more Motion Nodes (MNodes), where triggers can be set to implement various complex logics.
When an Action Group (AGroup) begins its performance, all the Property animations contained within its Actions start simultaneously. The performance process follows these steps: Waiting Period → Warm-up Process: Setting the Property to its initial value based on the MNode settings and waiting for the warm-up to complete → Transition Process: Completing the change in Property values according to the MNode settings → Cool-down Period: Waiting for the cool-down to finish → If the performance mode is set to "Loop," the process returns to the warm-up stage; otherwise, the performance ends.
Section 3: Operating Guidelines
1. Triggers
Triggers were mentioned earlier when discussing Motion Nodes (MNodes). Here are some additional explanations. When setting a trigger, you can choose whether it is an "internal trigger" or not. If it's an internal trigger, when activated, it will call an Action Group (AGroup) within the current MLSCC. You just need to fill in the desired Action Group name in the "Trigger Action" field. If it's not an internal trigger, you must ensure that a SelectChoice plugin is loaded along with the MLSCC.cslist atom. Fill in the name of the desired SelectChoice option in the "Trigger Action" field. When the trigger is activated, the relevant option will be executed. The specific instructions to be executed within the option are entirely up to you.
2. Following External Variables
As mentioned earlier when discussing Properties, the motion mode can be set to "Follow" to track an external variable. To do this, you need to ensure that a VUML plugin is loaded along with the MLSCC.cslist atom. In the property settings interface, fill in the name of a floating-point variable from VUML in the "Refer To" field (usually, the value of this variable should be between 0 and 1). You also need to set two Motion Nodes (MNodes) for the current property. After the performance starts, the value of this property will change accordingly between the values set in the two Motion Nodes, based on the variation of the VUML floating-point variable.
If a property adopts the "Follow" motion mode, its performance will not end unless it is initialized or overwritten by another performance segment.
3. Externally invoke an Action Group (AGroup)
MLSCC provides a JSON variable named "AGroup Name" and a JSON action named "Perform The AGroup". By setting "AGroup Name" to the desired Action Group name and executing "Perform The AGroup," you can externally initiate an Action Group.
4. Light Group Initialization
It is strongly recommended that you create at least one Action Group specifically for initializing your light groups. This Action Group should reset your light groups to an ideal state for the next performance segment. MLSCC does not provide a default initialization Action Group because initialization requirements vary greatly depending on the performance needs. It is more appropriate to leave it up to the creator to arrange. Sometimes, you may even need to set up different initialization Action Groups for different light groups on the same stage (as in my DEMO scenario). The time for initializing light groups is short, but usually, you should allow 3 to 5 frames for the initialization actions to complete thoroughly.
After initialization, I generally recommend using triggers to call subsequent performance segments. This calling mechanism is flexible, giving creators a lot of customization space. However, due to this high level of freedom, newer users may find it confusing.
5. Switch Properties of Light Atoms
A light atom has only two states: on and off. In the MLSCC system, all property values are floating-point types. Therefore, we stipulate that when the Switch property is greater than or equal to 0.5, the state of the light atom is on; otherwise, it is off.
6. Independent Brightness Properties "Lightness"
When HPVL controls a group of lights, it allows each light atom to independently control its brightness. This is a new feature added to the HPVL plugin later on. Properties like "Lightness" work in tandem with this new feature. Therefore, if you want to enable this property, remember to check the "Independent Control" option in the HPVL plugin for the light group atom (it is unchecked by default as this feature can have some performance overhead).
Finally, the inherent complexity of light show design determines that MLSCC cannot be a simple plugin. Designing a large-scale light show stage also requires a good foundation in plugin usage, such as familiarity with the LogicBricks series of plugins, VUML plugin, ActionGroup plugin, and so on. I have tried my best to include all the important content in this document, but there may still be omissions. Feel free to communicate with me anytime during use.
MLSCC is a powerful tool for creating light shows, consisting primarily of two major modules: light group creation and management, and lighting performance arrangement and control. It can achieve complex and diverse lighting effects, offering immense creative space. My demonstration scenario only showcases a small fraction of the achievable performance effects.
However, MLSCC is also a rather challenging plugin, with the difficulty mainly lying in understanding its control logic and working mechanism. After all, designing a light show requires not only good creativity but also comprehensive consideration and proper control of various performance details. This determines that MLSCC cannot be a simple plugin with a low entry threshold. Therefore, I will introduce MLSCC to you from the perspective of concept explanation and logical relationship clarification as much as possible.
Section 1: Creation and Management of Light Groups (MLSLightGroup.cs)
When setting up a light show stage, it is often necessary to create numerous empty atoms and utilize the HPVL plugin to achieve volumetric lighting effects. Creating and organizing these empty atoms can be time-consuming and labor-intensive, leading to a large list of scene atoms that are inconvenient to search and manage.
MLSLightGroup.cs effectively addresses the issue of light group creation. MLSLightGroup.cs needs to be loaded onto an empty atom. Each empty atom loaded with MLSLightGroup.cs serves as a light group, and the name of the empty atom serves as the light group name. You can create multiple light groups in the scene based on your needs.
MLSLightGroup.cs supports the creation of rectangular and circular (or arcuate) arrays, allowing customization of parameters such as the number of lights (rows and columns) and spacing.
After setting these parameters, you need to click "Build Light Group" to create the light group. Each time you modify the parameters, you need to click "Clear Light Group" first to remove the existing light group and then click "Build Light Group" to complete the creation. The created lights are named with the "light group name" followed by a "_four-digit sequence number", such as "LightGroupA_0001". You can click the "Show Light Atoms" button in the plugin's operation panel to view the names of all the lights within the light group. Knowing the names of the lights will be helpful when setting up triggers later.
Each light group atom should not only load MLSLightGroup.cs but also the HPVL plugin. Due to plugin compatibility considerations, I have made some modifications to the HPVL plugin with the permission of PluginIdea. Please load the modified HPVL (MLSCC VAR package's \Custom\Scripts\PluginIdea\HPVL\HPVL_For_MLSCC.cslist) onto the light group.
After creating a light group, remember to perform the following two steps: 1) Reload HPVL_For_MLSCC.cslist (click the green "Reload" button); 2) Click the green "Initialize HPVL (After Reloaded)" button on the MLSLightGroup.cs operation panel to re-activate HPVL.
You may need to adjust some parameters of the HPVL plugin on the light group, such as "Independent Control," "Noise," "Y-axis Scale," etc. It's important to note that these manually set HPVL parameters are saved together with the parameters of MLSLightGroup.cs. If you have loaded MLSCC.cslist in the scene, the HPVL parameters will be automatically saved every 5 seconds. If MLSCC.cslist is not loaded in the scene, you need to click the green "Manually Save HPVL Settings" button on the MLSLightGroup.cs operation panel to save the parameters. Remember, if you ultimately do not save the scene file, all previous saves will be meaningless.
Additionally, during the stage setup process, you may still need to use HPVL independently. However, due to game mechanism limitations, HPVL plugins from different VAR packages cannot be used simultaneously (which will result in errors). Therefore, I have also included the original version of HPVL in the MLSCC VAR package (\Custom\Scripts\PluginIdea\HPVL\HPVL.cslist) for independent invocation.
Both the modified and original versions of HPVL are copyrighted by PluginIdea.
Section 2: Choreography and Control of Light Shows (MLSCC.cslist)
Firstly, it's important to understand some basic concepts when controlling lights.
1. AGroup (Action Group): A collection of one or more performance actions (Actions). You can think of it as a "performance segment" and the basic unit for directing and scheduling light shows. Typically, during a light show, only one AGroup is performing at a given time. For more complex light shows, it is also allowed to have multiple AGroups performing simultaneously, But this requires a higher standard for creators, due to the more complex scheduling and control involved to achieve the desired performance effect. In terms of plugin functionality, all of these are fully supported.
Note: In a "performance segment", it is often necessary for different lights to perform different actions and cooperate with each other to achieve the desired performance effect. This is why the concept of AGroup exists.
An Action can not only operate multiple light groups and lights simultaneously, but also multiple attributes at the same time. Detailed explanations of attributes are provided below.
a) Group Properties: These properties are essentially some of the parameters of the HPVL plugin in a light group atom. Changes in these properties will affect all the lights within the light group. They include: "Angle", "Intensity", "Radius", "FadeEnd", and "Color".
b) Light Properties: These control the attributes of each light atom within a light group. They include: "Pitch", "Yaw", "YawAlt", "Switch" for toggling the atom on or off, and "Lightness" for independent brightness control.
Within an Action, you can initiate control of one or multiple properties, specify whether each property should perform in a loop, and set their movement patterns, which include: "Process" for continuous gradual changes, "Event" for non-continuous changes, and "Fellow" to follow external variables. You can also specify their waiting time (no action, waiting for the performance to start), warm-up time (entering the initial state of the performance), and cool-down time (waiting after the performance is completed, before entering the next loop if needed).
All time settings support three modes:
• "Fixed" (applicable to all objects affected by the current property)
• "Random" (for each object affected by the current property, a random value is taken within the given range)
• "Incremental" (for each object affected by the current property, whether it's a light group or an individual light, a certain amount is added to the given initial value).
You can also set triggers on motion nodes, which is a very useful feature. Triggers can be used to achieve transitions between multiple performance segments and any other instructions you desire. To do this, you first need to determine a tracking target atom within the scope of the current property's action. If the current property is a group property, the target atom should be a light group; if it's a light property, the target atom should be a light. When specifying the tracking target atom, you need to enter the full name of the atom. This is where the significance of viewing the names of lights within a light group comes into play. When the cumulative count of the tracked atom reaching the current motion node reaches the threshold you have set, the trigger will be activated. You can specify whether the trigger is a one-time activation or can be repeatedly triggered. After each trigger, the previous cumulative count will be reset.
In summary, an Action Group (AGroup) comprises one or multiple Actions, serving as the basic unit for directing and scheduling a light show performance. An Action, in turn, consists of one or several Property animations, specifying the scope of these animations (which light groups and individual lights they operate on). Each Property animation is described by one or more Motion Nodes (MNodes), where triggers can be set to implement various complex logics.
When an Action Group (AGroup) begins its performance, all the Property animations contained within its Actions start simultaneously. The performance process follows these steps: Waiting Period → Warm-up Process: Setting the Property to its initial value based on the MNode settings and waiting for the warm-up to complete → Transition Process: Completing the change in Property values according to the MNode settings → Cool-down Period: Waiting for the cool-down to finish → If the performance mode is set to "Loop," the process returns to the warm-up stage; otherwise, the performance ends.
Section 3: Operating Guidelines
1. Triggers
Triggers were mentioned earlier when discussing Motion Nodes (MNodes). Here are some additional explanations. When setting a trigger, you can choose whether it is an "internal trigger" or not. If it's an internal trigger, when activated, it will call an Action Group (AGroup) within the current MLSCC. You just need to fill in the desired Action Group name in the "Trigger Action" field. If it's not an internal trigger, you must ensure that a SelectChoice plugin is loaded along with the MLSCC.cslist atom. Fill in the name of the desired SelectChoice option in the "Trigger Action" field. When the trigger is activated, the relevant option will be executed. The specific instructions to be executed within the option are entirely up to you.
2. Following External Variables
As mentioned earlier when discussing Properties, the motion mode can be set to "Follow" to track an external variable. To do this, you need to ensure that a VUML plugin is loaded along with the MLSCC.cslist atom. In the property settings interface, fill in the name of a floating-point variable from VUML in the "Refer To" field (usually, the value of this variable should be between 0 and 1). You also need to set two Motion Nodes (MNodes) for the current property. After the performance starts, the value of this property will change accordingly between the values set in the two Motion Nodes, based on the variation of the VUML floating-point variable.
If a property adopts the "Follow" motion mode, its performance will not end unless it is initialized or overwritten by another performance segment.
3. Externally invoke an Action Group (AGroup)
MLSCC provides a JSON variable named "AGroup Name" and a JSON action named "Perform The AGroup". By setting "AGroup Name" to the desired Action Group name and executing "Perform The AGroup," you can externally initiate an Action Group.
4. Light Group Initialization
It is strongly recommended that you create at least one Action Group specifically for initializing your light groups. This Action Group should reset your light groups to an ideal state for the next performance segment. MLSCC does not provide a default initialization Action Group because initialization requirements vary greatly depending on the performance needs. It is more appropriate to leave it up to the creator to arrange. Sometimes, you may even need to set up different initialization Action Groups for different light groups on the same stage (as in my DEMO scenario). The time for initializing light groups is short, but usually, you should allow 3 to 5 frames for the initialization actions to complete thoroughly.
After initialization, I generally recommend using triggers to call subsequent performance segments. This calling mechanism is flexible, giving creators a lot of customization space. However, due to this high level of freedom, newer users may find it confusing.
5. Switch Properties of Light Atoms
A light atom has only two states: on and off. In the MLSCC system, all property values are floating-point types. Therefore, we stipulate that when the Switch property is greater than or equal to 0.5, the state of the light atom is on; otherwise, it is off.
6. Independent Brightness Properties "Lightness"
When HPVL controls a group of lights, it allows each light atom to independently control its brightness. This is a new feature added to the HPVL plugin later on. Properties like "Lightness" work in tandem with this new feature. Therefore, if you want to enable this property, remember to check the "Independent Control" option in the HPVL plugin for the light group atom (it is unchecked by default as this feature can have some performance overhead).
Finally, the inherent complexity of light show design determines that MLSCC cannot be a simple plugin. Designing a large-scale light show stage also requires a good foundation in plugin usage, such as familiarity with the LogicBricks series of plugins, VUML plugin, ActionGroup plugin, and so on. I have tried my best to include all the important content in this document, but there may still be omissions. Feel free to communicate with me anytime during use.
