时不时，总有一阵儿，我什么事也干不了。

我也去办公厅，东瞄瞄，西看看，每十秒钟查一次电子邮件，网上逛一圈。也许干点儿象付运通卡账单之类不需要大脑的事。不过要回去哗啦哗啦写程序，可没门儿。

这种不出活的状态，一般通常会持续一两天。在我的软件开发生涯中也有过几个星期干不了活的时候。就像他们说的，我不在状态，我进入不了情况，我找不到组织。

人人都有情绪波动，有的人温和一些，有的响动大点儿，也有的可以整个乱套。但不管怎么着，那段不出活期似乎总是跟忧郁有点儿关系。

我不由得联想到那些专家说，人们基本上控制不了自己吃什么。任何节食计划都长不了。大家总是悠回各自的正常体重。也许作为一个软件工程师，我也不能控制什么时候最能出活。我唯一希望的就是发呆那段能被哗哗干活那段扯平，最终还能混碗饭吃。

自从我干上软件开发这一行起，我平均每天只有两三个的高效时间。这真让我头大。我在微软实习的时候，另外一个实习生告诉我，他每天12点上班，5点下班。5个钟头还包括午餐时间，但他的同事还对他特别满意。因为他干的活比一般人都多。其实我也一样。我每天只有两三个小时的高效时间。看着别人那么卖力的干，还有点不好意思。不过呢，我总是组里出活最多的。由此可见，“人件理论”和极限编程都坚持不加班，每周只干40小时，还是有点道理的。他们都清楚这么做不会降低一个小组的生产能力。

每天只能干两小时还没让我太担心，真让我担心的是完全干不了活的那些天。

我老想这是怎么回事儿。我努力回忆我出活最多的时候。估计是微软把我搬到一间漂亮的新办公室的时候。舒适豪华的办公室，窗外风景如画，窗对面樱桃花开满了石头堆砌的庭院。所有的一切都那么恰到好处。我马不停蹄地干好好几个月，一口气把Excel Basic的详细设计搞定。用象纪念碑那么高的一叠纸，详细描素了一个超大型目标模型和编程环境，工作之细致，令人难以置信。我自始至终就没停过手。去波士顿参加MacWorld I的时候，我都带着一台手提电脑，坐在哈佛商学院的大阳台上把Windows类别的所有文件都写完了。

按步就班并不难。通常我一天是这样度过的：1，去上班。2，查电子邮件和上网等等。 3，考虑是否应该吃完中饭在开始干活。4，吃完中饭回来。5，查电子邮件逛网。6，终于决定应该开始工作了。7，查电子邮件逛网，东瞄瞄，西看看。8，再次决定确实应该开始开始干活了。9，打开该死的编辑器。10，一直会些程序学到晚上7：30，写到忘记时间。

在以上第8步和第9步之间似乎有点缺陷，因为我不是每次都能顺利地执行下去。

对我来说，启动是唯一的难题。静止物体在不受外力作用的情况下会保持静止。大脑里有些物质的质量大得不可思议，让它加速太难了。但是只要速度上去了，在全速行使的情况下，倒不用使什么劲就能继续走下去。就象骑着自行车去作一次自费横穿美国的旅行，一开始，你根本想象不出要花那么多时间让车轮动起来，可是一旦动起来了，让它们继续转就不是一件很难的事了。

也许高效率的关键就：启动起来。配对编程法之所以成功，说不定就靠两个人在一起，互相强迫对方启动起来。

我在以色烈当伞兵时，一次，有个将军来给我们讲实战战术。他告诉我们，步兵战术其实只有一种：行进中开火。你一边开火一边朝着敌人冲过去，火力让敌人抬不起头来，不能朝你开火 (当一个军人喊：“掩护我”的时候，他的意思就是“在我冲过街时候，你朝敌人猛烈开火，迫使他猫起来，没法朝我开火)。前进了，你就可以占领阵地，接近敌人，这样你的胜算要大的多。你要是不往前冲，敌人就有时间来搞清楚形势，这可不妙。你要是不开火，敌人就要朝你开火，撂倒你。

