3d Game Walkman

每个人物2000多个多边形吧，我这边绘制基本上不是瓶颈，用了分组批量绘制，很省，计算骨骼放在其他核心上，用了无锁模式，不干扰主绘制线程，但如果是单核cpu估计会很惨

Max中的关键帧插值算法的确是比较复杂，可吃透它意义非同凡响啊

之前看过这篇文章，那个帧压缩算法我已经不需要了，我已经成功模拟实现了max的关键帧的差值算法，通过这个把星期的分析把曲线上的数据统统解出来而且吃透了，通过我的计算，目前是LINEAR这种方式，任意时间得到的各顶点的位置和max的一模一样，这样下来根本不用去做什么帧压缩了，max的动画曲线上有多少个节点我就导出多少个数据（导出的数据超乎想象的少，打个比方两点是一条直线，这条直线多长，我不用关心，因为直线上的任意一点我能计算出来，我只需要这两个关键点就好了，这才是真正的“关键帧”数据插值计算啊），而且这其中的意义不光在帧数据的剔除（过去的认识很肤浅，骨骼动画不能光是“播放”的），不同动画集动作之间的自动融合的问题用固定的帧数据去播放是无法解决的，想象一下一个动作没播完，而打断去播放下一个动作，这两个动作怎么去自动连贯起来呢？如果要做到自动连贯起来，那么过渡帧的数据是要用通过关键帧插值来融合计算的，这能大大丰富动作的连贯和动作组合的复杂度，通过研究和实现max的插值算法以后正好能很好的解决这个问题

我导出的数据仅仅只有各骨骼关键帧的旋转四元数（连位移都不需要，我发现骨骼的移动全部是上层旋转带动的，如果不考虑缩放，那么也骨骼根本没有自身的位移量，看曲线一目了然的），另外还有蒙皮姿势的各骨骼初始位置，和蒙皮姿势的Mesh各顶点，另外还有材质等数据，这些数据足以

目前在这个基础之上还实现了换装，也就是更换蒙皮骨骼部件的功能，主蒙皮的骨架计算影响到次级副部件的子骨架这样的功能，很快我差不多能实现蒙皮部件换装，批量绘制，物件绑定插槽编辑，动作标签编辑，动作融合设置，等等...一个复杂的蒙皮配置系统了，应该会比OGRE那套复杂的多

已经搞定了，还真是不容易，抛弃矩阵，那玩意根本就不能直接拿来做线性插值，因为旋转的产生是有弧度的，直接这个矩阵来做差值一定会结果变成直线位移而严重失真，应该用每个骨骼原点自身的四元素旋转和自身位移和骨骼的世界原点这三个数据来做，回头我会写一篇具体实现方法的文章，现在任意时间的任意顶点的位置经过我的关键帧插值计算，已经和3dmax完全能对应上无误差了

今天看了一下max的api，关键帧运动插值计算有TCB， BEZIER，和LINEAR三种方式，还要根据IKeyControl来获取旋转、平移、和缩放的x,y,z三个分量的关键帧控制器，可以说相当于有9组控制器，通过这些控制器来得到运动轨迹曲线上标注的关键帧，三种插值得到的运动轨迹的变化是不一样的，前两个是曲线，最后一个是直线，这里面基本意思是看明白了，我决定把这通过IKeyControl得到的关键帧，和前面提到的帧压缩算法结合起来再来试验一下效果，但不打算使用TCB和BEZIER两种计算方法，这两种差值算法还要折腾曲线方程，过于复杂了，还是打算使用LINEAR线性差值的方式，我想缺点就是动作也许会没那么平滑吧，就好像行车转弯的时候按直线转和按弧线转，肯定是弧线自然一些，但代价似乎也不小吧，主要是计算插值的曲线方程不太容易搞

设定好阀值是不会出现裂缝的，我现在引擎正在用dx10重构，地形这部分我现在重新整理，已经有了很好的提升方法，我目前在考虑9宫之外的tile整体lod输出，9宫格内的按block lod 输出，9宫之外的tile加载的数据非常少，可视距离可以扩展2到三围tile的范围，这样能够花较少的代价看到更多更远的地形细节，也就是看的更远，这部分提升空间蛮大的。

我的窗口向来都设置这个颜色，比较清凉养眼

6个月太短了，我搞了三年半了，完全靠自学进步同样缓慢，很多地方也还很欠缺，就是有计划的去修炼提高，欲速则不达

就是个细致活，多画画图，找找规律，自然就能发现其中的拓扑结构了，就是用程序生成索引，然后缓存索引，别无它法，完全避免重复无谓的lock,unlock

