The Script operator provides advanced control over particles, using C#.
tyFlow’s script operator is fast. Combined with its multithreading capabilities, it performs nearly as fast as native c++ code, and is suitable for very complex tasks.
An exhaustive API of all tyFlow-related C# functions and parameters can be found within each Script operator’s editor window, by clicking the “API” button. Users may also reference other C# libraries accessible from Max.NET, like the Math library, for common functions. An internal “Mathf” library has also been added, which is a float-based alternative to the default “Math” library (ex: “Mathf.Sin(…)” returns a float where “Math.Sin(…)” would return a double). Using the “Mathf” library avoids the need to continually cast doubles to floats.
Normally it’s possible to create a static flow (a flow which only evaluates during particle birth) if no operators in the flow adjust the velocity/spin of particles. Without velocity/spin, once particles are born they will remain unchanged…thus, tyFlow can avoid repeatedly evaluating them. Static flows are great for scattering setups where you don’t need particles to continually update. However, the presence of a Script operator in a flow normally prevents it from being static, because prior to script evaluation in the simulation pipeline, tyFlow has no way of determining whether a user’s script will change particle properties over time (so it must assume the flow is never static). By enabling the “allow static evaluation” function, you can override this behavior and tell tyFlow not to worry about evaluating the Script operator if the rest of the flow is static as well. When enabled, it means the Script operator will only be evaluated during the non-static interval of the simulation, listed at the bottom of the editor window.
Script-accessible objects are scene objects that you wish to access directly from within a script.
Scene objects that you wish to access directly from within a script must be registered with the script operator by adding them to the script-accessible object list. Once an object is added to the accessible object list, it can be accessed from within a script using its script-accessible name (displayed in square brackets within the object list). For example, a sphere object added to the list might be displayed as “[obj001] Sphere001”, which can then be accessed within the script by the name: obj001.
Script-accessible texmaps are scene texmaps that you wish to access directly from within a script.
Scene texmaps that you wish to access directly from within a script must be registered with the script operator by adding them to the script-accessible texmap list. Once a texmap is added to the accessible texmap list, it can be accessed from within a script using its script-accessible name (displayed in square brackets within the texmap list). For example, a bitmap texture added to the list might be displayed as “[tex001] Map #1”, which can then be accessed within the script by the name: tex001.
Assemblies listed here (full paths separated with a semicolon) will be loaded by the C# compiler and their API (if they are loaded successfully) will be accessible within C# scripts.
Assemblies in the 3ds Max root directory can be referenced using the $MaxRoot symbol. Ex: “$MaxRoot\ManagedServices.dll”. If you have trouble loading an assembly not bundled with 3ds Max, try adding it to 3ds Max’s C# assembly folder ($MaxRoot\bin\assemblies) before importing.
If your script (accidentally) contains a while-loop that never breaks (exits), it will freeze Max once it executes. By enabling ‘Shift+ESC’ protection, you can force tyFlow to exit out of any script’s while loop by holding Shift+ESC on the keyboard.
By default, every time a custom data channel is accessed by its channel name, tyFlow must convert the string to a hash and then do a hashmap lookup to find the value of that channel for a particular particle. Doing such queries on huge numbers of particles can be very slow. Keeping this optimization enabled will greatly speed up all custom data access, as it manually moves hashmap lookups outside of all particle iteration loops, caching the resulting values for later use.
This should only be disabled for testing purposes.