Description: allow models to contain state (and logic) separate from the entity the model represents. The logic could be used to update the model state just before the actual rendering occurs, as part of the model render loop.
Proposed Addition: add parameters/hooks/callbacks to the generic model render method. When the model is rendered, it must be passed more than just the entity position and rotation. If it is available on the client, the entity itself could be passed to allow for arbitrary information sharing between entity and model. The model must also be able to maintain and update it's own state. Each entity would need a dedicated model instance (as opposed to a stateless model instance being shared among multiple entities of a given type).
Specific Features: the model state could be updated during rendering, based on information provided by the entity but in decoupled fashion.
Justification and Use Case: this allows for the model to be modified many times more frequently than the entity it represents. It can also be modified in ways that might not have any meaning to the entity (e.g. visual effects).
Probably, none of this is very clear so far, so let me give an example.
In the THX helicopter mod, the helicopter rotor is part of the model. The rotor speed is taken from the entity (which is updated about 20/sec based on throttle control, etc). But the rotor position (angle of rotation) is controlled entirely by the model during the rendering cycle: the rotor position is changed by the current entity rotor speed times the delta time since the previous render call. This happens immediately prior to the actual rendering of the model.
This allows the rotor to move much more smoothly since the position is updated frequently (e.g. 60 FPS instead of 20). Without this, the rotor movement is choppy and unpleasing.
Another example: this same technique is used in the THX helicopter mod for the rotation (yaw, pitch, roll) of the helicopter itself. When the entity y,p,r is updated, the new values are passed to the model. But the model maintains it's own y,p,r state to allow for smoother motion. For this to work, the entity also has to share the current rate of change of the y,p,r.
Challenges Faced: too much logic/processing could slow down the rendering cycle. Logic would be limited to cosmetic effects upon model (e.g. no effect on entity behavior is possible).
Affects Version/s: Modding API launch or later
Component/s: client-side rendering extension loaded from server plugin? Could this be considered an "animation api"? perhaps there is some overlap