当然是用程序来生成索引了，我现在已经改用17x17的规格了,33x33有点大了

这个很容易的，只要做好地形编辑器，让地形刷子能精确控制边界的贴图过渡的问题,刚好这部分最近正好在重构，混合部分我打算采用改进的“非线性”混合，能大大提高混合精度，待重构完成，其具体做法，我不久之后会发布到博客上，敬请留意

其实看看那些艺术照和生活照的区别，就是晕光蒙蒙的效果，对比也显得强烈，看少了还不错，看多了，就不爽了，感觉不真实

有的人会说，如果不是艺术照下的MM都很迷人就是极品了。
扯的有点远了 : )

不会啊，我用着没问题，很久没搞过newton了，早改physx了
不过physx的例子也用的GL，跟渲染引擎没关系，你只要关心物理方面的结构就行了，看东最开始的例子，然后凭理解在dx里面写，都差不多

MFC都用习惯了，是陈旧了点，不知道为什么没有后续支持来升级UI库，可能这就是真正挨骂的原因吧，
WxWidget 好像也是很庞大的哦，里面的例子很多，确实很吸引人

这片文章很老了，但确实是好文章，过去就是看了该文来写A*的。

同意2楼，共享资源传统的方式最好使用共享锁和排他锁，分而治之，可以参考读写锁的实现方法win32下单进程内建议使用用户模式，interlock系列函数足以

锁无关数据结构我还没找到很好的解决方案

全部是网上找的资料，GEM系列书上有介绍过，资料很零碎，具体上面的状态机封装形式还要结合脚本引擎，才能真正发挥它的威力，我已经这么做了，总之，就是一句话：很好很强大 o(∩_∩)o...

我用的是directx，模型采用自己的格式用的是shader和固定管线两个版本都支持

囧...

我明白，如果是vector<Entity*>的方式，根本不用去讨论该去用vector还是queue，重排就重排了，指针不会变
但如果是vector<Entity> 的形式情况就不同了

这样的类别的集合确实就不该直接去引用集合中元素的地址，这不是一个好的习惯。

主要是：我的序列化存储层只能支持 集合<entity>的形式
不支持 集合<Entity*>的形式，想引用从文件读取的集合数据又不想做太多的拷贝，迫于无赖。

只好回头再想想看有没有更好的折中方案了。

后面的部分是我摘录网上的文章，觉得好像也没什么不妥
当然了如果元素被移除了，这样去访问那会是危险的。

我试了试，似乎erase中间的元素以后，各元素的地址依然稳定，vc自带的的deque 是这样的，不知道其他版本的deque会不会也是这样？

我已经深深的爱上deque了 ^^

我现在讨论的不是迭代，任何集合都能迭代，光用一个iterator去遍历，任何集合都没有差别了。那一个vector就够了还要list和deque做什么？

我现在讨论的是它们的内部结构的差别，根据不同的场景而要用出这些集合的差别才是真道理，楼上看清楚，我现在就是想在外部指针去引用集合内部的元素，就是不想每次访问的时候都去迭代，集合如果只增不减的情况下，用deque是稳定的,而vector是不稳定的，vector存在空间重排，deque不存在空间重排，这是我要阐述的观点

那DLL里面的版本号呢？功能模块的DLL都是编译器生成的，你要在每个DLL里面再附加资源信息吗？我觉得有点繁琐了。何况如果每个文件都去解析里面的版本号的数据，速度是会很慢的，不仅繁琐，而且更难控制。
不过一些版本控制软件的却是加了版本号的，但也是有版本索引文件去记录这些版本，但绝对没有要求一定要在源文件中去加版本号。所以时间要素控制版本是高效便宜的做法

我是在
http://www.codeproject.com/
好久以前的找的，别人对MFC扩展的控件，

/2/3 /
/1/ ?/

?号的部分的级别显然应该是2，观测点因该在1点半的方位，前面叙述过，而且实践检验过，通过设定好的阀值，相邻的block级别不可能相差超过1的

各种级别和边的补缝形态索引的确是要计算的，但用过了不要浪费，我定义了一个cache，四条边的补缝形态以及除了四条边以外中间的形态都放入了缓存，缓存找不到的时候就计算，然后加入缓存，最终缓存能把所有形态填充到缓存，就不再需要计算lod形态了，我采用的就是这样的算法，能很有效的避免lock unlock，另外这点内存上的开销在空间上几乎是一次性的开销，其实非常的小，不必在意的。

lod影响的因素如果考虑起伏分布，的确是个高级话题，暂且还没考虑这些要求，但如果做个地理信息系统的时候，确实就很有必要了。

