好长时间没更新了
这段时间一直都在忙着写CoagelEngine，没时间上来更新。花了一个月的时间，现在基本把渲染器的框架写好了。渲染器是用Visitor模式实现的。同时API无关，理论上来说同样可以支持Directx，不过我没用过DX，现在只实作了GLRender。通过在场景的主节点Root（唯一）上调用Root->accept（GLRender*），就可以自动的渲染整个场景，GLRender会遍历整个场景图，智能的判断需要渲染的物体是什么类型，比如是Camera，TriMesh，TriStrip，BSpline等等。
场景中的每个节点都可能在程序运行时刻改变，比如Camera会相应键盘和鼠标来改变当前的视点，地形和复杂几何体会根据视点不同改变Lod等级，粒子系统会根据时间改变，骨骼动画等等，为了实现对这种功能的支持，我开始的设计是在每个节点上维护一个CallBack的链表（也可以是vector），当Render访问到这个节点的时候，先执行CallBack，然后再往下遍历，或者是渲染当前节点。但是后来在实作纹理调度机制时发现这种方法有会使程序的结构变得很混乱，最后确定用另外一个Visitor来实现两次遍历。也就是说，先用一个UpdataVisitor来遍历场景图，改变所有的节点，然后再用RenderVisitor来渲染。这种方法可以提供更优雅的程序结构，但是会有一定的性能损失。不过通过对整个场景图的良好的组织和限制，这种损失可以被限制在一个可接受的范围。
纹理调度策略：我希望能实作出比较合理的纹理调度策略，并且这种策略也可以用到其它的数据调度上。目前的设计是这样的。有一个texture Class来管理纹理，然后用一个textureGroup来管理多个texture class。当我要把1 个或多个纹理附给一个物体时，我就把一个texture group传给这个物体。但是这个时候，系统并没有初试化这些纹理，也就是说，纹理还在系统内存中，而不在显存中。只有当一个物体
确实需要被渲染时，才将它带的纹理传到显存中。当这个物体被从场景图中删除时，textureGroup也被删除。本来最初的计划是每个texture class只能属于一个特定的texture group。但是这样就不能实现不同
texturegroup中texture的共享。比如场景中的一面墙和很远处的另一面墙具有同样的外观，如果不能共享纹理，就会造成同样的纹理需要被创建两次，浪费了系统时间和显存。因此用smartPoint来管理texture class是一个更合理的选择。只有当所有需要这个texture class的group都被删除时，这个texture才被删除。
场景中的每个节点都可能在程序运行时刻改变，比如Camera会相应键盘和鼠标来改变当前的视点，地形和复杂几何体会根据视点不同改变Lod等级，粒子系统会根据时间改变，骨骼动画等等，为了实现对这种功能的支持，我开始的设计是在每个节点上维护一个CallBack的链表（也可以是vector），当Render访问到这个节点的时候，先执行CallBack，然后再往下遍历，或者是渲染当前节点。但是后来在实作纹理调度机制时发现这种方法有会使程序的结构变得很混乱，最后确定用另外一个Visitor来实现两次遍历。也就是说，先用一个UpdataVisitor来遍历场景图，改变所有的节点，然后再用RenderVisitor来渲染。这种方法可以提供更优雅的程序结构，但是会有一定的性能损失。不过通过对整个场景图的良好的组织和限制，这种损失可以被限制在一个可接受的范围。
纹理调度策略：我希望能实作出比较合理的纹理调度策略，并且这种策略也可以用到其它的数据调度上。目前的设计是这样的。有一个texture Class来管理纹理，然后用一个textureGroup来管理多个texture class。当我要把1 个或多个纹理附给一个物体时，我就把一个texture group传给这个物体。但是这个时候，系统并没有初试化这些纹理，也就是说，纹理还在系统内存中，而不在显存中。只有当一个物体
确实需要被渲染时，才将它带的纹理传到显存中。当这个物体被从场景图中删除时，textureGroup也被删除。本来最初的计划是每个texture class只能属于一个特定的texture group。但是这样就不能实现不同
texturegroup中texture的共享。比如场景中的一面墙和很远处的另一面墙具有同样的外观，如果不能共享纹理，就会造成同样的纹理需要被创建两次，浪费了系统时间和显存。因此用smartPoint来管理texture class是一个更合理的选择。只有当所有需要这个texture class的group都被删除时，这个texture才被删除。
