發一下牢騷和主題無關：
gdc13上面的分享（可以在gdcvault上面檢視），ubi和刺客信條無需分析了。
由於是發展了多年的引擎，所以主要是分析在這一代有什麼進化，相當不錯，實用性很強。
由於需要member身份才能看，所以我這裡多截一些圖好了。
氣候
除了畸形應用particle系統來做的氣候效果之外，對於一些特有的效果，應用其他的方法可以更高效和更好的來做：
cylinder based effect
應用cylinder來做一些volumetric的效果.
height based fog
這個倒不是cylinder based的，就是一般的計算height fog， 但是裡面有和陽光相關的引數：
雨：
近處是particle，遠處是cylinder based scrolling uv 做的雨。
雪
只有particles
雨雪遮擋
可以看出此代console效能的無奈。
surface上的溼潤和積雪效果
- 根據normal的方素來停止積累和溼潤效果的調整
- 溼潤就調整gloss
- 積雪就是調整diffuse顏色
踩出來的雪的陳跡
這個是這代遊戲的一個重要特性：
- 效果冷豔
- 影響gameplay--應該是可以根據這個來追蹤
- 主角和動物都市有
- 地形是地形，上面的雪是有專門的雪的mesh
- 在做雪痕的時候，是把雪的mesh在index buffer上面做調整，旁邊挖出洞
- 補上一個displacement map+tessellated triangle做出雪痕的外形
- tessellation這部分比擬直接，在可以r2vb的A卡上面可以直接做這個
個人覺得這個應該是為了lod來做，應用terrain渲染上面常用的geometry morphing應該也可以。
光照
初期的AC系列應用一個比擬簡單的lightmap，
左邊是高度，右邊是光照資訊，這樣的方法來記錄光照，然後每個物件到這兩個貼圖中來sample獲得光照資訊。
品德上還是不太好，沒有光的方向等資訊。
那麼改進版：
這個用法有點意思，的確不錯，那個第二個貼圖的HUE就是光的顏色亮度資訊。
AO
原先ac應用bake在vertex上的ao，它的缺陷也是比擬多的：
新的ao方法是ssao+預處理的一個world ao
ssao的缺陷是很明顯的：
- 產生ao的資訊就是來螢幕空間可以反算出來的world position的很小一個範圍，這個限制直接導致voxel cone tracing（link）產生的ao質量要好很多
ac的ao做法是：
本質上就是構建了一個非常簡化的天下mesh的voxel資訊，只是這個是在2d texture裡面存的。
多人渲染
每日一道理
“一年之計在於春”，十幾歲的年紀，正是人生的春天，別辜負了歲月老人的厚愛與恩賜。行動起來，播種夢想吧！
多人戰鬥階段有上千人，城鎮裡面有300到400人，這樣的範圍如安在ps3/xbox360上達到？
- instancing， 32一個batch，把vertex buffer複製32份（記憶體消費也是32倍）
- 這個應該主要是限制於console平臺的原因，如果pc平臺加vertex texture應該就不用去複製32份，不過需要instancing的也不會是很精細的人物，所以尚可
- 渲染階段：
- 能r2vb就r2vb
- 360上面是cpu計算骨骼資料，然後vertex texture
- ps3上面應用spu直接算出最後skinning好的mesh
水渲染
基於的論文是tessendorf的經典論文（最開始用於泰坦尼克號的海水渲染，略晦澀：筆記）。
然後應用論文中的方法，來預計算3個頻率的波：
水上的泡沫是每幀逐漸積累和消散的，在render target上面每幀做這個。
也是有高頻和低頻資料。
光照效果方面比擬畸形。
綜合一下：
NodeBasedShaderSystem
就是unreal引擎那種連節點生成material的方法，ac應用了，但是其他專案應用ac引擎的時候都給去掉了。
這一塊是圖形程式設計方面爭議最多的，有用的有不用的。
ac這裡把爭議部分列了出來。
對於我們，可能很多人瞥見unreal應用了，就覺得這個是更好的方法（或者說是最好的方法），但是其實應該說不是這樣的。
這裡首先是NodeBasedShaderSystem好的一面：
美術易於控制和發明效果，在發明prototype階段，效率無可比擬。
商業引擎這樣選擇顯然是更好的：不需要程式設計師停止深度參與的情況下，讓專案組可以快速做出好的東西，否則一開始可能就沒人去應用了。
在程式設計師可以深刻參與的情況下，手寫shader的比率還是相當高的。
然後就是不好的一面：
在應用這樣的引擎的時候，如果自己肆意施展，很輕易導致嚴重的效能問題，在後期舉步維艱。
這個就看團隊的氣力，尤其是程式設計師，TechArt對於資源的控制了，這還是可以搞定的問題，就像應用手寫預製shader的靈巧性問題也可以戰勝一樣。
帶著解決問題的態度，可能是兩者結合是更公道的方法，應用NodeBasedShaderSystem，並且有程式設計師手寫替換的功能，這樣在prototype和效率上可以達到一個比擬好的平衡。
DX11
首先到dx11，現實也就意味著是更強的平臺，直接各種lod都拉高。
裡面兩大塊比擬特殊：高質量的AO和陰影
在全resolution和1/2 resolution的應用mssao，在1/4 resolution上面應用hbao。
shadow
ac console版是poisson disc filter，在之前crytek一個ppt裡面有提到。
但是這個在邊緣就是比擬花，這裡ac應用了叫octagonal filter，現實上是sample了更多的點，在lightspace裡面以8角的方法挪動，加上lightview camera本身就是會有snapping按照texel為單位挪動，所以這個做出來就是更加平滑穩定，sample數量達到了25tap：
關於dx11的提議：
一頓大真話，概括起來就是dx11彷彿沒什麼用，但是ac彷彿在dx11上面展開的未幾，大殺器direct compute沒有提根本。
deferred context由於是driver控制，不如是dx9上面自己做多執行緒的方法可控性高，效率更好一些。
d3d query，各個廠商實現不同，一種顯示卡上ok，另一種上面就跪了可能最好不要用太多
tessellation，特有用的地方未幾，少用吧。
多和廠商聯絡。
文章結束給大家分享下程式設計師的一些笑話語錄：
開發時間
專案經理: 如果我再給你一個人,那可以什麼時候可以完工?程式設計師: 3個月吧!專案經理: 那給兩個呢?程式設計師: 1個月吧!
專案經理: 那100呢?程式設計師: 1年吧!
專案經理: 那10000呢?程式設計師: 那我將永遠無法完成任務.