过年回家上次网不容易
lod级别我用的是最简单的 观测点到block中心距离×阀值(一个小数) 来确定的，相当于运用一个策略钳制一个LOD当量在可用级别范围内，传统的方式都是这样做的，当然要做的更复杂，不能光靠距离来决定lod级别，比如起伏大的地形用高的级别，平坦的地域用低的级别，这可以说是另一个高级话题了

这帖子快一年了，回头看看，还真是感触颇多啊
后来我还是自己写了一套序列化的库，完全支持stl + zlib字节压缩的的序列化库，最终还是没有采用结构体的方式

自己写的这套库工作了很久了，也是我的IO和网络流的底层，用起来还是很方便的，足够了

3dMax里面一组面可以成为一个mesh，每个房间的面是一组mesh，是手工拆分好的，没有按照自动拆分portal的方式来做，那样太变态了，还是手工来的准确和灵活

偶现在用physx了，很久没用过newton了，physx那里面的矩阵和dx的到是不一样

跟VS里面的停靠窗口一样的效果啊,悬浮状态调整大小不影响渲染窗口大小,铆钉铆上以后调整大小影响全屏的渲染窗口大小

我的无限大是指：想要多大就多大，也就是说无论多大就可以。

我已经实现了从一头走到另一头走1天也走不到头的地形，无论多大运行速度都不受影响，场景所有数据全部实时动态加载和释放，而且已经研发了配套的地图编辑器，全部采用可视化编辑的支持

目前地形编辑器已经很好的支持室外场景编辑
室内场景也整合到了地形上，正在完善

所有的已经全部按计划实现了，目前在做符合游戏引擎要求的进一步完善
比如AI所需要的数据设置等等一些东西，地貌的渲染部分是下一个阶段的目标

另外：我只搞3D

俺用模版库写了一个支持STL容器的Serializer ，内部可选择用zip压缩字节，以及加密解密字节，已经用了很久了，感觉很爽

每个tile是独立的blendmap，而且我用了两层，其实完全可以考虑只用一层，就混6张，每个通道0－127 一个图128-255一个图， 127的色阶基本也够用，以前见有人这么搞过，后来想想也没必要节约这点资源了。

这部分做了改进
http://www.cppblog.com/tonykee/archive/2008/10/25/64982.html
呵呵，已非昔比了

boost是很好，可有些庞大，目前并不打算使用
我已经加入了fastdelegate，这个短小精悍，足以解决我的问题了。

fastdelegate 还可以，去研究一把

做了一点点调整，这个应该就是了

不算太复杂，SDK里面很多文档和例子可以参考，我目前只简单弄了弄静态模型的导出，动画方面的模型导出还没做深入的研究，另外导出格式自定义的流格式，对串化需要做深入的研究，否则只有xml了

我还是使用了以前的方案，没有放在OnIdle里面
这个函数在优先级别太低了。

原先看了游戏精粹2介绍的就是这样的索引形势，没什么诡异的啊？

初识A*算法

f(n) = g(n) + h(n)

　　其中f(n)是节点n的估价函数，g(n)实在状态空间中从初始节点到n节点的实际代价，h(n)是从n到目标节点最佳路径的估计代价。在这里主要是h(n)体现了搜索的启发信息，因为g(n)是已知的。如果说详细点，g(n)代表了搜索的广度的优先趋势。但是当h(n)>>g(n)时，可以省略g(n),而提高效率。

主要是看了这段介绍

是啊，H做了判定，G没有考虑，需要改进一下评估函数

我现在决定选择luaplus和C++连接了，那样方便很多
否则全手工调用那些栈真的很烦

收下了，感谢你，邻居

刚下了physX，里面的布料效果很吸引人，没有物理显卡，跑的也还算流畅。
文档很齐全，看来是得认真考虑考虑了

给你看另外一个东西
http://www.cnbeta.com/articles/57171.htm

你觉得这个大家伙怎么样？够成熟吧

呵呵，这个我知道，只是觉得phyx太过商业化了，而且需要那个什么物理卡，真不知道没有那物理卡性能会怎么样？

GL现在已经不再是问题，我在试着用dx做第三个例子。
newton的物理引擎的api 函数真的很繁多，要想用好他们，不是那么容易的事情，还有一些物理知识也有些生疏，这样看来掌握好也不是一两天的事情了。

计划把sdk里面提供的12个例子全部看完先。

目前练习完前两个例子的感觉是，newton的封装很优雅，非常注意回调函数的使用，状态监听能够运用自如，大大增强了其灵活性，另外newton的文档也是比较规范的，每个案例都有配套的指南，是很好的教程

准备研究研究newton。

渲染方面学的不好，见笑了。