在壓縮tangent frame一文中，我們看到了把tangent frame壓縮到4個位元組的方法。現在讓我們看看如何壓縮其他屬性，以達到減小頂點資料的目的。
首先看看完整的頂點都包含了哪些屬性：
屬性型別
大小（位元組）
備註position
float3
12texcoord
float2
8tangent
float3
12binormal
float3
12normal
float3
12blend_index
uint4
16骨骼動畫模型才有
blend_weight
float4
16骨骼動畫模型才有
總共
88
經過tangent frame壓縮，同時一般引擎都會把blend_index和blend_weight存入uint32，頂點格式就成了：
屬性型別
大小（位元組）
備註position
float3
12texcoord
float2
8tangent_quat
uint32
4blend_index
uint32
4骨骼動畫模型才有
blend_weight
uint32
4骨骼動畫模型才有
總共
32
這也是一般引擎常見的頂點布局。
上面可以看到除了position和texcoord，其他屬性都已經沒什麼油水了。所以我們的目標是把postion和texcoord壓縮到每個分量16-bit的程度，也就是：
屬性型別
大小（位元組）
備註position
short4
8texcoord
short2
4tangent_quat
uint32
4blend_index
uint32
4骨骼動畫模型才有
blend_weight
uint32
4骨骼動畫模型才有
總共
24
好在，現在的顯示卡都支援short4和short2的頂點屬性格式，給這份目標提供了可能。可惜不支援short1，否則position還能拆成short2+short1，能多省乙個short。
頂點屬性中存放的short在gpu端讀到的是[-1, 1]範圍的值，很顯然，直接把position和texcoord的分量直接放到short是不行的。這裡必須在模型裡儲存position和texcoord的bounding box，而在頂點屬性裡存的是經過bounding box歸一化過的分量。在vs裡面，用兩者重建出float的分量，繼續後面的計算。另乙個好在，現代顯示卡都支援mad，所以position * bounding_box_extent + bounding_box_center只需要一條指令，計算造成的效能幾乎無損，傳遞屬性卻能省掉幾乎一般的頻寬。
就是這樣簡單直接的壓縮，讓頂點大小比僅壓縮tangent frame的情況下又減少了1/4。精度上，short能提供65536個不同的值，對於一般情況綽綽有餘了。
大小（位元組）
壓縮率備註
原始格式
88100%
klayge 4.1及以前
4855%
tangent frame壓縮到8位元組，blend_index壓縮到4位元組
klayge 4.2
2428%
tangent frame壓縮到4位元組，blend_weight壓縮到4位元組，position壓縮到8位元組，texcoord壓縮到4位元組
經過這樣的壓縮，新格式只占用原始格式的28%。在causticsmap和deferredrendering等例子中效能有10%的提公升。
頂點資料壓縮
看過敏敏的 今年2 3月份曾經整過這玩意，做到用tangent.w來存handedness，解決了uv mirror的問題 沒想到頂點資料壓縮還有這麼深的學問，於是乎按照資料對max外掛程式進行了修改，效果超出想象 目前做到使用unsigned char x 4來存normal和tangent，sh...
sdk完整壓縮包
一 sdk manager設定 伺服器 開啟sdk manager，選擇選單欄的tools options 二 修改hosts檔案 windows在c windows system32 drivers etc目錄下，linux使用者開啟 etc hosts檔案，然後新增 當時驗證這種方式的時候貌似不...
自動計算頂點緩衝中所有頂點的法線
問題 當繪製自定義的結構時，你會發現光照不正確。這是因為你沒有指定正確的法線向量，顯示卡要求每個頂點都有法線資訊，這樣它才可以決定每個三角形獲得多少光照，詳細資訊可見第六章。為每個頂點計算法線向量看起來很複雜，因為大多數頂點被多個三角形共享。如果每個頂點只被乙個三角形使用，你只需找到三角形的法線向量...