<?xml version="1.0" encoding="UTF-8"?>
  <feed xmlns="http://www.w3.org/2005/Atom">
  <title type="html"><![CDATA[诡辩生活]]></title>
  <subtitle type="html"><![CDATA[诡辩!=颠倒黑白，或者说思辨本身就不存在黑白]]></subtitle>
  <id>http://www.guibian.com/</id>
  <link rel="alternate" type="text/html" href="http://www.guibian.com/" /> 
  <link rel="self" type="application/atom+xml" href="http://www.guibian.com/atom.asp" /> 
  <generator uri="http://www.pjhome.net/" version="2.8">PJBlog3</generator> 
  <updated>2010-06-30T04:51:54+08:00</updated>

  <entry>
	  <title type="html"><![CDATA[Gamebryo系列材质详解：四（一个最简单的VS）]]></title>
	  <author>
		 <name>volfmath</name>
		 <uri>http://www.guibian.com/</uri>
		 <email>volfmath@gmail.com</email>
	  </author>
	  <category term="" scheme="http://www.guibian.com/default.asp?cateID=6" label="Tech" /> 
	  <updated>2010-06-30T04:51:54+08:00</updated>
	  <published>2010-06-30T04:51:54+08:00</published>
		  <summary type="html"><![CDATA[总结上第三课的内容。写一个shader。我用gamebryo生成的写法。对应的hlsl或者cg的大家自己去google<br/><br/>1.首先确定VS中的入参，以及出参，还有寄存器中的东西。<br/>讲下这里的内容：寄存中一般存储了世界矩阵，视矩阵，材质颜色，灯光等相关的环境信息。因为显卡寄存器的数量是有限的，而环境越多能做的变化也越多，所以这里要做一个权衡。到底需要什么样的效果，需要用到哪些寄存器都要事先估算好。<br/>入参的一般是顶点的位置坐标信息。这个显然不能卸载寄存器里，因为顶点数量太多了。有些特殊的做法，比方在做Instancing的时候我们有时候会把顶点的变换信息存储到寄存器里。这以后再讨论。<br/>先写一个简单的：（取自gamebryo自动生成的shader脚本）<br/><div class="UBBPanel codePanel"><div class="UBBTitle"><img src="http://www.guibian.com/images/code.gif" style="margin:0px 2px -3px 0px" alt="程序代码"/> 程序代码</div><div class="UBBContent"><br/>/*<br/>Shader description:<br/>TRANSFORM = 0<br/>OUTPUTWORLDPOS = 0<br/>OUTPUTWORLDNBT = 0<br/>OUTPUTWORLDVIEW = 0<br/>OUTPUTTANGENTVIEW = 0<br/>NORMAL = 0<br/>SPECULAR = 0<br/>FOGTYPE = 0<br/>ENVMAPTYPE = 0<br/>PROJLIGHTMAPCOUNT = 0<br/>PROJLIGHTMAPTYPES = 0<br/>PROJSHADOWMAPCOUNT = 0<br/>PROJSHADOWMAPTYPES = 0<br/>OUTPUTUVCOUNT = 1<br/>UVSET00 = 0<br/>UVSET00TEXOUTPUT = 0<br/>UVSET01 = 0<br/>UVSET01TEXOUTPUT = 0<br/>UVSET02 = 0<br/>UVSET02TEXOUTPUT = 0<br/>UVSET03 = 0<br/>UVSET03TEXOUTPUT = 0<br/>UVSET04 = 0<br/>UVSET04TEXOUTPUT = 0<br/>UVSET05 = 0<br/>UVSET05TEXOUTPUT = 0<br/>UVSET06 = 0<br/>UVSET06TEXOUTPUT = 0<br/>UVSET07 = 0<br/>UVSET07TEXOUTPUT = 0<br/>UVSET08 = 0<br/>UVSET08TEXOUTPUT = 0<br/>UVSET09 = 0<br/>UVSET09TEXOUTPUT = 0<br/>UVSET10 = 0<br/>UVSET10TEXOUTPUT = 0<br/>UVSET11 = 0<br/>UVSET11TEXOUTPUT = 0<br/>POINTLIGHTCOUNT = 0<br/>SPOTLIGHTCOUNT = 0<br/>DIRLIGHTCOUNT = 0<br/>VERTEXCOLORS = 0<br/>VERTEXLIGHTSONLY = 1<br/>AMBDIFFEMISSIVE = 0<br/>LIGHTINGMODE = 1<br/>APPLYMODE = 0<br/>*/<br/><br/>//----------------------------------------------------------<br/>// 常量寄存中中的变量(这里需要在引擎里每帧设置进去)<br/>//----------------------------------------------------------<br/><br/>float4x4 g_World;<br/>float4x4 g_ViewProj;<br/><br/>//----------------------------------------------------------<br/>// 入参:我们定义一个结构叫Input来确定入参结构<br/>//----------------------------------------------------------<br/><br/>struct Input<br/>{<br/>&nbsp;&nbsp;&nbsp;&nbsp;float3 Position : POSITION0;<br/>&nbsp;&nbsp;&nbsp;&nbsp;float2 UVSet0 : TEXCOORD0;<br/>};<br/><br/>//---------------------------------------------------------------------------<br/>// Output:<br/>//----------------------------------------------------------<br/><br/>struct Output<br/>{<br/>&nbsp;&nbsp;&nbsp;&nbsp;float4 PosProjected : POSITION0;<br/>&nbsp;&nbsp;&nbsp;&nbsp;float2 UVSet0 : TEXCOORD0;<br/>};<br/><br/>//----------------------------------------------------------<br/>// 函数:这里是用到的一些函数，简单的主要写了上次提到的几个函数。都是关于坐标系转换<br/>// 的，关于坐标系转换的更高级内容，请参阅我写的：番外篇<br/>//----------------------------------------------------------<br/><br/>/*<br/><br/>&nbsp;&nbsp;&nbsp;&nbsp;This fragment is responsible for applying the view projection transform<br/>&nbsp;&nbsp;&nbsp;&nbsp;to the input position. Additionally, this fragment applies the world <br/>&nbsp;&nbsp;&nbsp;&nbsp;transform to the input position. <br/>&nbsp;&nbsp;&nbsp;&nbsp;<br/>*/<br/><br/>void TransformPosition(float3 Position,<br/>&nbsp;&nbsp;&nbsp;&nbsp;float4x4 World,<br/>&nbsp;&nbsp;&nbsp;&nbsp;out float4 WorldPos)<br/>{<br/><br/>&nbsp;&nbsp;&nbsp;&nbsp;// 用于灯光啊，projected space的转换，转换到世界坐标系下。<br/>&nbsp;&nbsp;&nbsp;&nbsp;WorldPos = mul( float4(Position, 1.0f), World );<br/> <br/>}<br/>//----------------------------------------------------------<br/>/*<br/><br/>&nbsp;&nbsp;&nbsp;&nbsp;This fragment is responsible for applying the view projection transform<br/>&nbsp;&nbsp;&nbsp;&nbsp;to the input world position.<br/>&nbsp;&nbsp;&nbsp;&nbsp;<br/>*/<br/><br/>void ProjectPositionWorldToProj(float4 WorldPosition,<br/>&nbsp;&nbsp;&nbsp;&nbsp;float4x4 ViewProjection,<br/>&nbsp;&nbsp;&nbsp;&nbsp;out float4 ProjPos)<br/>{<br/><br/>&nbsp;&nbsp;&nbsp;&nbsp;ProjPos = mul(WorldPosition, ViewProjection);<br/>&nbsp;&nbsp;&nbsp;&nbsp;<br/>}<br/>//----------------------------------------------------------<br/>//----------------------------------------------------------<br/>// Main():这是VS的主函数，从这里入参被处理好了以后交给像素处理管线去处理<br/>//----------------------------------------------------------<br/><br/>Output Main(Input In)<br/>{<br/>&nbsp;&nbsp;&nbsp;&nbsp;Output Out;<br/>// Function call #0&nbsp;&nbsp;把局部坐标转化为世界坐标<br/>&nbsp;&nbsp;&nbsp;&nbsp;float4 WorldPos_CallOut0;<br/>&nbsp;&nbsp;&nbsp;&nbsp;TransformPosition(In.Position, g_World, WorldPos_CallOut0);<br/><br/>// Function call #1&nbsp;&nbsp;把世界坐标转换为视坐标<br/>&nbsp;&nbsp;&nbsp;&nbsp;ProjectPositionWorldToProj(WorldPos_CallOut0, g_ViewProj, Out.PosProjected);<br/><br/>&nbsp;&nbsp;&nbsp;&nbsp;// 这里是UV信息，不做任何处理，用于像素着色器<br/>&nbsp;&nbsp;&nbsp;&nbsp;Out.UVSet0 = In.UVSet0;<br/>&nbsp;&nbsp;&nbsp;&nbsp;return Out;<br/>}<br/>///////////////////////////////////////////////////////////////////////////////////////////<br/></div></div><br/>这个是最简单的gamebryo vertex shader。<br/>总结一下，最后被我们忽视的两个东西，也是在我看来最重要的东西。1个是Shader description，全是大写字母的描述。有些是=0，有些是=1.<br/>实际上这就是最早说的这个VS里预定义的特性。由于这个vs非常简单，所以大部分都是0。现在不理解也不要紧，以后会继续讲到。<br/>再一个就是main函数。Main函数里的两个注视很有意思一个是Function call #0。Function call #1，其实就这就是生成好shader tree以后<br/>顺着tree向下走的过程。 下一张将进入一个精彩的部分。gamebryo光照方程。<br/><br/>]]></summary>
	  <link rel="alternate" type="text/html" href="http://www.guibian.com/article.asp?id=105" /> 
	  <id>http://www.guibian.com/default.asp?id=105</id>
  </entry>	
		
  <entry>
	  <title type="html"><![CDATA[番外篇For：Gamebryo材质系统]]></title>
	  <author>
		 <name>volfmath</name>
		 <uri>http://www.guibian.com/</uri>
		 <email>volfmath@gmail.com</email>
	  </author>
	  <category term="" scheme="http://www.guibian.com/default.asp?cateID=12" label="Math" /> 
	  <updated>2010-05-30T21:36:19+08:00</updated>
	  <published>2010-05-30T21:36:19+08:00</published>
		  <summary type="html"><![CDATA[虽然叫For Gamebryo材质系统，但其实跟他一点关系都没有。番外篇讲点多年来总结的数学知识，很多都是自己的YY。欢迎拍砖。本篇会长期更新。不过为了跟材质系统相关，我会先讲射影几何学，微分几何，线性代数的一点浅见。<br/><br/>1.坐标变换&amp;仿射空间<br/>本人不是科班出身，属于半道出家。计算机图形学小读过几本，幸好有个怪癖喜欢数学。今天才得以让那些深奥难懂的计算机只是重见天日。<br/>其实本质的东西都是很浅显的，但是日子久了形成了一门学问。装逼犯就多了。他们开始喜欢用术语欺骗人。特别是中国大多数教授，本事没学多少，术语倒是一箩筐。所以建议翻译的书少看为好，或者拿来一本一看很多不懂的术语，那通常是烂书。数学上有个operator，翻译到中文叫“算子”。我愣是学了两年才明白这个词的意思。害人不浅啊。计算机也没好哪里去。长度都能说成“欧几里德范数”。我无语。<br/><br/>我大学时候读过2，3本计算机图形学书，一本是本科生教材，一本是3D游戏中的数学，还有本大部头的3D图形学卷1，好象是。每次以讲到变换都要说，我们把变换矩阵加一行，加一列就可以做变换了。<br/><br/>这对刚刚学过线性代数的人很不能理解。我们通常觉得，一个3维矩阵就表示了3维空间。其实这个概念也是稀里糊涂的。好，就这样认为吧。那么为什么在3维空间里坐标换要用到一个4×4的矩阵啊。不奇怪么？]]></summary>
	  <link rel="alternate" type="text/html" href="http://www.guibian.com/article.asp?id=101" /> 
	  <id>http://www.guibian.com/default.asp?id=101</id>
  </entry>	
		
  <entry>
	  <title type="html"><![CDATA[双面维罗尼卡：深度解析豆瓣成功的秘诀]]></title>
	  <author>
		 <name>volfmath</name>
		 <uri>http://www.guibian.com/</uri>
		 <email>volfmath@gmail.com</email>
	  </author>
	  <category term="" scheme="http://www.guibian.com/default.asp?cateID=5" label="My Life" /> 
	  <updated>2010-05-27T23:59:48+08:00</updated>
	  <published>2010-05-27T23:59:48+08:00</published>
		  <summary type="html"><![CDATA[豆瓣从一上线开始就不走寻常路。慢慢开始构建阿北心中的社区模型，就像乔布斯之于苹果迷一样，我觉得阿北之于豆瓣迷，他就是所有粉丝的教主。<br/><br/>不管你想怎么否认，你的心里总会有一个时刻觉得豆瓣的用户群在中国网民中素质强于其他SNS社区，好过开心网不用多说，秒杀人人网。这个艾瑞的数据也许比我说的更加明白。在一个没有偷菜没有买人抢车位的社区，注册人数和在线人数一次次被刷新不能不说是个奇迹。<br/><br/>人人网抄了facebook的社区模式，开心网抄了插件体系。但都开始陷入瓶颈。人人网的几个动作都2到家了。收购开心域名和改校内为人人。两个目的很明显，用开心的域名来抢流量，用人人域名来做横向扩张。但是我们发现都是失败的。开心网还是那些白领阶层的同事。校内网依然是同学。反观豆瓣，从来都没有高调入市，才豆瓣呢，豆苗都没出来。但是你看看豆瓣用户群恰恰涵盖所有的范围。我的好友里有同事，有同学，有朋友，更多的是不认识的人，他们来自各行各业，有全国各大高校高材生，全球各大公司高级人员，也有厌学的孩子，下岗待业的，自由职业者，摇滚明星甚至钢琴老师。而这些都是因为我们＂臭味相投＂。<br/><br/>我后来发现阿北是工作经历是IBM的科学家，看，阿北是抽象思维，其他两个陈一舟和程炳皓都是具象思维。想想看SNS的精髓是什么啊？什么推动了历史的车轮在前行，互联网为什么这么热闹？交流啊。<br/><br/>什么是交流的出发点啊？兴趣啊。一首歌，一部电影，一本书。这才是社区的抽象接口，用我们程序的思维来说就是找到了合理的隐喻。我为什么不想去人人？因为我根本不关心同学在干吗，开心也是，我也根本不关心我的同事在干吗。换句话说，稀奇古怪的原因使我们在一起学习或者工作了一段时间，或许我们曾经是十年修的同窗度，我们曾经互相帮助，但一旦远了，朋友的友情也就淡了。人人网天天提醒我们，你很久没跟你的同学打招呼了，我也懒的去点，因为什么？我们没什么好交流的，彼此知道曾经是朋友，或许以后哪天能见面，再困难的时候帮助下对方而已。到目前为止我的人人网只有同学，开心网只有同事。<br/><br/>而我关心的那些东西，我每天的兴趣点都是我迫切想了解的。我每天都想看看我感兴趣的东西的动向，或者寻找新的兴趣点。最紧密的关系是遥遥相望的两个人，彼此知道对方的存在，而甚至没见过面。有可能是两个社会上的成功人士，武林高手，他们谈论着他们感兴趣的话题，投资，创业。也有可能是两个只喜欢拣便宜的学生，他们谈论着哪儿可以买到经济实惠好看的衣服。他们可以为此说上一天。豆瓣中的两个人，就想双面维罗尼卡，他笑他也笑他哭他也哭他痛他也痛。你可能永远不知道对方是谁，但是你能感知到远方有一个人，你们是如此的想像<br/><br/>这才是交流的本质，从2006年刚内测开始，我就慢慢觉得豆瓣不需要声张，豆瓣不需要宣传，他自然的就会成真那个为我们最需要的平台，只有在这里，关系才被更本质暴露出来，是不要任何人为的强加因素的。]]></summary>
	  <link rel="alternate" type="text/html" href="http://www.guibian.com/article.asp?id=104" /> 
	  <id>http://www.guibian.com/default.asp?id=104</id>
  </entry>	
		
  <entry>
	  <title type="html"><![CDATA[我是谁？哪些方式可以找到我]]></title>
	  <author>
		 <name>volfmath</name>
		 <uri>http://www.guibian.com/</uri>
		 <email>volfmath@gmail.com</email>
	  </author>
	  <category term="" scheme="http://www.guibian.com/default.asp?cateID=5" label="My Life" /> 
	  <updated>2010-05-23T22:23:23+08:00</updated>
	  <published>2010-05-23T22:23:23+08:00</published>
		  <summary type="html"><![CDATA[由于twitter,flickr甚至buzz都被封锁。所以好多好的东西都不能用，虽然翻墙已经不是今天很陌生的话题了，但是总是对交流带来的不便。在twiiter上我基本只会fellow别人，自己不会写东西。flickr也只是浏览。<br/><br/>目前我最主要的即时通信工具还是QQ，虽然在挨踢界装丫挺的世界里，总是觉得用msn的用户群更加像B一点，我还是不入他们的流。QQ对我目前的工作学习生活来说非常方便。<br/><br/>QQ群我是不经常用的，我到目前也没看到哪个QQ群里在聊技术。倒是自己建了一个群，是一个有共同爱好的朋友在一起聊技术，不过群大部分时间都是静默的，因为技术的交流并不象口水那样总是平凡的。群的分享很喜欢，我们会交流下自己的读书目录。这还是不错的。<br/><br/>我其实是希望交流是能整合的，所以大部分的工作在google上已经完成了。google reader是我用来看别人文章的地方那个，google doc用来记下小想法，是没有分享的，因为他能与我的iphone同步，所以很多时候我在地铁上有好的想法都会记下来。另外书签也可以同步，后来就很少用delicious了。google分析是用来看我的blog的流量的，没什么用只是为了爽，gmail用来收邮件。算是个我比较商业的邮箱了吧。<br/><br/><span style="color:red">公布下邮箱：volfmath@gmail.com</span><br/><br/>QQ上的朋友比较杂，不过基本不加不认识的，除非特殊情况。所以就算公布出来也没什么意义.<br/><span style="color:red">QQ号：93696372</span><br/>下面是几个常去的地方：<br/>豆瓣网：<a href="http://www.douban.com/people/guibian" target="_blank" rel="external">http://www.douban.com/people/guibian</a><br/>豆瓣改了友邻的方式我基本不知道怎么玩了，有共同兴趣的就加吧。豆瓣也是我倾注时间最多的地方，所有的blog的文章都会在9点上同步，想看的朋友可以群订阅。上面有个书单，是我读过的书。<br/><br/>腾讯围脖：<a href="http://t.qq.com/volfmath" target="_blank" rel="external">http://t.qq.com/volfmath</a><br/>上面有我的数目，我工作时的一些记录和随想。如果QQ能做好我已经就不打算换了。可以去fellow我，另外我还有5个邀请，想要的可以找我。<br/><br/>人人网：<a href="http://www.renren.com/profile.do?id=1681306539" target="_blank" rel="external">http://www.renren.com/profile.do?id=1681306539</a>&amp;_os_type=30<br/>都是我学习过程中的同学，所以不是同学加了也没意思<br/><br/>开心网：<a href="http://www.kaixin001.com/home/?uid=25132068" target="_blank" rel="external">http://www.kaixin001.com/home/?uid=25132068</a>&amp;t=78<br/>全是同事，其他人不加<br/><br/>我是谁？<br/>行不改名，坐不改姓：真人名王骏，非网名呃。<br/>职业：国内某知名游戏公司项目经理+主程序(至少我觉得我现在在被当两个人用)<br/>工作内容：<br/>1 帮助项目制定版本内容，与用户交流，架设CI，教大家使用SVN和HG。教大家TDD。<br/>2 解决游戏中架构问题，核心技术。我寒死。<br/><br/>我的工作信条：没有TDD，没有CI，不敏捷，迷信人月的公司要么反省，要们乘早关门。XP的世界里没有经过的测试的代码不允许提交svn。摒弃瀑布式。<br/><br/>未来期望：不想再去另外一家游戏公司了，要么在目前这家公司终老，要么等他完。麻烦所有猎头公司不要再给我电话了，目前还没有看的入眼的国内游戏公司。<br/>如果换工作，给几个期望地点把，中科院计算所，北大数学院，微软亚洲研究院，谷歌。有内线的朋友联系我啊~~~ 哈哈<br/><br/>研究方向+自我评价：<br/>数学类：精通基础课：分析，代数，复变，实变，泛函，拓扑，微分几何，目标的研究方向是代数几何。虽然只懂一点点。<br/>图形学：精通图形学算法，手写，岂止手写，可以闭着眼睛写Shader。精通数学，物理算法，可YY出很多图形学算法，并经常在sg的论文里不可自拔。深刻了解图形学的核心架构，对放射几何学有很深入的研究。<br/>语言类：精通c++，难道只是精通？简直变态。语言类书籍读了不下20本，从primer，还有老爹的TPLC开始，读过无数本E打头的，ME打头的书。对标准委员会的那些八卦家伙了如指掌。哈哈。也读过讲stl,boost库的数多本，读过loki，元编程，曾经对模板无比热爱。了解对象模型和C++起源。其他大小语言懂个10个8个，什么asp,php都不再话下，HTML/CSS也搞搞，很久不跟标准了估计现在已经落后了。java,C#,Object C略通一，二。熟悉各种编程范式，面向过程，面向对象，函数式，元编程等等。并能用很口水的表达出来。<br/>开发环境：擅长在win下，废话哈哈。用过linux开发，在苹果上玩过ip开发，如果这也算unix也算有点经验了把。IDE随意，反正Mikefile也写的来。<br/>另外设计模式倒背如流，信手拈来。深刻理解人月神话与人件，懂得以人为本的开发。极力推崇敏捷建模，快速迭代，结对编程，测试驱动开发，持续继承等等等等。我觉得这应该是每个公司的基础标准，而不应该是奢侈品，相信没有银弹，现在不会将来也不会。大部头的啃过不少，代码大全，**之美系列，软件调试等等等等<br/><br/>自我介绍：热爱读书，所有好奇的方向，有挑战的读物都愿意尝试。喜欢思考，多年沉迷与数学的结果，让我喜欢给事物抽象出本质以及找类比。这在博客里有体现。目前热衷于建立软件工程的流程，虽然力量很微薄，但想做好。<br/><br/>工作年限：<br/>3年 = 国企程序员工作30年 = 私企普通程序员工作10年 = 私企高级程序员工作5年 = 公务员工作∞年<br/>睡觉时间：每天加上在地铁上的不超过6个小时。其他都在读书工作和思考<br/><br/>业余爱好：旅游，摄影，钢琴，吉他，听歌。<br/>设备：canon系 450D， 50.18II 24-105/4L <br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; casio PX120破电钢一台&nbsp;&nbsp;&nbsp;&nbsp;鸟琴一把<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 台版海外版CD无数。 T61P一个工作用，macbook小白上网+白象，nono,classic便携听歌<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sony D-ne20用来放CD。&nbsp;&nbsp;iphone伴随我好久啊。无数功能，打电话，上网，帮老婆偷菜等。<br/>]]></summary>
	  <link rel="alternate" type="text/html" href="http://www.guibian.com/article.asp?id=103" /> 
	  <id>http://www.guibian.com/default.asp?id=103</id>
  </entry>	
		
  <entry>
	  <title type="html"><![CDATA[Ogre 1.7版本重大改进]]></title>
	  <author>
		 <name>volfmath</name>
		 <uri>http://www.guibian.com/</uri>
		 <email>volfmath@gmail.com</email>
	  </author>
	  <category term="" scheme="http://www.guibian.com/default.asp?cateID=6" label="Tech" /> 
	  <updated>2010-05-12T17:46:52+08:00</updated>
	  <published>2010-05-12T17:46:52+08:00</published>
		  <summary type="html"><![CDATA[Ogre新的版本在年后首次发布了。1.7较之以往的版本有了长足的进步。<br/>由于跟SOC的互动，Ogre 1.7开始慢慢渗透了更多只有商业引擎才有的功能。这得益于最初优良的框架。<br/><br/>下面一个一个道来。<br/><br/>1.改了个名字，似乎是另外一个怪兽。：） 协议改变，现在是MIT了，总之就是更自由了。<br/>2.Sample Browser的引入，社区里有篇写的很详细的文章。很多商业引擎都有，个人觉得实行用其实一般，属于引擎的噱头。以后只需要进行一次资源重建就可以切换包括渲染系统等等东西，不用重新运行可执行文件。<br/>3.使用CMake来构建，好处就不说了，社区里也有帖子很详细。<br/>重点来了啊~~<br/>一.地形系统重大改进。<br/>1. 地形管理从场景管理中独立出来，成为一个可选组建<br/>2. 内置了可编辑功能 (不过功能还不强大哈)<br/>3. 使用了批量渲染。当顶点数量随着LOD递减时，渲染的批次也会递减。最低的Lod渲染批次的数量为1<br/>4. Lod可以实时的与Camera设置进行适配。因此可以方便在不同的视角中使用同样的地形<br/>5. Skirts技术替代了早期的缝合技术来出来地形的裂缝。<br/><br/>这里解释下。Skirts不知道国内通用的翻译是什么。直接翻译成“裙子”也行。大片地形渲染中，不同的Lod层次的地块由于有不共用的顶点所以一定会造成裂缝（Cracks）。老的解决办法就是缝合，通过削减高级别Lod地块的边缘顶点数或者增加低级别地块的边缘顶点数来做过渡。这样的缺点是，无论哪种方法都要重新遍历整块地形然后重新进行三角形剖分。对地形的分页和缓存带来很大的麻烦。<br/>Skirts的做法，则是对每个分块的四条边，在现有的顶点的基础上再延伸出一圈，并且与单个分块的边界共享顶点，而高度值不同，这种延伸出来的一圈叫做“裙子”（Skirts）。蛮形象的把，呵呵。只要保证顶点的高度值足够大，两个分块的裙子可以把裂缝遮挡住。<br/>这种消除裂缝的方式唯一缺点是会增加绘制的三角形数量，但是对于现在的图形处理器来讲，这种三角形数量的额外增加不会带来性能上的下降。<br/><br/>6. 内建了地形的保存和加载，并且是在后台线程里完成的<br/>7. 支持多层材质融合，可配置的采样输入，以及可插件化的材质。<br/>8. 支持生成全局Normal maps和light maps.同样也是在后台线程完成的。<br/><br/><br/>二.Compositor的重大改进<br/>这也是去年实际做项目中遇到的最麻烦的问题。由于不能共享，导致过渡的耗费，让我们不得不放弃了某些后期的效果。现在终于解决了。就是通过了一个叫‘pooled’的东西。<br/><br/>1. 当不同的合成器实例使用一个相同大小和格式的表面时可以被共享,这样可以节省内存。<br/>就是说rendertarget如果设的一样的话，就可以被用来用去了。<br/><br/>2. 系统会帮你侦测这个合成器实例链以避免相互依赖。<br/><br/>3. &#34;pooled&#34;需要在定义纹理时显式被激活。注意下，这个激活不是默认的。因为一旦它被激活，你就没法完全看到那些作为中间过程的纹理了。（因为他们可以通过共享的方式互相传递（ping-ponging），或者叫反射吧）；但是如果用户又恰好需要，所以就设置了默认不激活。<br/><br/>其实很好理解，就是说如果&#34;pooled&#34;被激活，那么那些被用来ping-ponging的纹理就得不到了，因为不作为最终结果的图不会被保存，那个被共享的rendertarget会被反复擦写。所以说，你如果到最后又想用那些图，就不能激活&#34;pooled&#34;也就是说，使用默认了就可以了。<br/><br/>4. 另外一个就是可以在运行时，交换两个Compositor。Technique现在都有一个自己的名字&#34;scheme&#34;。交换的时候只要通过名字来所以就可以了。不用麻烦的再去用大量的宏定义去判断什么的，以前做法是判断硬件是否支持啊，或者自定义几种表现方式啊。现在都不用了。因为那样看起来会很乱。<br/><br/>5. 现在也可以保存和共享一个用过的纹理，保证向前向后交换都变得更快。<br/>另外还有一些细节修改：<br/>a.不想继承FSAA的，需要设置下&#39;no_fsaa&#39;。<br/>b.支持逐纹理sRGB gamma校正。<br/>c.跨Compositor的通信。<br/>i.使用chain_scope 或 global_scope 直接可以定义纹理来自于其他的地方。<br/>ii.使用texture_ref，可以直接从其他Compositor或公共部分引用一个纹理。<br/>d.Compositor代码之间连接被改进了<br/>i.可以自定义一个合成器pass。不仅仅是quad/scene/clear啦。要用render_custom来激活这个自定义的类型。<br/>ii.可以自动使用CompositorLogics，来使compositor和相关的代码连接（例如使用一个compositor监听者）<br/><br/>PS:compositor这种东西在其他引擎中还很少见到，原因是涉及的东西太复杂，不好抽象，如果限制太多，后期做起来就很困难。Ogre算是一个尝试把，不是实际用起来还是有不少地方不太方便使用。等大牛们慢慢重构把，希望以后对后期制作方面的设计是个帮助。<br/><br/><br/><br/>三：增加了几个很牛X的组件<br/>1.RTSS组件。<br/><br/>这个太强了，以前材质脚本都需要一个懂美术&amp;懂技术的人员来搞定。现在不用了，在画面上点点UI，保存下，就完成了一个Shader文件。并且里面支持per-pixel lighting, normal mapping and shadows等更多内容。<br/>已经有点gamebryo的意思了。GB里做的只是把这个生成Shader的方式跟Max结合到了一起。而作为Ogre我也觉得应该有自己的一套pipeline，并且集成好用的工具提供给游戏开发人员。现在看到个雏形，挺高兴。<br/>实现过程其实还是蛮复杂的，特别是构建一个ShaderTree系统，具体的关于Gamebryo的实现，做个广告，<a href="http://www.guibian.com" target="_blank" rel="external">http://www.guibian.com</a>。可以去我Blog看罗。<br/>另外，我觉得这还不够帅，按照这样发展下去，SOC2010应该能作出类似UE3的东西，就是拖拖拉拉出Shader。至少我觉得在Ogre现有框架下实现并不复杂。<br/><br/>2.分页组建。<br/>新的分页组件从场景管理器中独立开，分拆成为几个不同的可选组件。<br/>插件化的策略组件来控制场景中的分页。插件化的内容组件来控制分页的内容。<br/>插件化的集合组件用来组合不同的分页(比如 在一个页中分出多个LOD级别)<br/><br/>四：支持Iphone<br/>估计地球人都知道了，自己去看代码把。很多Objective C的东西，看起来很亲切把。：） 我的Ip已经能跑起来了。就是速度还有待提升。另外别忘了先预解析一下材质脚本，不然解析Shader很费电。 - -||<br/><br/><br/>五：几个不加解释的翻译<br/>1. 场景管理器的修改，可以中途暂停一帧的渲染（比如通过在一个过程中使用回调函数），暂停后可以触发另一个渲染，最后在恢复。这是之前在商业引擎中看到的。而且是个很有用的功能。<br/>2.添加了一个选项可以手动触发阴影图的更新，比方在有特殊光照的时候。<br/>两个方法结合起来很有用。当有多重shadowmap的时候，纹理就可以被重用了。<br/>其实还是Compositor里的东西，另外跟DS有关。<br/><br/>抗锯齿的改变<br/>1.支持CSAA，dx9和10中可以使用。<br/>2.简化了并标准化了AA的设置。<br/>在Root的config选项里。所有情况下都加FSAA，组合上一个采用方式和一个提示字符串。通过空格分隔。<br/>在cr&#101;ateRenderWindow的miscParams参数上你可以提供 &#34;FSAA&#34; 和 &#34;FSAAHint&#34;参数,前面是这个采样的倍数，后面是一些提示(例如质量)<br/>PS：怎么跟gamebryo越来越像，怀疑google code这些家伙是GB的倒戈。<br/><br/>光照的改变<br/>1.阴影摄像机的远近裁减面设置支持每盏灯光。<br/>2.可以通过调用MovableObject::setLightMask来设置渲染物体mask光照,一个可渲染物体的掩码与灯光掩码按位求与，如果是0，灯光就被排除。<br/><br/>LOD的改变<br/>LOD不再使用距离作为度量来区分了。<br/>LOD策略现在在材质和网格上都能被设置，或者按照距离，或者按照像素数。当然也可以很方便的添加新的策略。<br/>STL容器<br/>所有的STL 容器现在使用自定义的内存分派。<br/><br/>优化<br/>固定管线的光照状态更加智能化，为了处理物体数量巨大的时能发挥更好的性能。<br/>着色器参数更新现在更加有选择性了，减少不必要的更新。<br/><br/>GpuProgramParameters改变<br/>多个cg程序或者材质基本中需要共享的参数可以在一个地方定义和更新。代码看这里：GpuProgramManager::cr&#101;ateSharedParamerers<br/>当Gpu程序的基类被改变或者重加载以后，参数会自动被移植。改变后任然可以使用的参数将合并到新的参数中去。<br/><br/>文件系统的改变<br/>支持创建和移除文件（仅在FileSystem中有效）<br/><br/>DataStream的改变<br/>可写数据流也支持了（同样仅在FileSystem中有效）<br/><br/>加了一个新的类StreamSerialiser，是读写二进制数据格式的新方法。<br/><br/>PS：看到Ogre开始也要用流格式来管理数据了<br/><br/>RenderWindow的改变<br/>可以自定义v-sync的刷新频率。并且硬件也要支持。<br/><br/>视口的改变<br/>增加了一个clear方法来手动清除任何 颜色/深度/模板的组合，这个指定值不执行更新操作。<br/><br/>图片的改变<br/>增加了 loadTwoImagesAsRGBA 和 combineTwoImagesAsRGBA 这两个方法，使用它可以更容易的构造 法线/高度图 和 漫反射/高光图等组合<br/><br/>线程也做了修改，大家自己去看把。<br/><br/><br/>总结下，这次新版本作出的改变。感谢SOC的那帮牛人，Ogre越来越向着一个易用的引擎靠拢。开始借鉴很多商业引擎不错的地方。开始慢慢解决在实际项目中遇到的问题。而他优良的扩展性被体现的很明显。最初项目开发的时候，我们发现Ogre其实有很多&#34;bug&#34;，之所以有个引号，是因为那不叫真正的Bug，由于Ogre在游戏项目中不太经常的出场率，造成很多引擎设计上没有考虑到的问题，不过我发现这个版本很多的新功能都弥补了那些缺陷。这些可喜的结果我相信在SOC2010后还会有个飞跃~<br/><br/><br/><span style="color:red">本文只发表在此处与<a href="http://class.gd" target="_blank" rel="external">http://class.gd</a>&nbsp;&nbsp;&nbsp;&nbsp;因此如果转载请著名出处</span><br/>]]></summary>
	  <link rel="alternate" type="text/html" href="http://www.guibian.com/article.asp?id=100" /> 
	  <id>http://www.guibian.com/default.asp?id=100</id>
  </entry>	
		
  <entry>
	  <title type="html"><![CDATA[Gamebryo系列材质详解：三]]></title>
	  <author>
		 <name>volfmath</name>
		 <uri>http://www.guibian.com/</uri>
		 <email>volfmath@gmail.com</email>
	  </author>
	  <category term="" scheme="http://www.guibian.com/default.asp?cateID=6" label="Tech" /> 
	  <updated>2010-05-12T00:34:14+08:00</updated>
	  <published>2010-05-12T00:34:14+08:00</published>
		  <summary type="html"><![CDATA[托了好久的一篇文章，上次写了一半丢了。只好重头写来。<br/><br/>写这篇文章的时候纠结了很久,如果说的太细,就要涉及到很多数学上的东西,比如要解释为什么变换矩阵是4x4的,要解释tangent space的动机.但是我觉得这对毫无基础而言的学习者来说是个灾难.所以我打算用一个特殊的番外篇来试图解释一些问题,但是你完全不用去看他.就像我记得一开始学习一个引擎的使用时,我们都是先掌握好他的用法,刻意回避掉源代码也就是实现过程,这对学习是有帮助的.等到我们自如的使用以后再来研究细节.<br/><br/>和初衷一样，我不觉得写一个shader是多么困难的事情，不过很多地方都把这个说的异常的玄乎。包括图形中用到的大量的数学知识，我也没觉得有多么的数学。当然最近我在看一个模拟流体的文章中，看到了久违的N-S方程，突然觉得有时候数学懂的多点还是很有用的。<br/>但是无论怎样，游戏里用的编程知识，甚至高超的数学技巧，都只是工具而已，如果你沉溺于其中势必会适得其反。真正的成功来自于设计。还是那句胡子白的老话：技术只是工具，不是诉求。<br/>本文的目的是从浅显的角度让你认识到什么的shader，让一个从来都没有写过一句渲染代码的同志们都能通过这几篇短文的学习开始自己东西使用可编程管线。当然，我也力求用最直白的方式让你搞清楚什么是线性变换，什么是仿射变换，Tangent Space啊，甚至刚才那个N-S方程。<br/><br/>首先我假设你稍微懂点高等数学的知识，微积分，线性代数，如果懂点微分几何就更好了。不过就算这些你听都没听过也不要紧。这不会影响阅读。<br/>两个问题：1.先去看下Generated里生成的文件,如果你能看懂一些片段么?<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2.最上面有很多大写字母,后面跟着=0,=1的你能大概懂么?<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3.如果上面那个问题你能回答,那么顺带看下这个问题,找两个文件,相同的定义,一个是0,一个是1,下面的片段有什么不同,你能看出来么?<br/><br/>如果前两个都回答不出来,那最好回去读下前两篇文章.<br/><br/>好的,如果都没难倒你,那么可以开始了。<br/>首先假设你知道渲染流水线，如果这个也不懂，最好找本基础的书看两眼，或者WIKI下。<br/>打开任意一个Shader VS文件（顶点着色器），如果有GB就随便开一个生成的文件，都缺不了两样东西。<br/>一个叫WorldMatrix（或者world），一个叫ViewProjectMatrix（或其他大同小异的名字）<br/>为什么这两个是必须的呢？也就是说一个简单的模型，美术在Max里拉出的一个BOX，到底要做哪些事情才能正确的显示在我们眼前呢？如果细说，就需要说到射影几何学。（我打算开个番外篇专门说这个内容 ：））<br/><br/>模型的每个顶点数据都有自己的位置信息，他们需要WorldMatrix来把自己的局部坐标变换到世界坐标。WorldMatrix是一个4×4的矩阵（为什么呢？请看番外篇吧）&nbsp;&nbsp;变换到WorldMatrix以后，最后一步需要把世界坐标中的模型变换到视坐标。就是ViewProjectMatrix，也是个4×4的矩阵。<br/><br/>这样就完成了一个最简单的变换。从本地坐标到屏幕坐标。To be continue...<br/><br/><br/><br/>]]></summary>
	  <link rel="alternate" type="text/html" href="http://www.guibian.com/article.asp?id=99" /> 
	  <id>http://www.guibian.com/default.asp?id=99</id>
  </entry>	
		
  <entry>
	  <title type="html"><![CDATA[Gamebryo系列材质详解：二]]></title>
	  <author>
		 <name>volfmath</name>
		 <uri>http://www.guibian.com/</uri>
		 <email>volfmath@gmail.com</email>
	  </author>
	  <category term="" scheme="http://www.guibian.com/default.asp?cateID=6" label="Tech" /> 
	  <updated>2010-04-28T01:30:38+08:00</updated>
	  <published>2010-04-28T01:30:38+08:00</published>
		  <summary type="html"><![CDATA[以下内容，在讲解过程中要不时的用到那张表格，希望你可以在合适的地方放置一边对照以便查看。<br/><br/>材质系统并不难理解，大白话就是我们经常说的“导出”。就是说美术人员在利用3D工具制作的那些东西，如果在游戏中使用。（其实这个比方不好.如果你很清楚的话.导出应该是把MAX里记录的数据转换成引擎所需要的数据.不仅仅是材质,还有顶点数据组织方式,包括位置,颜色，法线，多套UV数据，骨骼数据等等.而材质脚本是用来确定这些数据使用的方式.同样的数据可以有不同的表现,这就是Shader的作用.）MAX毕竟是一个通用软件，对于实时性比较高的游戏来说，我们很难百分百利用到所有Max的功能。这就需要数据间的一个对应。有些游戏的做法呢，是自己制作一个与Max差不多的东西，叫做引擎的工具，在他们自己工具里，给你规定好了一些可以使用的功能，而这些都是这款引擎所支持的功能。<br/>另外一些呢，就是做了导出工具，例如gamebryo。也就说美术的面对的原始工具依然是他们熟悉的Max或者Maya，XSI等。然后他们会有一张长长的表，告诉你哪些是支持的哪些是不支持的，其实有不少就算是支持的，也仅仅是模拟跟Max中查看的效果不完全一致。<br/><br/>gamebryo的材质系统，相比那些只给出材质编写规范的引擎有几点好处：<br/>1.完全隔离了美术与技术之间过多的无意义的讨论，比如美术描述我这里想要一种什么样的透明样式，技术人员要把它翻译成alpha_blend的方式等。这样会造成理解的误差，除非一个美术基础好，又懂技术的人员来完成，这样的人才是很少的。<br/><br/>2.规范了材质系统以后，gamebryo会根据不同的情况生成不同的材质脚本文件。（这里我们假设你的机器已经可以使用可编程管线了，事实上gamebryo的材质系统绝大部分是可以用固定管线实现的，而gamebryo也做到了对硬件不依赖。但这不是我们讨论的重点）。比如使用Normal Map的和不使用的，两个材质脚本（这里是Shader实现的）就有些不同。具体的以后在细分析。而这些不同是通过gamebryo内部的所谓Shader tree完成的。<br/><br/>3.所谓Shader Tree。对程序来说其实不难理解，就是一大堆function，或者说函数，或者说过程的片段。比如：世界坐标转换视坐标，光照的计算，Normal的计算，等等等等。当你在Max中用到这些选项后，他就会把所有用到的过程组织起来形成一个巨大的树状结构。所以叫ShaderTree。而这个树状结构就是一步步的流水线处理。好处不言而喻，坏处如果仔细想也能猜到。函数方法都被固定了，如果用光照，那么对于任何物体计算光照就一个方式，Normal也一样，如果你想做点个性的东西，对不起要么你自己组织ShaderTree(非常繁琐)，要么写自己的Shader。<br/><br/>gamebryo用哈希表来表示所用到的不同特性.比如是否有normal map啊,是否有darkmap啊.哈希表最终作为生成的材质脚本文件名.你可以看到有个generated文件夹下有些稀奇古怪的文件名就是那些了.注意他们是自动生成的.你不能做修改,或者说改了也没用.第二点,他保证了相异的功能不同名,哪怕只是很微小的差异.第三哈希表加快了文件名字符串匹配速度,能很快知道一个新模型用到的功能是否已经存在.另外在第一次进入游戏的时候会生成并且缓存下来,所以当游戏资源固定的时候是不会每次做这个工作的.所有的材质脚本的个数就是gamebryo所谓的自己的渲染管线的排列组合。如果你很熟悉可以推算出固定管线一共支持的描画方式的个数.更加详细的内容请查阅内核代码.<br/><span style="color:red">建议:<br/>1.固定管线基本能覆盖绝大多数游戏中大部分物体的描画方式.毕竟这是总结了很多游戏以后的一个浓缩.不是随便想出来的.所以尽量使用他.<br/>2.例外怎么办?首先肯定有例外.不可能有一个覆盖所有渲染方式的游戏材质系统,否则就自由成DX了,失去了设计的意义.<br/>3.我们项目中也遇到过例外.解决方式第一如果是一个比较通用的例外,并且完全舍弃掉原来某些功能的使用方式，建议直接修改核心的shader tree.有点抽象哈,后面具体例子里我会讲.第二,如果是仅仅扩展某一项或者某几项功能,并保留固定管线功能,建议扩展自己的shader tree.其实1也可以按照2的方式来做,但是自定义shader tree是件非常麻烦的工作,代码量也很大.最后一种,自己写shader,如果仅仅为了某几个特殊物体的处理.或者与固定管线差距太大.</span>]]></summary>
	  <link rel="alternate" type="text/html" href="http://www.guibian.com/article.asp?id=98" /> 
	  <id>http://www.guibian.com/default.asp?id=98</id>
  </entry>	
		
  <entry>
	  <title type="html"><![CDATA[Gamebryo系列材质详解：一]]></title>
	  <author>
		 <name>volfmath</name>
		 <uri>http://www.guibian.com/</uri>
		 <email>volfmath@gmail.com</email>
	  </author>
	  <category term="" scheme="http://www.guibian.com/default.asp?cateID=6" label="Tech" /> 
	  <updated>2010-04-28T00:02:10+08:00</updated>
	  <published>2010-04-28T00:02:10+08:00</published>
		  <summary type="html"><![CDATA[前一阵子我贴出了Gamebryo的材质管线的图片，没加解释的贴出的。我想对于明眼人有经验的人一眼就能看出他的思路是什么，高手通常还能分析出他的局限性与弊端。但是还是受到很多很多的回复。最近的很多经历让我觉得有必要详解一下整个这张图片。<br/>我力求做到国内解释的最详细的一篇，或许比官方还详细吧。但是由于我的知识层次结构，或许并不能面面俱到，所以如果你有新的观点也不妨给我指出吧。<br/>首先，我是一个程序，所以里面设计的大部分知识，偏重于图形学基础知识。可编程管线，Shader流水线，坐标变换，甚至微分几何。但是对于美术而言我就欠缺很多，不过好在我得到了很多美术同行的帮助，也会穿插讲一些美术方面的注意事项，以及实际项目过程中使用这套材质系统的经验。而对于后两条实际上，就目前我的菜鸟水平，是很泛泛的也是最需要行家来补充的。当然如果可以，我也将一些在MAX，Maya中如何操作以及一些在项目开发过程中遇到的问题，修改，或者弥补的方式。<br/>几点建议：<br/><span style="color:blue"><br/>1.适合人群：中低层次游戏开发人员，引擎开发人员，有志于从事图形方面研究的起步人员，懂程序的美术，懂美术的程序。高手请绕道吧。</span><br/><span style="color:red">2.也是我最想说的：任何引擎，或者说任何技术都有其所谓的局限性，就是CE3也不是万能的。当然这套材质系统更谈不上十全十美，我经常听到美术抱怨引擎的拙劣，或者程序抱怨美术的滥用。因为在技术日新月异的今天我们时常忘记了游戏画面的本质，我们常常吹嘘自己有了一款怎么怎么样的引擎，我们常常吹嘘自己能实现什么样的技术，但是永远不要忘记，技术只是手段，而不是苛求。一款游戏唯有风格确定了，知道我们要做什么，要实现什么样的画面，才能考虑怎样去做，而这些恰恰与引擎毫无关系。那些长久的，被人们时常拿来称颂的游戏没有一款是仅仅因为引擎而强大的。我想这不仅仅是美术开发的问题，程序又何尝不是，我记得那时候做工具的时候，有一天掌握了Command模式，我高兴的不得了，后来又一天，我发现Boost bind这个东西更是兴奋了半宿没睡。于是开始滥用设计模式，模板，沉迷于语言的技巧中不可自拔，以至于在项目中出现了很多问题，才让我清醒的认识到。简单的才是美的。时间会证明一切，只有那些最简单的最明了的东西才是长远的。扯远了。下面正式开始。</span><br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br/><br/><img src="http://www.guibian.com/attachments/month_0903/g2009310112240.jpg" border="0" alt=""/>]]></summary>
	  <link rel="alternate" type="text/html" href="http://www.guibian.com/article.asp?id=97" /> 
	  <id>http://www.guibian.com/default.asp?id=97</id>
  </entry>	
		
  <entry>
	  <title type="html"><![CDATA[在复旦视觉艺术学院练琴]]></title>
	  <author>
		 <name>volfmath</name>
		 <uri>http://www.guibian.com/</uri>
		 <email>volfmath@gmail.com</email>
	  </author>
	  <category term="" scheme="http://www.guibian.com/default.asp?cateID=7" label="Music" /> 
	  <updated>2010-04-05T22:20:20+08:00</updated>
	  <published>2010-04-05T22:20:20+08:00</published>
		  <summary type="html"><![CDATA[今天晚上去了大学城一趟，复旦大学视觉艺术学院3号楼。也就是图书馆那幢楼。在复旦练琴的感觉不错啊，3楼是一个大琴房，隔音效果很好，亲也不错。触感很好。：）&nbsp;&nbsp;以后就常去练琴了啊。另外文汇路是大学城宿舍，好多好多吃的啊。比西区好多了。<br/><img src="http://www.guibian.com/attachments/month_1004/h201045221810.JPG" border="0" alt=""/><br/>]]></summary>
	  <link rel="alternate" type="text/html" href="http://www.guibian.com/article.asp?id=94" /> 
	  <id>http://www.guibian.com/default.asp?id=94</id>
  </entry>	
		
  <entry>
	  <title type="html"><![CDATA[Gamebryo帧渲染系统详解]]></title>
	  <author>
		 <name>volfmath</name>
		 <uri>http://www.guibian.com/</uri>
		 <email>volfmath@gmail.com</email>
	  </author>
	  <category term="" scheme="http://www.guibian.com/default.asp?cateID=6" label="Tech" /> 
	  <updated>2010-03-31T23:46:29+08:00</updated>
	  <published>2010-03-31T23:46:29+08:00</published>
		  <summary type="html"><![CDATA[如果没记错的话，我曾经写过一篇关于Gamebryo帧渲染系统的内容。估计当时剖析的不是太详细。那么现在我在这里重新讲一下帧渲染系统，希望能把他将清楚。由于我手头没有代码，而且又是商业引擎，所以很多函数我并不是完整的使用gamebryo中的，能使用伪代码的地方我尽量使用伪代码。<br/><br/>好，首先再次强调下帧渲染系统是逻辑系统，严格上跟渲染没有任何关系，就是说如果你可以绕开帧渲染系统，一样可以画出想描画的东西，只不过GB这样做的目的是使得渲染层次更加清晰，灵活了。<br/>OGRE也有类似的概念，在Ogre中也可以定义自己的层，但是由于没有帧渲染系统，所以层次上不如Gamebryo灵活，方便易用。<br/><br/>RenderFrame 和RenderStep我就不再赘述了，因为这两个概念很简单，里面也没有实质性的内容。你想怎么理解都可以，前者是后者的超集，Step又是Click的超集。<br/><br/>详细说一下RenderClick和RenderView。RenderView可以理解成我们所要描画的物件。RenderView里有AppendScene这样的接口，就可以把所有想View的东西都挂接上去。RenderView里还有个重要的工具叫做Culler，Culler是做什么用的呢？是负责裁剪的，这里的裁剪是逻辑上的裁剪，就是精确到几何体级别的裁剪。（注意不是三角面级别的）。Culler是作为Processor被加进去的，就是一个裁剪的过程。Culler提供了一些抽象接口，来满足用户的自定义裁剪。就是说你可以根据你的需要来在渲染前进行裁剪。<br/><br/>下面说到RenderClick，RenderClick精确的字面意思就是一次描画，这个类的功能也基本是这样，知道了要画的东西，但是要画到什么上去就需要RenderClick了，每个RenderClick对应了一个RenderTarget。就是要描画的地方。一个描画的过程是这样的，首先找到RenderTarget就是要描画的地方，因为如果是后期特效，有时候会有多个RenderTarget。<br/>知道了要描画的地方后就开始描画了，首先从RenderView里找出要描画的几何体（这里的几何体已经是被裁剪过后的几何体了），然后Click里再做一个处理，这里的处理也是个Processor，就是意味着用户可以定义。这里处理的目的基本上是对物体做一个排序。这里不会再对几何体进行裁剪了，而是进行类似Alpha排序等这样的工作，保证物体被正确的按层次画出来。最终得到的RenderObjList就是用来描画的了。<br/><br/>整个过程其实还是比较简单的，给用户很多自己选择的机会。是一个不错的设计。]]></summary>
	  <link rel="alternate" type="text/html" href="http://www.guibian.com/article.asp?id=93" /> 
	  <id>http://www.guibian.com/default.asp?id=93</id>
  </entry>	
		
</feed>
