substance redux 是一款紋理處理軟體加中介軟體，專門用於紋理生成和壓縮。具其使用者指南介紹，它能夠對紋理集進行優化，可以將現有壓縮演算法的效能提高50%或更多。其壓縮方式可是無失真壓縮，也可以是無失真壓縮。壓縮時可以由使用者自定義壓縮比和影象質量。
redux可以針對批量紋理檔案進行壓縮打包。操作流程是新建乙個project專案，為該專案匯入若干個紋理檔案，可以設定每乙個紋理的壓縮引數。最後匯出壓縮檔案。redux可以對多種格式的影象檔案進行壓縮。如果輸入影象的長寬不為2的ｎ次冪，ｒedux會自動將其拉伸至2的ｎ次冪。reduxsdk提供的ｄemo中將壓縮檔案解壓成符合dds格式的功能。
redux最大的賣點在於其影象生成功能,它可以用若干個簡單的圖元,經過演算法生成複雜的影象.圖元只需要占用很小的磁碟空間,生成方法的儲存也用不了多少磁碟空間,按他們官方的說法,遊戲中占用磁碟最大的部分是紋理,而使用了redux可以將紋理占用的磁碟空間降低到最小,從而最多能將遊戲的發布包大小降低到二分之一.
redux 提供3種紋理壓縮方式：
redux mode 1（redux 模式 1）是無失真壓縮演算法，在大多數情況下壓縮比最小。但是，通常它的渲染速度最快。
redux mode 2（redux 模式 2）是提供高質量影象的快速壓縮演算法，但是尺寸縮減率為 40% 左右。
redux mode 3（redux 模式 3）實現了影象質量和尺寸縮減率的大致均衡。影象質量低於模式 2，但是通過此模式可以獲得更高的壓縮比。尺寸縮減率為60% 左右。
在實際操作中，我將300張dds檔案進行壓縮，發現redux mode 2與redux mode 3生成的檔案大小是一樣的。我當時沒有在意這些dds檔案具體是什麼壓縮格式,估計大部分為dxt5的.
redux 主要針對批量紋理檔案進行壓縮，壓縮後的檔案分為兩類。
乙個「頭」檔案，包含主要資料檔案的目錄並向解壓縮**提供每個紋理的位置。該檔案的擴充套件名為 .rdxh，用於儲存每個紋理的詳細資訊，例如紋理名稱、資料夾和路徑。
乙個或多個「資料」檔案，包含實際已壓縮的紋理，這類檔案的擴充套件名為.rdxc。第二類檔案將採用「塊」。可以將所有紋理儲存在乙個大檔案中，這樣就只需要處理乙個資料「塊」。對於匯出的壓縮「塊」檔案，可以有以下三種設定方式：
1. no chunks（無塊）——即乙個大資料檔案，包含專案中每個單獨的紋理；
2. chunks split according to a size limit（根據大小限制來分割塊）——例如，每 4 mb 資料建立乙個新塊；
3. chunks split according to content（根據內容分割塊）——即為每個紋理建立乙個新塊。此時會生成乙個標頭檔案，若干個chunk檔案。
生成壓縮檔案之後，如果對原紋理檔案有任何改動，則必需重新生成壓縮檔案。
這種壓縮方式不太符合我的想法。我所希望的是通過乙個紋理名找到乙個壓縮檔案，載入該檔案，解壓縮並生成紋理。如果使用redux，引擎需要先載入乙個.rdxh標頭檔案，生成乙個redux定義的reduxhandle物件。然後根據紋理名找到紋理下標索引，再通過索引值使用redux提供的介面獲取紋理資料。
建立只含有乙個紋理檔案的redux工程，這樣生成的壓縮檔案中有含有乙個紋理。這是很麻煩的事情，工作量會很大。
reduxsdk提供的ｄemo中將壓縮檔案解壓成符合dds格式的資料，我曾經對其效能做過測試：
首先使用300個dds檔案進行測試。原檔案大小為59.6m，如果使用rar壓縮後大小為25.9m。dds的壓縮格式,當時沒有記錄,估計大部分為dxt5.
壓縮方式
檔案大小
載入檔案時間
同步建立紋理時間1
同步建立紋理時間2
不壓縮59.6m
2355ms
6172 ms
6133 ms
redux mode1
無失真壓縮
19.5m
743ms
25016 ms
24985 ms
redux mode2
40% reduction
17.3m
702ms
25862 ms
25860 ms
redux mode3
50% reduction
17.3m
674ms
25878 ms
25911ms
redux mode1
無失真壓縮
texture per chunk
20.6m
813ms
(此為建立reduxhandle的時間)
29027ms
29089ms
用引擎載入本地檔案建立這300個紋理需要的時間約為8秒，通過解壓redux檔案來建立300個紋理需要花費30多秒時間，是本地載入的4倍。
針對不同大小的檔案，建立紋理所使用的時間如下表所示：
紋理大小
檔案大小
引擎載入建立時間
redux mode1建立時間
redux mode2建立時間
redux mode3建立時間
128*128
11k1ms
105 ms
31 ms
30 ms
256*256
65k11 ms
228 ms
82 ms
82 ms
512*512
257k
49 ms
206 ms
140 ms
137 ms
1024*1024
1025k
176 ms
297 ms
418 ms
415 ms
2048*2048
5462k
242 ms
2263 ms
2265 ms
2294 ms
使用若干個簡單的圖元,經過演算法生成複雜的影象.這裡最大的問題是,美術無法適應這種做圖方式.正常情況下,美術用繪圖板在ps中做圖,而redux則要求美術以解析的方式,先想象出一張圖由多少圖元組成,再設計好圖元的組合方式.如何讓圖元生成影象,這種邏輯思維太顛覆了.一般人很難高效的用它提供的軟體做圖.就是因為這個原因,最終這個中介軟體沒有使用.
（1）專案的屬性設定時，設定mode2與mode3生成的壓縮檔案是一樣的。
（2）對單幅紋理的壓縮設定中redux mode3 與專案屬性中的mode3不一樣。
設定redux mode２與redux mode3沒有任何區別.
（3）對於一些紋理檔案壓縮後資料大小，要大於未處理的資料大小。
原dds檔案大小為6.475kb，壓縮後為6.682kb
原dds檔案大小為57.6kb，壓縮後為140.9kb
（4）使用有失真壓縮，對一些紋理會產生明顯的斑駁.
（5）當時我使用的版本，如果紋理的數目過多，會導致軟體崩潰。
（６）redux執行緒不安全，所以不能同時解壓多個紋理。
我個人對redux的感覺是:這個中介軟體很奇怪.目前的發展,硬碟大小不是問題,記憶體的消耗也不是問題.最大的問題是提高效率.為了提高效率我們經常使用一些用空間換時間的演算法.而redux則反其道而行之,它所做的無非是用時間換空間.以上這些材料還是我兩三年前整理的,文章中的效能測試資料僅供參考,不知道現在redux發展的如何,也不太清楚市面上有多少遊戲使用它.用google搜尋了下,也沒多少關於它的網頁.也許redux會在移動遊戲上有所發展,畢竟現在移動端的磁碟空間比pc端小了很多.
我所遭遇過的遊戲中介軟體 FlashOcx
在專案中,一開始使用flashocx做ui介面,後來買了scaleform,就成了兩種並存的情況.再後來的兩年半時間裡,有若干次的想把所有flashocx的介面翻成scaleform的.這個翻介面的工作不是我做,本來我認為不是什麼難事,畢竟二者的資源都是flash的swf檔案.但翻改起來,工作量比想...
我所遭遇過的遊戲中介軟體 HumanIK
我所遭遇過的遊戲中介軟體 humanik 憑心而論,humanik是我接觸的autodesk的三款中介軟體中最讓我省心的,另外兩款是scaleform和kynapse.省心的原因是它的複雜程度比其他兩款小很多,更為重要的是,我做的專案壓根沒用使用到humanik.所以我對humanik的研究只是停留...
我所遭遇過的中介軟體 3D MAX SDK
搞圖形的人都知道3d max,而3d max sdk就是在該軟體基礎上的一套軟體開發包.至於該不該將3d max sdk歸納為中介軟體,不要在意這細節了,反正我覺得sdk和中 間件就差不多是乙個東西.實際上我看網上有些文章將中介軟體與外掛程式混為一談.在我看來,中介軟體是用於做軟體開發的,外掛程式則...