1,今天上午主要工作在看vertex blending,主要原因是考虑换装系统的设计和武器挂接的实现
在网上找到一个开源的实现，叫shanguang在csdn的blog
还看到一个架设wow的实现，恩，要去分析下服务器端的实现
还看了一篇文章分析天龙八部的客户端水平的，咔咔
接着说vertex blending，骨骼的实现和表皮的实现都很简单
a，骨骼的实现主要有两点，各个骨头之间的关联关系（就是把层次树给表示出来），然后是每个动作每一帧各个骨头的相对位置和角度, 这两者之间的关联是通过骨头的序号来关联的
b,皮肤的实现更简单，就是用点拉一个三角形网格，给出每个点的法向量，对应的纹理坐标，与光作用的系数，以及采用的光照方程和shading方程
但是如何对点采权重就很难猜出来，可以为皮肤指定多套骨骼，本质是建立皮肤的点和骨骼点之间的关联关系，可是这个过程如果手动指定就太过于麻烦，比如几千个点的手动指定是完全不能接受的事情。
如果程序来做这个事情，最简单的就是离谁近就指定给谁，权重为1，然后手动调整
再进一步，不光计算离谁最近，还要看最近的点在骨骼上的位置，如果在两个的边缘，就用一定的方式分别赋予权重，本来是想利用距离赋值，可是real -time rendering给了一个例子，似乎是说这样不太好
还可以进一步拓展，如果同时离几个骨骼都在边缘范围内，就分别赋予权重，然后让用户手动调整
遗留了real -time rendering的4页书没有看
2，下午开始看如何在wtl内嵌ogre,号称内嵌，其实也是一样调用已经写好的类做一些东西，唯一的区别在于要让ogre的renderwindow始终是某一个控件
这个问题很好明白
用windows api建立窗口程序应该是做了这么三个过程，
a,用某种方式建立起控件之间的关联关系，我以前以为所有的都是用vc的这种拖拽方式，后来觉得windows api 可能不是，是通过程序来指定之间的关联关系
这一步相当于建立了外观
b,每个线程拥有一个消息循环和消息队列，如果有消息队列进入线程，线程将消息取出，根据位置判断是谁的，然后在消息循环里面进行处理
但是对windows api还是不明白，对原来明白的wtl在干什么也糊涂了
基础是重要的，是要好好弥补的！
是需要经常性的复习的
3，然后开始想如何内嵌ogre，ogre作为一个评价这么高的引擎，肯定是引了头文件和dll，然后在里面开始用就成了，但是ogre初始化都做了什么，
恩，真好，既不懂wtl的原理，也不懂ogre启动的过程
4，后续时间在看variance SM
SM的原理很简单，但是real time rendering关于适用于什么光源这块说的很奇怪，spotLight没问题，但是direction light似乎不成啊，我们是把camera放在一个点上，然后生成z-buffer，这样不能用于direction light
本质是这么回事，如果在一个只有一个光源的场景里面，如果这个场景还没有像镜子一样的强反射体，那么在这个光源看来，只有他能看到的是有光亮，剩下的都是没有光亮的，因为如果一个物体看不到，说明在它和光源之间必然有物体进行遮挡，
所以2次渲染，先以光源的位置来渲染下，然后再用真实的camera的位置进行渲染
但是判断一个物体是否在阴影里面，需要查找第一次的z-buffer,这肯定会导致alias，另外一个恶心的问题是z-flighting导致的self-shadow
对于alias，一个办法是取多个点进行平均，这样可以让边缘的点的颜色没有那么是非分明，让锯齿看上去不那么明显
但是这个方法带来的是效率上的下降，要取多个点，还要对多个点进行平均，
如果能对之前得到的z-bufffer进行滤波，据说能得到更好的结果，于是，大家级想能不能进行滤波，
variance SM 就是为了滤波提供的，本来滤波是不行的，因为我们进行的是比较，非黑即白，
于是variance SM 就存贮了另外一个数据，对分布的概率进行分析，能够得到一个概率说自己在一个什么样的区间，这样就可以不用非黑即白
但是这个也有一点问题，本来之前只是在边缘处，有可能出现大于小于同时出现的情况（这句话是否正确需要清醒的时候去想一下）
现在在全区域内都变成了一个概率事件，注意到不等式是利用放缩实现的，在一些极端情况下可以出现很变态的结果
我举个例子， 四个点分别高度是100，100，900，900，比如某个地方出现一个断桥，下面有遮挡物，形成一个很大的方差，400
那么如果在900的底下1100位置有个物体，算概率，概率竟然为1，
这主要是在出现断层的时候会很恶心，当然这么大的论文便宜肯定有人发现了，还有新的论文去弥补，恩，我先睡觉，明天接着去看
