IBase->ILTModel->ILTModelClient,这个接口体系是设计来提供给GameCode使用的,GameCode是EngineCode的Client.
但这里的ILTModel不能理解为1个Model概念的抽象.LithTech将所有的EngineObject抽象成一个HOBJECT句柄交给GameCode,而不是抽象成接口对象.而这里的ILTModel接口实际起着函数空间namespace的作用,将Flat函数空间转成有层次的命名函数空间,ILTModel interface contains functions for manipulating models and animations.
ILTModel的实现类没有成员变量,因此它的接口方法接受一个HOBJECT hObj,这是一个之前由Engine传出的ModelInstance对象.HOBJECT定义是LTObject*, ModelInstance继承于LTObject,所以ModelInstance是HOBJECT.ILTModel的实现类将HOBJECT强转成ModelInstance以获得实际操作的目标.
所以,ILTModel作为模型函数族接口,代理处理有关Model型HOBJECT的业务,此后代码流转入CLTModelClient的实现,再转入ModelInstance.
WorldTreeObj->LTObject->ModelInstance,场景图中的EngineObject继承于LTObject,这样ModelInstance作为一个独立的EngineObject,有着自己的位置/大小/骨骼动画控制状态成员变量等.很明显,我们不能也不用为每个ModelInstance存储基本的模型物理数据(如顶点数据等),所以其必然使用一个Model*数据,以得到不变的Model的物理模型数据.实现上,ModelInstance将这个指针放在成员变量m_AnimTracker内,使用GetModelDB取出.
Model & ModelNode: 这里的Model表达出一个物理上的模型的概念(物理图形数据),我们定义这种概念为Data Base.多个ModelInstance会使用或指向同一个的Model,她们之间是使用关系.那么,Model不应该拥有游戏环境属性数据(如位置,朝向及与游戏环境相关的数据),只应该拥有自身的物理图形自然数据.
Model模型数据本身也应该是一棵树,她使用ModelNode结构数组加指针子树,来管理模型的树型坐标系统.ModelSocket是模型绑定口,其他的Model可以绑定到Socket上以形成复合模型,ModelSocket绑到1个ModelNode上,完成概念上的统一.但ModelSocket不同于ModelNode,ModelSocket有自身更高级的模型绑定概念数据要维护.
Model包含m_StringList,一个单向ModelStringList链表,以存储并维护Model所载入的字符串数据,这样存储块明晰且节约空间.Model的所有子对象要加载字符串数据时,应调用Model的LoadString方法.
CModelMgr: 简要地管理当前引擎加载的所有的Model实例对象.
ModelNode: ModelNode节点树结构以维护Model内部的坐标系统的层次关系.
AnimTracker: 作为一个独立的对象跟踪Model下的一个ModelAnim的运动情况(运动到第几帧等信息).似乎当操作多个Model体系中的类对象时,用C风格函数更能表达逻辑,因为此时的逻辑不能严格归属某类,所以采用了trk族函数来处理AnimTraker和Model,ModelAnim之间的交互.
TransformMaker是骨骼系统的算法核心实现类,由ModelInstance::UpdateCachedTransformsWithPath，ModelInstance::UpdateCachedTransforms启动.
动作过渡机制的调用堆栈
trk_SetCurAnim(LTAnimTracker *pTracker, uint32 iAnim, bool bTransition)
ILTModel::SetCurAnim(HOBJECT hModel, ANIMTRACKERID TrackerID, HMODELANIM hAnim)
CLTClient::SetModelAnimation(HLOCALOBJ hObj, uint32 iAnim)
LTAnimTracker中m_TimeRef记录了动作信息,这个名字起的不好.