Regardless of the type of plugin developed, the process is similar: a new class is derived from an existing one, functions are overloaded as needed, and the class is then registered in the MotionBuilder registry. You do not need to explicitly call the functions of the new class as MotionBuilder will call them correctly, based upon the type of plugin. For example, a device will overload the I/O and evaluation functions in the FBDevice class, and register itself as a device. The user adds a device in the interface and the new (overloaded) device functions are automatically called in the correct thread with no intervention by of the developer.
MotionBuilder has a multi-threaded engine which aims to optimize real-time performance by increased utilization of given single core. Separate threads having different priorities are launched in parallel. For example, device input/output, constraint evaluation, model deformation, and rendering may each be done in separate threads.
Threads like the IO thread might be given higher priority than constraint evaluation, model deformation, or rendering to ensure no device input is lost. Threading priority is configured in config/[machine_name].Task.txt.
In the MotionBuilder polling model, the plugin exposes callback functions that are called by the real-time engine. The plugin does not directly call any functions in the engine. Any extra threads or processes running parallel might seriously slow down performance or even prevent MotionBuilder from running at all.
Optimize for real-time by minimizing the CPU time in the evaluation threads of AnimationNodeNotify, DeviceIONotify. Callbacks exist for constraints, models, and devices, and can be used in many ways.
High-priority device evaluation threads. When a device is active, these threads call FBDevice::DeviceIONotify() at a frequency defined by FBDevice::SamplingPeriod in m s (default 30Hz). Execution time should be kept to a minimum because of the CPU bandwidth they require.
These evaluate operators, constraints, and devices propagating data from source objects (such as input devices) through constraints, and possibly back out to output devices. They propagate calls to FBBox::AnimationNodeNotify() in devices and operators. Another example is the deformation thread: the engine uses lazy evaluation to evaluate what is needed. For example, animation nodes on devices are not called if a device’s playback mode is set to 'recorded', if a device is offline, or if a node has already been evaluated and it is known that its data is still valid.
The UI refresh is separated from all other threads. The UI thread manages UI events and refreshes the views and other UI components as needed. The real-time rendering engine executes in this thread.