Access Constraints are used in two ways in STK:
Many constraints require additional configuration data to be set by the user. For example, all Min/Max constraints require a min and/or max value be set; the lighting constraint requires the setting of a lighting type; the object exclusion constraint requires an STK object and exclusion angle. The configuration data is held by STK objects as part of their constraint settings. Thus, each constraint should be viewed as a pairing of (i) a computational algorithm; and (ii) configuration data required by the computational algorithm.
The pairing of the algorithm with its configured data, for use as a computational entity, occurs in a PreCompute step, culminating with an activated constraint component. The activated component is initialized with its data and any other data needed from the two objects involved in the access computation. Once activated, the constraint component can compute its metric. The metric value may be used in an event detection algorithm to determine time intervals satisfying some condition (e.g., elevation angle >5 degs) or simply be used as an important characteristic of an analysis, depending on the tool using the access constraint. Once the tool no longer needs to compute with the access constraint, it is deactivated in a PostCompute step.
The PreCompute, Compute, and PostCompute steps describe the computational lifecycle of every constraint. This lifecycle has ramifications on the lifecycle of the plugin component.
Note: Most importantly, the author of an Access Constraint Plugin must be aware that a plugin component may be created and destroyed many times, depending on how it is used by STK--there is not just one instantiated plugin component that lives for the lifetime of STK.
Access constraints apply to a pairing of STK objects. Some constraints (e.g., elevation angle) may be applied by both STK objects. [This depends on whether the constraint has been registered to do so.] Even if the same constraint is active for each object, different activated constraint components will be created because they may (and probably will) have different configuration data. The access constraint plugin is no different: if the constraint is registered on both objects then it may be applied by a user to both objects and two activated plugin components will be created, one for each object. In one case, one object will be the Base object with the other being the Target; in the second case, the objects will switch the Base-Target designations.
Currently, when visibility intervals are being computed, the entire collection of applicable access constraints are first activated, initialized by calling Init(), and then PreCompute() is called on each one. This is done before any constraint is evaluated. Once all visibility processing is completed, PostCompute() is called on all the activated constraints, and then each is freed using Free() and destroyed.
In general, the lifecycle for plugin components follows the same lifecycle as that outlined above. However, additional considerations must be addressed when using an access constraint plugin component as a metric in a Figure of Merit.
Currently, each time step in the animation graphics of Figure of Merit objects causes a complete computational lifecycle for plugins. That is, for every animation time:
Note: Because the plugin is instantiated and freed at every time step, no plugin component can 'remember' information from one time step to the next.
Note: For faster animation, avoid doing IO (like, for example, logging to a log file) during any of the plugin's calls.
STK Programming Interface 11.0.1