2005.3.22
1.开始制定开发计划
2.总结先前累计的若干基本功能模块.
2005.4.8
1.基本场景建立,4叉树+ROAM地形,多重纹理AlphaMap,物体模型分布,水面,天空.
2005.4.11
1.今天随便看了一下HL2分析的文章,觉得HL2的MaterialSystem非常好,非常对我的脾胃,决定采用.
2005.4.14
1.加入最简单的室内场景.
2.开始研究HL2的MateiaSystem,并移植入DestinyMatrix,当前的主要任务是建立MaterialSystem.
2005.5.3
1.这两个星期忙于现实工作,所以一直在思考引擎实现框架的设计问题,各大模块之间的责任和协作到底如何,思绪渺渺.
较之,HL2于大局架构把握上层次更高,游戏引擎/渲染系统(MaterialSystem)/底层渲染API实现(ShaderAPI),通观全局,层次分明,接口手法也很符合规范.但,HL2的具体实现实在够乱,接口的具体语义逻辑实在牵强,不够平民化,调用环节过多,我想它没能完成OpenGL的实现,也跟它在逻辑语义抽象上的局限性有关.特别她把渲染状态管理放在API实现层,有DX的实现,那Opengl怎么实现DXX的概念,可能是未完成的版本.相较其他引擎,明显的看出它作为商业级的产物,架构,编译速度,代码更符合现实程序实践.
OpenSceneGraph的在接口逻辑设计上比HL2清晰,Geometry,Material,StateSet的语义逻辑更明确,更灵活,具有极强的伸缩性,但它没有大局架构,没有API和总体层次间的隔离机制,我估计效率也不太好,几个Demo都很慢,而且是为VR设计的,而不是游戏.
Torque的结构实在是不敢恭维,网络,脚本,图形,场景管理代码一起堆,客户端和服务端代码一起堆,编辑器和引擎代码一起堆,是个高大全的产物,实际结果确实是高大全,直接就用脚本写服务器和客户端了.她的总体设计目标和思路都与其他引擎不同,她想直接用以别人作游戏.不过她的场景图的算法思路很好,网络实现也很强,效率不错.
Ogre号称面向对象,而我却以为是肤浅的面向对象,基本上没有接口语义概念,除了一堆的Singleton Manager就看不到其他设计模式了,依靠强制的C++技法来实现,如C++单体类,C++跨DLL继承等手法,在概念抽象上比较强硬,如Material就来个Techniche数组,Techniche就来个Pass数组,简单的用一个类包装一个观念,实际上没能很好地抽象出其中的关键逻辑.为了达到它可扩展的目的,连场景图算法都丢进去了,有必要吗?
2005.5.16
推翻原来的设计,采用HL2引擎的3层结构,借鉴OpenSceneGraph的操作手法,统一了渲染逻辑,为渲染状态的管理打下了基础.
接下来开始深入剖析渲染状态的表达,并增强渲染逻辑的广泛适用性.然后采用OpenSceneGraph的算法进行管理.
2005.5.17
开始编写场景图DmSceneGraph,渲染状态封装DmStateSet,以及场景图与渲染状态之间的树型关系维护,进一步统一IRenderCraft的接口.
2005.5.19
不切实际!如何将多种场景管理算法融合进一个SceneGraph呢?然后才是渲染状态排序实现.谁能告诉我是对还是错,只是命运的折磨不住地困扰着我,sigh.