我很长一段时间都在想着这个教导。我想通了不论是战斗机空中格斗还是大规模舰队攻击，大部份军事战略战术都是以行进中开火作为基础的。我又化了十五年时间才想通了行进中开火也是一个人在现实生活中成功的基本原则。你每天都得往前进点儿，不用想你写的程序怎么差劲，怎么卖不出去，只要你不停地写，不停地改，滴水也能穿石。同时， 要注意你的竞争对手朝你开火。他们是不是想让你全心全意应付他们的扫射，好让你往前走不了呢？

想想这些年来，微软开发出来的资料存取方法，从OBDC，RDO，DAO，ADO，OLEDB直到现在的 ADO，.NET，不停翻新，技术上有必要吗？还是因为那个设计组实在蹩脚，每过他妈一年就得重新发明一遍资料存取技术？(实际上可能真是)。它最终的效果其实是一道掩护火力，让竞争者别无选择，只能把本来该用来开发新功能的宝贵时间都用来移植和升级了。仔细看看软件行业，干得好的公司对那些对大公司都依赖最少，不用把所有精力都用来为赶潮流而把程序重写一遍，还得修改那些只有在Windows XP上才会出现的缺陷。那些花太多时间去猜测微软未来发展方向的公司，日子都好过不了。有些人见了.NET就发怵，忍不住要按.NET来完全重建自己的体系结构，以为自己别无选择。哥门儿，看清楚了，微软是在朝你开火呢，而且这只是掩护火力。这游戏就是这么玩儿的。这样一来，他们就可以大步朝前走，而你却不能。你要支持Hailstorm 吗？SOAP呢？还有RDF？是因为你的顾客需要，所以你支持它们？还是因为有人朝你开火而你觉得应该还击？大公司的营销部都懂火力掩护。他们到客人那儿就说，“你们不一定非买我们的。谁的产品最好您就应该买谁的。不过，我们想提醒您，在下单之前最好先确认他们支持(XML/ SOAP/CDE/J2EE)。否则你们就会被他们的技术套牢。”。等到小公司去向这个客户推销的时候，那个听话的CTO就会问他们：“你们有J2EE 吗？”。他们回去就只好不管卖不卖得掉，都埋头打造他们的J2EE。他们也就再没有机会来展示自己的特色了。其实，这只不过是个打勾功能。因为有个打勾拦在那儿空着，你就必须有这个功能。其实谁都不需要它。这就是火力掩护。

对于我这样的小公司来说，行进中开火意味着两件事。别跟时间过不去，同时你还得每天都进步。天不负苦心人，你终有出头的一天。我昨天花了一天时间只不过让FogBUGZ的颜色稍微好看点。这不要紧，只要不停步。最重要的是，我们的软件越来越好，客人越来越多。在我们达到Oracle 的规模之前，我们并不需要通盘战略。我们只需要每天早晨到办公室来，别多想，打开编程器。

e.Emboss Bump Mapping
想法不错，效果不好，应该算最简单的一种。

所有准确的时间，截图，由于时间长了，都没有了，真郁闷。

http://www.gamedev.net/reference/articles/article2138.asp
关于水面渲染的系列文章,很不错,这篇主要讲了cubic environment mapping和planar mirror两种办法来实现反射,可惜没有找到后续.
其中提到一种方法,可以用任意的Plane来替换Frustum的Near Plane来做Frustum Cull.
http://www.terathon.com/code/obliqued3d.html

http://www.gamasutra.com/gdce/2001/jensen/jensen_01.htm
Deep-Water Animation and Rendering
这篇讲的比较全了,各种Wave Model,各种渲染时的效果Reflection/Refraction,Caustics,Godrays,Foam and spray.

http://www.vterrain.org/Water/
很多关于水面渲染的文章.
不过好像没有讲怎么模拟水下的,谁知道哪里有讲水下模拟的文章?

http://freespace.virgin.net/hugo.elias/models/m_perlin.htm
Perlin Noise

16*16的FFT，嘿嘿远看还可以，近看就惨不忍睹了。


256*256的PN