后來，我書沒有讀好，錢也沒有賺到，喜歡的人也沒能在一起，最后只給自己留下了一生的缺點，不自信，猜疑，膽小，自閉。。。。
---- 網易與熱評
一、文件解析漏洞
1、IIS6.0目錄解析
只要存在一個xx.asp（xx.asa）的文件夾，里面所有的文件都會被解析為asp文件
2、IIS6.0分號后面不解析
a.asp;jpg，這樣的文件會被解析成asp文件，另外*.cer，*.asa也都會被解析成為asp文件
3、apache解析漏洞，apache是從右往左解析后綴，直到解析到可以識別的后綴
假如有個文件是a.php.abc.aab.acd，apache最終解析為a.php
4、IIS7.0、IIS7.5、Nginx<8.03畸形解析漏洞
在默認Fast-CGI開啟狀況下，黑客上傳一個名字為cracer.jpg，內容為<?php fputs(fopen('shell.php','w'),'<?php eval($_POST[aiyou])?>');?>的文件，然后訪問cracer.jpg/.php,在這個目錄下就會生成一句話木馬shell.php
漏洞影響范圍：nginx 0.7.65以下（0.5.*, 0.6.*, 0.7.* ）全版本系列和0.8.37（0.8.*）以下8系列受影響。
http://ap.test.com/1.jpg/1.php
http://ap.test.com/1.php%00.jpg
5、.htaccess文件解析
如果在Apache中.htaccess可被執行，且可被上傳，在.htaccess中寫入:<FilesMatch "mst.jpg"> SetHandler application/x-httpd-php</FilesMatch>，然后再上傳mst.jpg的木馬, 這樣mst.jpg就可解析為php文件
二、上傳本地驗證繞過
服務器命名規則
第一種：上傳文件名和服務器命名一致
第二種：上傳文件名和服務器命名不一致（隨機）
1、客戶端 Javascript檢測(通常為檢測文件擴展名）
首先判斷js本地驗證，在用burp抓包，提交的時候，burp沒有抓到包，就已經彈出了彈框，說明本地驗證
繞過方法：
刪除監測函數
使用burp抓包改名
使用firebug直接刪除本地驗證的js代碼
添加js驗證的白名單，如將php的格式添加進去
2服務端MIME類型檢測(檢測 Content-Type內容)
直接使用bup抓包,得到post上傳數據后,將 Content-Type內容改成image/png就可以成功繞過。
3.服務端目錄路徑檢測(檢測跟path參數相關的內容）
允許上傳，但是上傳到一個沒有權限的文件夾，先抓包，發送到repeater，將路徑修改為上級目錄
三、上傳服務端驗證繞過
1、文件名大小寫繞過
用像AsP,pHp之類的文件名繞過黑名單檢測
2、名單列表繞過
用黑名單里沒有的名單進行攻擊,比如黑名單里沒有asa或cer之類（asp:asa,cer,1.asp;.jpg,1.asp/1.jpg php:php3,php4,php5,php7）
3、特殊文件名繞過
比如發送的http包里把文件名改成test.asp.或test.asp_(下劃線為空格),這種命名方式在windows系統是不被允許的，所以需要在burp之類里進行修改,然后繞驗證后，會被windows系統自動去掉后面的點和空格,但要注意Uni/ Linux系統沒有這個特性。
4、0×00截斷繞過
把文件名修改為1.php%00.jpg,然后將%00編碼
5、表單提交按鈕
有的上傳頁面沒有提交按鈕，可以查看源碼，然后添加一個
<input type="submit" value="提交" name="bb">
禁止非法，后果自負
歡迎關注公眾號：web安全工具庫
推薦：用 NSDT編輯器 快速搭建可編程3D場景
glTF 擴展擴展了基本 glTF 模型格式。 擴展可以引入新的屬性（包括引用外部數據的屬性，并且擴展可以定義這些數據的格式）、新的參數語義、保留的 ID 和新的容器格式。 擴展是針對特定版本的 glTF 編寫的，并且可能會在更高版本的 glTF 中提升為核心 glTF。
glTF廣泛應用于Web上的3D展現，如果你需要將模型轉換為glTF格式，可以使用NSDT 3DConvert的在線轉GLTF工具。
https://3dconvert.nsdt.cloud
所有 glTF 對象屬性（請參閱 glTFProperty.schema.json）都有一個可選的擴展對象屬性，該屬性可以包含新的特定于擴展的屬性。 這允許擴展擴展 glTF 的任何部分，包括幾何、材質、動畫等。擴展還可以引入新的參數語義、保留 ID 和包含 glTF 的新格式。
GLTF擴展無法刪除現有的 glTF 屬性或重新定義現有的 glTF 屬性以表示其他含義。
示例包括：
{
"materials": [{
"emissiveTexture": {
"index": 0,
"extensions": {
"KHR_texture_transform": {
"offset": [0, 1],
"rotation": 1.57079632679,
"scale": [0.5, 0.5]
}
}
}
}]
}GLTF擴展可以添加新的屬性和值，例如屬性語義或紋理的 mime 類型。 在所有 Khronos (KHR) 擴展中，并且作為供應商擴展的最佳實踐，這些功能添加旨在允許在無法識別 extensionsUsed 數組中的擴展的工具中安全回退使用。
模型中使用的所有擴展都以字符串形式列在頂級 extensionsUsed 數組中； 所有必需的擴展都以字符串形式列在頂級 extensionsRequired 數組中，例如，
{
"extensionsUsed": [
"KHR_draco_mesh_compression", "VENDOR_physics"
],
"extensionsRequired": [
"KHR_draco_mesh_compression"
]
}這允許引擎快速確定它是否支持渲染模型所需的擴展，而無需檢查所有對象的擴展屬性。
如果典型的 glTF 加載器在不支持該擴展的情況下無法加載資源，則認為需要擴展。 例如，任何網格壓縮擴展都必須根據需要列出，除非資產提供了未壓縮的后備網格。 同樣，必須根據需要列出紋理圖像格式擴展，除非還提供了核心格式（JPG、PNG）的后備紋理。 通常，PBR 或其他類型的材質擴展不應在 required 中列出，因為核心 glTF 材質可以被視為此類擴展的有效回退，并且此類擴展不會導致一致的 glTF 加載程序失敗。
要創建新的GLTF擴展，請使用GLTF擴展模板并在此存儲庫中打開拉取請求。 確保將擴展添加到 glTF 擴展注冊中心。
如果擴展添加一個新的頂級數組（通過擴展根 glTF 對象），則其元素應繼承 glTFChildOfRootProperty.schema.json 的所有屬性。 擴展引入的其他對象應繼承 glTFProperty.schema.json 的所有屬性。 根據 glTF 2.0 約定，模式應該允許附加屬性。 請參閱 KHR_lights_punctual 作為示例。
如果缺乏擴展支持會妨礙正確的幾何加載，則擴展規范必須聲明這一點（并且必須在 extensionsRequired 頂級 glTF 屬性中提及此類擴展）。
注意：由于歷史原因，較舊的擴展可能不遵循這些準則。 未來的擴展應該這樣做。
除了擴展之外， extras對象也可以用來擴展glTF。 這與擴展完全分開。
所有 glTF 對象屬性都允許向 extras 對象子屬性添加新屬性，例如，
{
"asset": {
"version": 2.0,
"extras": {
"guid": "9abb92a3-39cf-4986-a758-c43d4bb4ab58",
}
}
}這使得 glTF 模型能夠包含特定于應用程序的屬性，而無需創建完整的 glTF 擴展。 對于擴展不會被廣泛采用的利基用例來說，這可能是首選。
應當將你的GLTF擴展添加到GLTF擴展注冊中心，以便得到廣泛地應用。具體注冊方法請參考 README.md。
Khronos 擴展使用保留的 KHR 前綴。 一旦獲得 Khronos 集團的批準，它們就會受到 Khronos IP 框架的保護。 打算批準的擴展也可以使用 KHR 前綴來避免名稱/代碼/版本抖動。 Khronos 成員可以提交延期批準，然后由 Khronos 發起人委員會進行投票。
Khronos Group 已批準以下擴展：
KHR_draco_mesh_compression擴展定義了一個架構以使用 glTF 格式的 Draco 幾何壓縮（非規范）庫。 這使得 glTF 支持流壓縮幾何數據而不是原始數據。 該擴展規范基于 Draco 比特流版本 2.2（該規范的全部內容是規范性的并包含在范圍內）。
一致性部分指定實現在遇到此擴展時必須執行的操作，以及擴展如何與基本規范中定義的屬性進行交互。
KHR_lights_punctual擴展定義了一組與 glTF 2.0 一起使用的燈光。 燈光定義場景內的光源。
許多 3D 工具和引擎支持燈光類型的內置實現。 使用此擴展，工具可以導出這些燈光，引擎可以導入這些燈光。
該擴展定義了三種“準時”光類型：定向光、點光和聚光燈。 準時光被定義為參數化的無限小點，它們以明確的方向和強度發光。
這些燈光由節點引用并繼承該節點的變換。
此擴展的一致實現必須能夠加載資源中定義的燈光數據，并且必須使用這些燈光渲染資源。
KHR_materials_anisotropy擴展定義了材料的各向異性（anisotropy）屬性，例如通過拉絲金屬可觀察到的屬性。 引入非對稱鏡面波瓣模型來考慮這種現象。 該波瓣的視覺上明顯的特征是鏡面反射的細長外觀。
KHR_materials_clearcoat擴展定義了一個透明涂層，可以分層在現有 glTF 材料定義之上。 透明涂層是基于物理的渲染中常用的技術，用于表示應用于基材的保護層。
核心 glTF 2.0 材質模型包括 emissiveFactor 和 emissiveTexture 來控制材質發出的光的顏色和強度，并限制在范圍 [0.0, 1.0] 內。 然而，在具有高動態范圍反射和照明的 PBR 環境中，可能需要更強的發射效果。
在KHR_materials_emissive_strength擴展中，提供了一個新的 emissiveStrength 標量因子，它控制每種材料的發射強度的上限。
可以使用核心材料的 emissiveFactor 和 emissiveTexture 控件對該強度進行著色和回火，從而允許強度在材料表面上變化。 為 emissiveStrength 提供高于 1.0 的值可能會對反射、色調映射、光暈等產生影響。
KHR_materials_ior擴展允許用戶將折射率設置為特定值。
glTF 中金屬粗糙度材料的介電 BRDF 使用固定值 1.5 作為折射率。 這非常適合許多塑料和玻璃，但不適用于水或瀝青、藍寶石或鉆石等其他材料。
彩虹色描述了一種色調根據視角和照明角度而變化的效果：半透明層的薄膜會導致相互反射，并且由于薄膜干涉，某些波長會被吸收或放大。 在肥皂泡、油膜或許多昆蟲的翅膀上都可以看到彩虹色。
利用 KHR_materials_iridescence 擴展，可以指定薄膜的厚度和折射率（IOR），從而實現虹彩材料。
KHR_materials_sheen擴展定義了可以分層在現有 glTF 材質定義之上的光澤。 例如，光澤層是基于物理的渲染中用于表示布料和織物材料的常用技術。
KHR_materials_specular擴展向金屬粗糙度材質添加了兩個參數：鏡面反射和鏡面顏色。
鏡面反射允許用戶配置電介質 BRDF 中鏡面反射的強度。 值為零會禁用鏡面反射，從而產生純漫反射材質。 金屬BRDF不受該參數的影響。
specularColor 更改電介質 BRDF 中鏡面反射的 F0 顏色，允許藝術家在金屬粗糙度材質中使用鏡面光澤度材質 ( KHR_materials_pbrSpecularGlossiness) 中已知的效果。
KHR_materials_transmission擴展旨在解決光學透明度最簡單和最常見的用例：無折射、散射或色散的無限薄材料。 專門處理“薄”材料（即僅考慮表面而不考慮體積的材料）可以在計算折射和吸收等內容時進行許多簡化。
許多光學透明材料無法用核心 glTF 2.0 PBR 材料以物理上合理的方式表示。 這是因為核心規范僅包含“alpha 作為覆蓋范圍”的概念（通過 baseColorFactor 和 baseColorTexture 的 alpha 通道公開）。 許多常見材料（例如玻璃和塑料）需要截然不同的渲染技術。
KHR_materials_unlit擴展定義了用于 glTF 2.0 材質的無光照著色模型，作為核心規范提供的基于物理的渲染 (PBR) 著色模型的替代方案。 不發光材料的三個激勵用例包括：
這些用例并不相互排斥：藝術家可能出于性能原因選擇未照明的材料，并做出美學決策來補充該選擇。 因此，能夠渲染 PBR 的客戶端實現不應自動“升級”到完全著色的 PBR。 在無光照材質上指定的任何核心 PBR 屬性（ baseColor 除外）僅作為不支持 KHR_materials_unlit 擴展的客戶端的后備。 擴展名，無論是資產中必需的還是可選的，都表明對無光照視覺樣式的偏好。
KHR_materials_variants擴展允許對資產的多種材質變體進行緊湊的 glTF 表示，其結構允許在運行時進行低延遲切換。
一個典型的用例是數字商務，其中可能會向用戶展示例如 一雙運動鞋以及在不同顏色之間切換的能力。
默認情況下，glTF 2.0 材質描述包圍無限薄體積的表面的散射屬性。 由網格定義的表面代表薄壁。
KHR_materials_volume擴展使得可以將表面轉變為體積之間的界面。 材料所附著的網格定義了均勻介質的邊界，因此必須是流形的。 體積提供折射、吸收和散射等效果。 散射不是本擴展的主題。
頂點屬性通常使用 FLOAT 組件類型存儲。 然而，這可能會導致精度過高、內存消耗和傳輸大小增加，以及渲染性能降低。
KHR_mesh_quantization擴展擴展了網格屬性存儲允許的組件類型集，以提供內存/精度權衡 - 根據應用程序需求，16 位或 8 位存儲就足夠了。
使用 16 位或 8 位存儲通常需要轉換原始浮點值以適應統一的 3D 或 2D 網格； 該過程通常稱為量化（quantization）。
為了簡化實現要求，該擴展依賴于現有的方法來指定幾何變換，而不是向模式添加特殊的反量化變換。
例如，靜態 PBR 就緒網格通常需要每個頂點的 POSITION（12 字節）、TEXCOORD（8 字節）、NORMAL（12 字節）和 TANGENT（16 字節），總共 48 字節。 通過此擴展，可以使用 SHORT 來存儲位置和紋理坐標數據（分別為 8 和 4 字節），使用 BYTE 來存儲法線和切線數據（各 4 字節），每個頂點總共 20 字節，通常可以忽略不計 質量影響。
由于該擴展不提供指定數據的 FLOAT 和量化版本的方法，因此使用該擴展的文件必須在 extensionsRequired 數組中指定它 - 該擴展不是可選的。
KHR_texture_basisu擴展增加了使用具有 Basis Universal 超級壓縮的 KTX v2 圖像指定紋理的功能。 此擴展的實現可以使用此類圖像作為 glTF 2.0 中可用的 PNG 或 JPEG 圖像的替代品，以提高資源傳輸效率并減少 GPU 內存占用。 此外，指定 mip 貼圖級別是可能的。
使用擴展時，允許使用值 image/ktx2 作為 KHR_texture_basisu 紋理擴展對象的 source 屬性引用的圖像的 mimeType 屬性。
在運行時，引擎應將通用紋理格式轉碼為平臺支持的某種塊壓縮紋理格式。你可以使用BasisViewer在線查看Basis格式的紋理。
許多技術可用于優化 3d 場景的資源使用。 其中最主要的是能夠最大限度地減少 GPU 必須加載的紋理數量。 為了實現這一目標，許多引擎鼓勵將許多對象的低分辨率紋理打包到單個大型紋理圖集中。 然后，通過垂直和水平偏移以及該區域的寬度和高度來定義與每個對象相對應的生成圖集的區域。
為了支持此用例，KHR_texture_transform擴展向 textureInfo結構添加了偏移、旋轉和縮放屬性。 這些屬性通常作為 UV 坐標上的仿射變換來實現。 在 GLSL 中：
varying in vec2 Uv;
uniform vec2 Offset, Scale;
uniform float Rotation;
mat3 translation=mat3(1,0,0, 0,1,0, Offset.x, Offset.y, 1);
mat3 rotation=mat3(
cos(Rotation), sin(Rotation), 0,
-sin(Rotation), cos(Rotation), 0,
0, 0, 1
);
mat3 scale=mat3(Scale.x,0,0, 0,Scale.y,0, 0,0,1);
mat3 matrix=translation * rotation * scale;
vec2 uvTransformed=( matrix * vec3(Uv.xy, 1) ).xy;這相當于Unity的 Material#SetTextureOffset和 Material#SetTextureScale，或者Three.js的 Texture#offset和 Texture#repeat。 截至目前，UV 旋轉尚未得到廣泛支持，但為了向前兼容性而包含在此處。
KHR_xmp_json_ld擴展向 glTF 添加了對 XMP（可擴展元數據平臺）(ISO 16684-1) 元數據的支持。 元數據用于傳輸有關 glTF 資產的信息（例如歸屬、許可、創建日期）。 元數據對 glTF 資源外觀和渲染沒有規范影響。
XMP 是一種將元數據嵌入到文檔中的技術，自 2012 年以來一直是 ISO 標準。XMP 數據模型的一個實例稱為 XMP 數據包 (ISO 16684-1.1)。 XMP 元數據作為元數據包數組嵌入到頂級 glTF 擴展中。 然后可以從以下類型的 glTF 對象引用 XMP 元數據包：資產、場景、節點、網格、材質、圖像、動畫。 glTF 頂級對象資產引用的 XMP 元數據適用于整個 glTF 資產。
XMP 元數據按命名空間組織 (ISO 16684-1.2)。 此擴展允許將任何 XMP 元數據命名空間嵌入到 glTF 資產中。 glTF 中的 XMP 元數據數據包使用 JSON-LD 的受限功能子集。 這允許 JSON 解析器和 JSON-LD 解析器讀取各個數據包。
XMP 的 JSON-LD 序列化 (ISO 16684-3) 中概述了使用 JSON-LD 序列化 XMP 元數據。 JSON-LD 規范概述了 JSON-LD 1.1 的詳細使用方法。 JSON-LD 限制和建議中概述了 glTF 的其他限制。
EXT_mesh_gpu_instancing擴展專門設計用于啟用 GPU 實例化，使用少量繪制調用一次渲染單個網格的多個副本。 它對于樹木、草地、路標等非常有用。平移、旋轉和縮放屬性允許網格以不同的旋轉和比例顯示在許多不同的位置。 與頂點屬性一樣，自定義實例屬性可以使用下劃線作為前綴（例如 _ID、 _COLOR 等），并用于特定于應用程序的效果。
雖然此擴展存儲針對 GPU 實例優化的網格數據，但需要注意的是，(1) 即使沒有此擴展，GPU 實例和其他優化也是可能的，并且受到鼓勵，以及 (2) 該術語的其他常見含義“ 實例化”存在，與此擴展不同。
glTF 文件帶有各種二進制數據 - 頂點屬性數據、索引數據、變形目標增量、動畫輸入/輸出 - 這些數據可能占總體傳輸大小的很大一部分。 為了優化交付大小，可以使用 gzip 等通用壓縮 - 但是，它通常不會捕獲 glTF 二進制數據中的某些常見類型的冗余。
EXT_meshopt_compression擴展提供了一個用于壓縮二進制數據的通用選項，該選項是針對 glTF 緩沖區中常見數據類型定制的。 該擴展在 bufferView 級別上工作，因此與數據的使用方式無關，支持幾何圖形（頂點和索引數據，包括變形目標）、動畫（關鍵幀時間和值）和其他數據，例如 EXT_mesh_gpu_instancing 的實例轉換。
與超壓縮紋理類似（請參閱 KHR_texture_basisu），此擴展假設緩沖區視圖數據針對 GPU 效率進行了優化 - 使用量化并使用 GPU 渲染的最佳數據順序 - 并在 bufferView 數據之上提供壓縮層。 每個 bufferView 都是獨立壓縮的，這使得加載器能夠最有效地將數據直接解壓縮到 GPU 存儲中。
除了優化壓縮比之外，壓縮格式還具有兩個特性：非常快的解碼（使用 WebAssembly SIMD，解碼器在現代桌面硬件上以約 1 GB/秒的速度運行），以及與通用壓縮兼容的字節存儲。 也就是說，不是盡可能減少編碼大小，而是以通用壓縮器可以進一步壓縮比特流的方式構建比特流。
這對于典型的 Web 交付場景是有益的，其中所有文件通常都使用 gzip 壓縮 - 這里的編解碼器不是完全替換它，而是增強它，同時仍然減小大小（當 gzip 壓縮不可用時，這對于優化交付大小很有價值） ，并且還減少了 gzip 解壓縮的性能影響，gzip 解壓縮通常比此處提出的解碼器慢得多）。
EXT_texture_webp擴展允許 glTF 模型使用 WebP 作為有效的圖像格式。 未實現此擴展的客戶端可以忽略提供的 WebP 圖像并繼續依賴基本規范中可用的 PNG 和 JPG 紋理。 定義后備紋理是可選的。 最佳實踐部分描述了此擴展的預期用例以及在沒有后備紋理的情況下使用它時的預期行為。
WebP 是一種由 Google 開發和維護的圖像格式，可為網絡上的圖像提供卓越的無損和有損壓縮率。 與 PNG 相比，它的尺寸通常小 26%，比同類 JPEG 圖像小 25-34% - 源。
當一個擴展由多個供應商實現時，其名稱可以使用保留的 EXT 前綴。 Khronos IP 框架通常不涵蓋多供應商擴展，但有一些值得注意的例外情況（上面列出）在 EXT 前綴下廣泛使用后已經通過了 Khronos 批準過程。
EXT_lights_ies擴展允許使用 IES 燈光配置文件作為場景內的光源。 IES 光輪廓使用來自光源的真實測量數據來描述光的分布。
許多 3D 工具和引擎都支持 IES 燈光配置文件。 使用此擴展，工具可以導出，引擎可以導入包含 IES 燈光配置文件描述的燈光的場景。
燈光配置由節點引用并繼承該節點的變換。 它們描述場景內的點光源。 這些光源被定義為參數化的無限小點，它們以角度變化的強度向各個方向發射光。
此擴展的一致實現必須能夠加載資源中定義的燈光配置文件并使用這些燈光渲染資源。 需要支持以下 IES 光配置標準：IES LM-63-95、ANSI/IESNA LM-63-02 和 ANSI/IES LM-63-19。 實施必須支持 B 型和 C 型光度測定的光配置文件。 對 A 型光度測定的光配置文件的支持是可選的。 請參閱實現細節，了解不需要的字段列表以及上述標準版本之間的相關差異的描述。
EXT_lights_image_based擴展提供了在 glTF 場景中定義基于圖像的燈光的能力。 基于圖像的燈光由環境圖組成，該環境圖表示場景的鏡面反射亮度以及輻照度信息。
許多 3D 工具和引擎支持基于圖像的全局照明，但所采用的具體技術和數據格式各不相同。 使用此擴展，工具可以導出，引擎可以導入基于圖像的燈光，并且結果應該高度一致。
此擴展精確指定了一種格式化和引用要使用的環境貼圖的方法。 這樣做的目標有兩個。 首先，它使得實現對此擴展的支持變得更加容易。 其次，它確保基于圖像的照明的渲染在運行時保持一致。
此擴展的一致實現必須能夠加載基于圖像的環境數據并使用此照明渲染 PBR 材質。
供應商前綴列表維護在 Prefixes.md 中。 任何供應商（不僅僅是 Khronos 成員）都可以通過在 GitHub 上提交問題來請求擴展前綴。 請求應包括：
Khronos IP 框架不涵蓋供應商擴展。
ADOBE_materials_clearcoat_specular擴展定義了一種控制 KHR_materials_clearcoat 擴展提供的透明涂層的折射率 (IOR) 和鏡面 F0 的方法。 這會覆蓋透明涂層的默認 IOR（1.5），并且還提供了一種調制 F0 反射率的方法。 這與 KHR_materials_ior 和 KHR_materials_specular 擴展一起修改 F0 反射率的方式完全相同。
許多光學透明材料無法用核心 glTF 2.0 PBR 材料以物理上合理的方式表示。 Alpha 覆蓋（通過 baseColorTexture 的 Alpha 通道暴露）對于不反射、折射、吸收或散射光的透明材質（例如紗布）很有用。 然而，大多數物理材料不屬于這一類。 透明玻璃和塑料就是很好的例子。 在最簡單的情況下，玻璃表面的鏡面反射在完全透明的網格上仍然可見。 使用 0% 的 Alpha 覆蓋率也會使反射不可見。
ADOBE_materials_thin_transparency擴展旨在解決光學透明度最簡單和最常見的用例：沒有復雜散射（例如動態散射）或色散的薄材料。 專門處理“薄”材料（即僅考慮表面而不考慮體積的材料）可以在計算折射和吸收等內容時進行許多簡化。
AGI_articulations擴展用于定義模型上所有可移動節點的自由度的名稱和范圍。
在 glTF 2.0 中，核心動畫系統面向典型的圖形行業使用模式，其中模型作者在創作時決定模型的哪些部分將移動，以及這些移動的確切性質和時間安排。 它不允許模型的某些部分被作者指定為可移動的情況，但它們的確切運動直到模型構建之后才知道。
例如，想象一下機動支架上的無線電碟形天線的情況。 構建模型時，模型作者可能知道碟形天線可以指向某些方向，但可能不知道（直到碟形天線被積極使用）它在任何給定時間指向哪里。 該碟形天線的 glTF 模型需要指出可用運動的名稱和限制，但該模型不包含要執行的實際運動序列，這可能要等到運行時或碟子運行時的實時模擬才能知道。
在這種情況下，我們說模型是可以鉸接（articulated）的，我們需要鉸接來定義模型上所有可移動節點的允許運動（自由度）的名稱和范圍。 如果需要，將關節應用到節點并不排除將 glTF 核心動畫應用到同一節點。 實現可以自由選擇如何以及何時運用可用的關節，并且預計該信息將位于 glTF 文件的外部（否則它可以簡單地編碼為動畫）。
AGI_stk_metadata擴展向 glTF 模型添加了額外的元數據。 這些元數據旨在與 Analytical Graphics, Inc. 生產的產品 STK（系統工具包）的現有功能進行 1:1 匹配。
非真實感 3D 對象（例如無紋理的建筑物）在勾勒出其邊緣時通常更具視覺吸引力。 向 glTF 模型添加輪廓的一個簡單方法是向模型添加 LINES 類型的附加基元，沿著要輪廓的邊緣繪制線條。 不幸的是，這種方法的視覺質量相當差，因為線條深度與三角形相沖突。 線條的光柵化與三角形邊緣的光柵化不匹配。
單獨渲染的線條和三角形之間的深度沖突
避免這種深度沖突的傳統方法是使用 glPolygonOffset 或類似的方法。 然而，glTF 2.0 不支持指定多邊形偏移。 即使它確實如此 - 或者定義了擴展來支持它 - 使用這種方法也很難獲得高質量的渲染。 根據所選的多邊形偏移值，由于深度偏差太大，背面上的線條可能會“滲透”到正面，或者由于深度偏差太小，線條可能會呈現點狀外觀。 即使仔細調整多邊形偏移值，通常也可以在單個場景中同時檢測到兩個問題。
即使這些偽影被認為是可以容忍的，渲染單獨的線圖元也會增加渲染場景所需的繪制調用數量。 此外，在某些硬件上，繪制線條比繪制三角形要慢得多。
CESIUM_primitive_outline擴展向渲染引擎指示應勾勒出三角形邊的列表。 雖然它沒有規定應該如何完成渲染，但所有線條實際上都是三角形的邊緣這一事實允許渲染引擎使用更高質量和更快的技術來渲染線條，而無需推斷出這種技術在運行時的適用性。
FB_geometry_metadata擴展通過場景關聯場景圖的累積幾何復雜性和場景空間范圍的摘要來注釋 glTF 場景對象。 每個遞歸引用的網格都會被枚舉以獲得總頂點和圖元計數，并且每個單獨的頂點都會被轉換到場景空間中以獲得完美計算的邊界框。
此信息的一些經過驗證的實際應用：
2. 當服務器端系統需要根據幾何復雜性做出決策，并且不想包含自己的復雜矩陣/向量代碼時。
glTF 中的訪問器定義存儲在通過 bufferView 查看的緩沖區中的數據的類型和布局。 當從緩沖區讀取定時數據時，緩沖區中的數據可能隨時間動態變化。
包含定時媒體和/或元數據的場景應利用MPEG_accessor_timed定時訪問器擴展來描述對動態變化數據的訪問。 MPEG_accessor_timed 是常規訪問器的擴展，用于指示底層數據緩沖區是動態的。 請注意，定時訪問器有兩個 bufferView，一個從包含訪問器繼承，另一個在 MPEG_accessor_timed 擴展中。 前者用于引用定時媒體數據。 后者可用于指向動態緩沖區標頭，該標頭可能存在也可能不存在。 當存在時，兩個 bufferView 應指向同一個循環緩沖區。
具有 MPEG_accessor_timed 擴展的訪問器中的 accessor.bufferView 字段以及定時訪問器信息頭字段適用于循環緩沖區內每個幀的數據。
定時訪問器擴展由 MPEG_accessor_timed 標識。
MPEG_animation_timing 擴展支持媒體時間線和 glTF 2.0 定義的動畫時間線之間的對齊。 使用擴展可以創建講述的故事。 動畫計時元數據可以允許同時暫停和對 glTF 2.0 和媒體中定義的動畫進行其他操作。
MPEG_audio_spatial 擴展添加了對空間音頻的支持，它可以包含在頂層或附加到場景中的任何節點。
為了支持定時數據訪問，緩沖器元件被擴展以提供循環緩沖器的功能。 MPEG_buffer_circular 擴展可以被包括作為緩沖器的一部分。 提供對定時數據的訪問的緩沖區應包括 MPEG_buffer_circular 擴展。
MPEG_media 提供了 glTF 文檔中其他擴展引用的 MPEG 媒體項數組。
MPEG_mesh_linking 擴展提供了將一個網格鏈接到 glTF 資源中的另一個網格的可能性。
陰影網格對應于 glTF 2.0 定義的常規網格數據，不帶 MPEG_mesh_linking 擴展。 依賴網格可以通過依賴陰影網格來進行變換/動畫。 包含在從屬網格中的 MPEG_mesh_linking 擴展鏈接從屬網格和陰影網格，并提供用于實現對從屬網格進行動畫處理的能力的數據和信息。 因此，陰影網格存在于 glTF 資源中，以幫助實現將變換應用到從屬網格上的能力。
MPEG_scene_dynamic擴展鏈接。
MPEG_texture_video 擴展提供了將 glTF 2.0 中定義的紋理對象鏈接到媒體及其相應軌道（由 MPEG_media 列出）的可能性。 MPEG_texture_video 擴展還提供對定時訪問器的引用，即具有 MPEG_accessor_timed 擴展的訪問器，其中解碼的定時紋理將可用。
當不支持 MPEG_texture_video 擴展時，紋理緩沖區應由標準 glTF 源對象描述的數據填充。
MPEG_viewport_recommished 擴展通過引用定時訪問器提供從 glTF 2.0 中定義的相機對象到推薦視口信息的鏈接，其中推薦視口信息的樣本將可用。
推薦的視口信息提供動態變化的信息，包括包含相機對象的節點的平移和旋轉，以及相機對象的固有相機參數。 客戶端根據動態變化的信息來渲染視口。
注意：實現推薦視口的另一種方法是為帶有附加相機的節點定義動畫。 然而，該方法不支持動態更改內部相機，并且必須在創建 glTF 對象期間定義。
MSFT_lod 擴展添加了為 glTF 資源指定各種細節級別 (LOD) 的功能。 此擴展的實現可以將 LOD 用于各種場景，例如根據對象的距離渲染不同的 LOD，或者從最低的 LOD 開始逐步加載 glTF 資源。
此擴展允許在幾何節點或材料級別定義 LOD。 節點 LOD 可以跨不同級別指定不同的幾何體和材料，而材料 LOD 可以為相同的幾何體指定不同的材料。
MSFT_lod 擴展被添加到最高 LOD 級別。 擴展定義了一個 ids 屬性，它是一個包含較低 LOD 級別索引的數組。 數組中的每個值都指向質量低于前一級別的 LOD 級別。 例如，如果擴展是在節點級別定義的，則具有擴展的節點對象是最高 LOD 級別。 擴展的 ids 數組中指定的每個值都指向另一個節點對象的索引，該節點對象應用作較低的 LOD 級別。
此擴展的實現可以解析 ids 數組以創建可用于資產的 LOD 級別列表。 如果包含此擴展的資源加載到未實現該擴展的客戶端中，則將加載最高的 LOD 級別，并忽略所有較低的 LOD。
MSFT_packing_normalRoughnessMetallic擴展增加了對備用紋理打包的支持，旨在用于 Windows Mixed Reality Home 和 Windows Mixed Reality 的 3D 啟動器。
此擴展定義了 normalRoughnessMetallicTexture 的附加屬性。 此屬性指定具有包裝法線 (RG)、粗糙度 (B)、金屬 (A) 的紋理的索引。 這種專門的包裝旨在為核心 glTF 2.0 規范中指定的包裝提供一種優化的替代方案。
該擴展僅應在為支持此打包的引擎創建 glTF 資產時使用，而不是通用的打包擴展。 任何不支持此擴展的客戶端都可以安全地忽略這些額外的打包紋理并依賴于 glTF 2.0 中的默認打包。 此擴展還可以與其他擴展（例如 MSFT_texture_dds）一起使用，以將打包紋理存儲在 DDS 文件中。
MSFT_packing_occlusionRoughnessMetallic擴展增加了對備用紋理打包的支持，旨在用于 Windows Mixed Reality Home 和 Windows Mixed Reality 的 3D 啟動器。
此擴展定義了三個附加屬性：
該擴展僅應在為支持此打包的引擎創建 glTF 資源時使用，而不是通用的打包擴展。 任何不支持此擴展的客戶端都可以安全地忽略這些額外的打包紋理并依賴 glTF 2.0 中的默認打包。 此擴展還可以與其他擴展（例如 MSFT_texture_dds）一起使用，以將打包紋理存儲在 DDS 文件中。
MSFT_texture_dds擴展添加了使用 DirectDraw Surface 文件格式 (DDS) 指定紋理的功能。 此擴展的實現可以使用 DDS 文件中提供的紋理作為 glTF 2.0 中可用的 PNG 或 JPG 紋理的替代方案。
該擴展名被添加到紋理節點并指定一個指向圖像節點索引的源屬性，該索引又指向 DDS 紋理文件。 不理解此擴展名的客戶端可以忽略 DDS 文件并繼續依賴指定的 PNG 或 JPG 紋理。
NV_materials_mdl擴展提供了在 glTF 資源中存儲和傳輸材質的能力，這些資源是在 NVIDIA 材質定義語言 (MDL) 中定義的，如 MDL 語言規范中所定義。 此擴展的目的是除了標準 glTF 2.0 PBR 模型之外，還可以在 glTF 中為支持 MDL 的應用程序和渲染器提供高質量的材質定義。
MDL 材料在 MDL 模塊中定義，這些模塊存儲在文件擴展名為 .mdl 的文件中。 對 .mdl 文件的引用在一致實現的配置上下文中解析，特別是使用 MDL 語言規范附錄 F 中記錄的搜索路徑。 作為替代方案，MDL 模塊也可以嵌入到資產中。 MDL 材質可以接受紋理和其他資源作為輸入參數。 此擴展使用 JPG 和 PNG 紋理的核心 glTF 2.0 標準中的圖像。 此外，如果使用此擴展，圖像對象還可以分別使用 image/x-exr 和 application/x-vdb 媒體類型引用 EXR 和 VDB 資源。 EXT_lights_ies 擴展用于 IES 燈光輪廓，MDL 語言規范附錄 B 中定義的 MBSDF 各向同性測量 BSDF 數據是此擴展的一部分。
此擴展的一致實現必須能夠加載引用的 MDL 模塊，驗證引用的函數調用和用戶定義的類型在這些 MDL 模塊中具有兼容的定義，并在引用的材質綁定中使用這些函數來渲染網格 相應的 MDL 材料代替標準 glTF PBR 材料。 通過檢查帶有類型參數的調用是否找到匹配的函數定義（包括 MDL 語言規范第 12.4 節中定義的重載解析）來針對 MDL 模塊驗證函數調用。 通過檢查 MDL 模塊中相應類型的所有字段或枚舉值是否存在，針對 MDL 模塊驗證用戶定義類型。
由于 MDL 材質取代了標準 glTF 材質，因此強烈建議創作應用程序還在 MDL 材質旁邊提供緊密匹配的標準 glTF PBR 材質，以便不理解此擴展的實現仍然可以顯示此 glTF 文件的代表性渲染 。 然而，定義后備材料是可選的。 最佳實踐部分提供了有關此問題的更多詳細信息。
MDL 材質是通過返回內置類型材質的語言中的函數來定義的。 此擴展對引用的 MDL 模塊中定義的函數的函數調用進行操作。 這些函數調用在 functionCalls 數組屬性中定義，該屬性在頂級 NV_materials_mdl 擴展對象中定義。 函數調用和類型引用的模塊在modules 數組中定義。 最后，BSDF 測量資源在 bsdfMeasurements 數組中定義。
存檔的擴展名對于讀取較舊的 glTF 文件可能很有用，但不再建議使用它們來創建新文件。
KHR_materials_pbrSpecularGlossiness擴展定義了基于物理的渲染 (PBR) 的鏡面光澤度材質模型。 此擴展允許 glTF 支持此附加工作流程。
KHR_techniques_webgl擴展允許 glTF 使用外部著色器程序及其參數化值定義著色技術的實例。 著色技術使用 JSON 屬性來描述 GLSL 頂點和片段著色器程序的數據類型和語義。
此擴展規范針對 WebGL 1.0，并且如果設備支持必要的 WebGL 擴展，則可以在任何基于 WebGL 1.0 的引擎中受支持。
KHR_xmp擴展向 glTF 添加了對 XMP（可擴展元數據平臺）(ISO 16684-1) 元數據的支持。 元數據用于傳輸有關 glTF 資產的信息（例如歸屬、許可、創建日期）。 元數據對 glTF 資源外觀和渲染沒有規范影響。
XMP 是一種將元數據嵌入到文檔中的技術，自 2012 年以來一直是 ISO 標準。XMP 數據模型的一個實例稱為 XMP 數據包 (ISO 16684-1.1)。 XMP 元數據作為元數據包數組嵌入到頂級 glTF 擴展中。 然后可以從以下類型的 glTF 對象引用 XMP 元數據包：資產、場景、節點、網格、材質、圖像、動畫。 glTF 頂級對象資產引用的 XMP 元數據適用于整個 glTF 資產。 XMP 元數據按命名空間組織 (ISO 16684-1.2)。
此擴展允許將任何 XMP 元數據命名空間嵌入到 glTF 資產中。
Khronos (KHR) 延期草案尚未獲得批準。 多供應商 (EXT) 擴展不需要批準，但在完成之前仍可能發生變化。
本節跟蹤 Khronos 和多供應商擴展的狀態，這些擴展要么已經在開發中，要么我們認為表現出足夠的共識，極有可能用于未來的開發。 我們歡迎對這些以及所有其他擴展提供反饋（請參閱 GitHub 問題）。 該列表旨在提供當前優先事項和方向的總體了解。
對于此處未列出但可能對不同用途很重要的功能，我們鼓勵社區從供應商擴展（不需要審核）開始，尋求反饋和合作者，作為共識形式，我們可能會考慮最好的方法 將供應商擴展引入更廣泛的生態系統：通過多供應商擴展、Khronos 擴展或包含在 glTF 規范的未來版本中。
擴展 | 狀態 |
KHR_animation_pointer | 準備測試 |
KHR_audio | 準備測試 |
KHR_materials_diffuse_transmission | 準備測試 |
KHR_materials_sss | 正在開發中 |
原文鏈接：http://www.bimant.com/blog/gltf-extensions-ultimate-guide/