自由學習記錄（65）

其他腳本語言也可以熱更新，但 Lua 特別適合，游戲主程序通常是 C++，Lua 只是邏輯腳本，改 Lua 不影響主程序運行

語言	應用場景
Python	Web 后端 / 數據處理服務
JavaScript	瀏覽器端熱重載 / React HMR
C#	Unity 的 ILRuntime / HybridCLR 實現 DLL 熱更新
TypeScript	前端構建工具支持熱替換
WASM	支持在不重啟主進程的前提下動態替換模塊

框架	特點
XLua（Unity）	支持 Lua 腳本與 C# 混合調用
Tolua	早期流行框架，適配 Unity
Cocos2d-x Lua	天然支持熱更新（如 loadstring、require）
Skynet	服務級熱更新（服務器端框架）

XLua 是 Unity 官方推薦的 Lua 熱更新解決方案，
它允許你在 Unity 項目中使用 Lua 腳本寫邏輯，并在運行時替換、更新這些邏輯而不重新打包整個程序。

你可以寫 C# 腳本，Unity 編譯器會把它們 編譯成 DLL，然后隨游戲一起打包發布。
但是這些 DLL 是 不能在運行后更換的（尤其是用 IL2CPP 發布后，代碼會被轉成 C++ 編譯成二進制）

文件	能否在運行時執行	原因
`.cs`（C# 腳本）	? 不行	要編譯成 DLL，運行時不能改
`.lua`（Lua 腳本）	? 可以	Lua 是腳本語言，由運行時解釋器解釋執行
`.js`（UnityScript）	?/?（已廢棄）	Unity 原生早期支持，后來移除
`.py`、`.ts` 等	? 不行	Unity 無內建解釋器，需自己嵌入

所以在 Unity 中，Lua 是特地“嵌入”的解釋器環境，類似你在游戲內裝了一個“小電腦”來讀 .lua 腳本文件。

熱更新 ≠ 必須聯網,熱更新只意味著：“你可以在運行時用新的邏輯代碼替換舊邏輯，而不是必須重新打包游戲。”

【例：聯網游戲】

玩家打開游戲 → 發現服務器上有新版本的 skill_logic.lua
游戲自動下載覆蓋舊腳本
新技能邏輯立刻生效，不用重啟或重裝游戲
? 熱更新起作用

但熱更新只有在游戲有聯網機制、支持下載新 Lua 腳本時才有“更新”的實際效果。

哪怕是單機：

使用 Lua 腳本仍然可以讓邏輯更靈活（比如任務邏輯、關卡行為可以寫在 Lua 里）
你仍可以在不同版本中方便地換腳本，不必全局改 C# 和重新打包

假設你開發了一個單機游戲，打包之后放在某個平臺上供人下載。玩家下載之后完全斷網。

? 情況 A：游戲只是用了 Lua，但不打算更新

你在開發階段就把很多邏輯寫在 Lua 腳本里（比如關卡配置、敵人 AI）
這些 Lua 文件被打包進安裝包中
游戲運行時，Lua 虛擬機會加載并執行這些腳本

👉 這種只是運行時使用 Lua 腳本，不叫熱更新。

? 情況 B：游戲打包時內置了備用腳本機制

雖然斷網，但你設計了一個“插件目錄”或“本地腳本讀取路徑”
玩家或開發者可以手動替換這些 Lua 文件
游戲運行時會讀取外部的 Lua 腳本而不是打包內的

👉 這種屬于本地熱更新（不依賴網絡，但仍可更新邏輯）

對比項	Lua 腳本	C# 代碼（Unity 環境）
執行方式	解釋執行（通過虛擬機）	編譯成 IL，再由 Mono/IL2CPP 運行
文件是否可直接編輯	? 是文本，可隨時改	? 編譯后為 DLL，不可直接改
是否可脫離主程序更新	? 熱替換，加載新腳本	? 更新必須重打包或特殊框架支持
運行開銷	很小，輕量	稍重（尤其在移動平臺）
熱更新難度	低	高，需要專門的反射或動態加載機制

NotebookLM 處理鏈接的原理是“抓取單一頁面的 HTML 文本結構 + 語義索引分段提問”，它不支持自動抓取整個網站或跳轉鏈接的子頁面。

NotebookLM 是如何處理你傳入的鏈接內容的？

? 1. 抓取網頁內容（HTML）并轉成純文本結構

NotebookLM 在你添加一個鏈接（如 Unity 官方文檔）后，會嘗試：

抓取該鏈接的網頁源代碼（HTML）
使用網頁解析器（如 Readability、或自研 parser）將主要正文內容提取成 Markdown / 文本塊
忽略頁面上的導航欄、頁腳、廣告、腳本等無關內容

? 它不會只是截圖，而是真正讀取文字內容構建“筆記”塊（Source Note）

NotebookLM 的語義索引機制

抓取完文本內容后，它會：

對內容進行分段（chunking），每個段落成為一個“Note”（筆記源）
使用 embedding（文本向量化）將所有筆記內容編碼入一個向量數據庫
你提問時，通過語義相似度找到相關筆記片段，再由模型生成最終回答

📌 這是典型的“RAG（Retrieval-Augmented Generation）”機制

不推薦直接保存 HTML 的情況

有些網頁（尤其是 React/Vue/Angular 構建的 SPA，比如 Unity 腳本 API 頁面）用的是JavaScript 動態渲染，所以：

如果你用右鍵「保存為 .html」，保存下來的只是一個殼，正文根本沒在里面
NotebookLM 加載后幾乎是空的，或抓到大量 JS、空 div

🧪 測試方法：

把你保存下來的 HTML 文件用 VSCode 或記事本打開，搜索頁面正文里的句子：

如果找不到，說明你保存的只是網頁殼；
如果找得到，那這份 HTML 文件可以上傳。

Google Slides

指的是 Google 幻燈片（PPT）。
如果你用 Slides 做了學習總結、圖示流程，也可以導入。
NotebookLM 會將每頁幻燈片的文本提取出來，作為知識塊。

是的，本地部署 AI 模型的核心用途之一，就是：

? 讓 AI 像 NotebookLM 一樣，基于你自己的資料、文件、知識庫進行提問和對話。

這其實是構建 RAG 系統（Retrieval-Augmented Generation），它和 NotebookLM 背后的原理基本一致，只不過：

項目	NotebookLM	本地 AI 部署
數據來源	Google Docs / Slides / 鏈接	你本地的 PDF、HTML、TXT、數據庫等
模型調用	Google 的 Gemini 模型	你選擇的模型（如 Llama3、Mistral）
數據存儲	云端	全部在你電腦或局域網
權限和隱私	Google 控制	你完全掌控

果你要自己做一個“本地 NotebookLM”，你需要這些東西：

1. 大模型（LLM）本地推理能力

推薦模型：LLaMA 3 (Meta)、Mistral 7B、Qwen、Yi
推薦框架：llama.cpp、Ollama（最簡易）或 vllm

2. 文檔解析與嵌入（Embedding）工具

工具：langchain, llama-index
功能：將 HTML / PDF 分段、轉為向量、構建索引數據庫

3. 向量數據庫（存放你的知識庫）

推薦：Chroma, FAISS, Weaviate（輕量開源）

4. 對話界面（Web UI）

簡易：text-generation-webui, Open WebUI, LM Studio
復雜：你可以自己寫一個界面，或集成進 VS Code、網頁等

DeepSeek、LLaMA、Mistral 這類模型的 推理代碼 + 權重文件 都可以本地完整下載，運行時無需聯網。

所需組件都可以脫網運行：

組件	是否可本地使用	說明
模型參數（權重）	?	是 `.bin` 或 `.gguf` 等格式的矩陣數據，存儲的是“知識”
Tokenizer	?	是文本轉 ID 的規則集，通常是 `tokenizer.json` 文件
推理邏輯（前向計算）	?	例如 transformer block 的執行流程，已寫死在推理引擎中
向量檢索（RAG）部分	?	可用本地 `ChromaDB`、`FAISS` 等做離線知識檢索

推理 = 權重矩陣 + 編碼向量 + 固定執行邏輯

一個大語言模型（如 DeepSeek）推理時的核心步驟：

文本輸入 → 分詞（Tokenizer）→ 編碼為向量（Embedding） ?
→ 一層層 Transformer block 運算（矩陣相乘 + 激活） ?
→ 輸出下一個詞的概率分布

在這個過程中：

權重（Weight）：
- 是模型的“知識”，本質上是幾百億個數字矩陣。
- 你下載的 .gguf 或 .safetensors 文件就是這些權重。
- 是訓練時學到的所有語言、邏輯、人類知識的載體。
推理邏輯（代碼）：
- 是程序中寫死的算法，比如：Multi-head Attention、LayerNorm、MLP 等。
- 所有模型結構都是固定的，都是前向傳播（forward pass），不涉及訓練。
輸入向量（Prompt）：
- 是你給模型的提示，會影響其如何“激活”內部知識。

輸入的詞（prompt）不同，經過同樣的邏輯，會激活不同的權重組合

同一個模型，對“貓”和“太陽能電池板”會走出完全不同的語義路徑

采樣策略會變化（也可以固定）

常見策略：
- Top-k、Top-p（nucleus sampling）、temperature
會影響下一個詞的選擇（是否更“保守”或更“發散”）
這部分可以固定（設定 temperature=0 表示 deterministic 推理）

本地部署的 AI 模型有“兩套知識來源”

來源	內容	控制方式
? 模型自身的知識	模型訓練階段學到的世界知識（百科常識、編程技能、英語表達、物理知識等）	不能修改，存在于參數（權重）中
? 你的私有資料（文檔）	你上傳的 HTML / PDF / 筆記等內容，作為問答參考	可控，可更新，可刪除

默認情況下，網站GPT 回答問題是基于它自身知識庫

也就是你說的這部分：

“不開聯網搜索，其實和本地部署一樣，靠的是原本的訓練知識。”

具體表現：

場景	是否聯網搜索	知識來源
GPT-3.5 / GPT-4（無插件、無瀏覽器）	? 不聯網	只基于模型權重內的“世界知識”
GPT-4（瀏覽器/插件打開）	? 聯網檢索	部分信息來自網絡（會標注來源）

所以：你在官網用 GPT 問技術問題，如果沒開啟聯網，它和本地模型在“機制”上完全一致：都靠權重本身的記憶

這種默認模式等于 非-RAG 模式

RAG 模式 = 檢索+補腦，可以額外喂內容

模型本身不會“自動記住”你文件夾里的內容

你即使有 100 個文本文件放在模型旁邊，模型也不會自動讀取它們。

文本資料轉為“可查詢知識”的三步過程

這就是構建一個資料庫的標準做法：

🔹 第 1 步：加載文本內容

用程序（如 langchain / llama-index / haystack）遍歷文件夾中的所有 .txt 文件。

for file in all_txt_files:content = open(file).read()

🔹 第 2 步：分段（chunking）+ 嵌入（embedding）成向量

將每個文檔按段落/長度切塊，然后對每段文本編碼成一個“向量表示”

chunks = split_into_chunks(content, size=500, overlap=100)for chunk in chunks:vector = embedding_model.encode(chunk)store_in_vector_db(vector, metadata={source: file})

🔹 第 3 步：提問時檢索相關段落 + 輸入模型

當你問問題時，系統先找出最接近你問題的文本片段，再和你的問題一起發給語言模型

🔄 所以最終表現是：

模型本身不記得資料內容，但它每次回答前都“臨時借用”你給的資料內容來判斷。
每次回答都等價于你給它說：“你看一下這些段落，幫我回答這個問題。”
這個過程會自動進行，但你需要先把資料轉換好（預處理階段）

?那你說的“之后回答的時候就按照這個來”，是不是只要文件放進去就行？

不是自動的，你必須手動做一次預處理（但可以自動化）：

操作	是否自動
遍歷 text 文件夾	? 可以自動
分段處理	? 可以設定 chunk 大小
向量化文本	? 用本地 embedding 模型
構建索引庫	? 一次性構建后反復使用
問題→相似段落→模型回答	? 每次對話中自動運行

截止訓練數據時間點：Unity 2022 LTS（Long-Term Support） 是主要參考版本。
核心 API 覆蓋范圍：Unity 2018～2022，包含大量關于 Editor, MonoBehaviour, ScriptableObject, Shader, URP/HDRP, AssetDatabase, SceneManagement, SerializedObject, Gizmos 等。
Unity 的 API 向后兼容性較好，因此對舊版本（如 2019）也廣泛適用。

我能回答的問題包括但不限于：

編輯器快捷操作（如拖拽材質、添加組件、移動物體）；
Editor 工具編寫；
使用 MenuItem, EditorGUILayout, Selection, Undo.RecordObject 等；
渲染管線（如切換 URP、使用 ShaderGraph）；
常見項目組織和資源結構（Assets/Scenes/Prefabs 等）。

我熟悉的主要渲染架構：

內置渲染管線（Built-in Render Pipeline）
通用渲染管線（URP）
高清渲染管線（HDRP）

支持的版本以 Unity 2019.3～2022.3 為主（URP/HDRP 較穩定階段）。

Shift + 空格（Shift + Space）最大化

你提到的設置項	實際設置項是否存在 / 替代方案
Surface: Transparent	? 已存在，Surface Type → Transparent
Alpha Clipping: Off	? 存在，Alpha Clipping 復選框未選中
ZWrite: Off	? 可通過 Depth Write → Auto / Off 控制
Blend: Alpha	? 存在，Blending Mode → Alpha
Two Sided: On	? 存在，Render Face → Both

圖中這些設置都是 有效且匹配我描述的那一套配置，只不過在 Unity 新版中，表述方式稍有不同。例如：

ZWrite: Off → 在 Unity Shader Graph 中表述為 Depth Write: Auto，如果你需要強制關閉，改為 Off 即可；
Two Sided: On → 對應 Render Face: Both；
透明效果開啟 → Surface Type: Transparent + Blending Mode: Alpha。

為了實現“胎海流麻”這類半透明拖尾效果而進行的必要設置，它們直接影響透明度渲染、混合方式、遮擋關系和雙面顯示。下面我逐項解釋原因：

? `Surface: Transparent`

目的：允許材質使用透明度（Alpha）通道進行混合。
默認是 Opaque（不透明），這會導致 Alpha 值被忽略。
用于拖尾/氣體/魔法軌跡等帶透明通道的特效材質必須設為 Transparent。

? `Alpha Clipping: Off`

目的：關閉透明裁剪。
如果開啟裁剪，像素的透明度小于閾值就會完全剔除，形成“硬邊界”。
拖尾需要平滑透明漸變，不需要硬邊剔除，所以關閉。

? `ZWrite: Off`

目的：關閉深度寫入，避免透明物體互相遮擋時出現“排序錯亂”。
如果 ZWrite 是 On，透明拖尾會錯誤地遮擋后方物體或自己。
一般透明材質必須禁用 ZWrite，交給渲染隊列排序處理。

? `Blend: Alpha`

目的：使用標準的 SrcAlpha / OneMinusSrcAlpha 混合模式。
保證拖尾色彩與背景融合自然。
是最常見的 標準透明混合 模式（適用于煙霧、水流、光跡等）。

? `Two Sided: On`

目的：渲染模型的背面。
拖尾是片狀或帶狀結構，背面默認不會被渲染，導致在某些角度下“消失”。
開啟雙面可確保從各個角度都看到拖尾。

Ctrl + K（Windows）

調出 Unity 的 Quick Search 窗口（類似 Spotlight 或 VS Code 的 Command Palette）。
可用于快速搜索：
- 項目資源（材質、預制體、腳本等）
- 菜單命令
- 設置項
- 場景對象
- Package 包、幫助文檔等

Unity 的 Quick Search 插件可能需單獨安裝：

打開 Window > Package Manager
找到 Quick Search（或手動添加包 com.unity.quicksearch）
安裝或更新后即可使用快捷鍵 Ctrl + K

xxxxx

“水面融合感增強”

“胎海流麻”這個效果，本質上是一種柔和透明的流動尾跡，往往會：

附著在角色或物體的運動軌跡后方
有一定程度的透明、虛幻、擾動感
看起來像拖曳、擴散、融化，甚至帶有一點“流體”的質感

實現這個“視覺貼地/貼水”感的技術背后邏輯：

渲染策略	實現目的	技術核心
基于深度的透明度調整	讓尾跡在靠近水面時顯現，離開時淡出	`SceneDepth - PixelDepth` 控制透明度
軟邊混合（Soft Blend）	讓邊緣與水面過渡柔和，避免“剪影”感	使用 *`Alpha smoothstep(...)`**
擾動背景法線	讓尾跡拖曳時“壓出水痕”的感覺	用 FlowMap 或擾動法線輸入到 `Normal`
顏色調制	讓尾跡顏色受水面或背景影響	可采樣背景顏色、或者乘以偏藍/偏水的調色
UV 或 FlowMap 流動	表現“尾跡在水面上擴散流動”	用 `time` 或 `flow_uv` 滾動貼圖

你創造的是一種**“光學擬態”：尾跡其實是“掛在半空”的，但你通過視覺邏輯模擬出它正貼著水面自由流動**。

這就是技術美術的價值所在——在不動物理數據的前提下，創造出讓玩家信服的視覺真實感。

角色走過的路徑 → 留下拖尾 → 拖尾前端顏色深，尾端顏色淡
這就需要：

前端頂點顏色 = 白 + 高 Alpha（不透明）

尾端頂點顏色 = 粉藍 + 低 Alpha（慢慢淡出）

而這正好就用 Vertex Color（頂點色）來控制。

🔧 為什么不用 Texture 來代替？
拖尾是運行時生成的動態網格，UV 通常不穩定；

頂點色可以更靈活表達“實時變化”；

更高效，不需要貼圖采樣，適合用于大批量的尾跡系統。

Unity 中拖尾的 Vertex Color 怎么來的？

Unity 的 TrailRenderer 在運行時會自動生成一段 mesh，并且：

? 會為拖尾的每個頂點寫入 Vertex Color（包括 RGB 和 Alpha），Alpha 值自動隨時間衰減。

如果你現在連線中用了 Vertex Color → BaseColor * _TintColor，那說明：

你用 VertexColor.rgb 做了拖尾的顏色控制；
用 VertexColor.a × _TintColor.a 控制透明度漸變，非常合理。

也就是說我Shader里的tintcolor其實是設置拖尾顏色的，而對拖尾顏色的設置，出于uv不穩定的原因，所以使用了頂點顏色來存放設置的顏色，而效果是相同的

最終顏色 = VertexColor.rgb × _TintColor.rgb
最終 Alpha = VertexColor.a × _TintColor.a

（TrailRenderer 不生成 UV，或者 UV 排布隨點數變化）；
即使有，也難以做出漸變 + 時間衰減的同步控制；
頂點色天然適合表達 “隨時間變化”、“路徑上漸變”、“自動衰減” 這些視覺語言。

xxxxxx

還是有點太吃力了，，太多概念都是懵的，

03 反射光_嗶哩嗶哩_bilibili

pow（）就是正片疊底

無腦用phong的vr直接點乘出夾角影響高光結果，blinnphong 是更省性能，但是沒必要

Unity小白的TA之路：6個問題輕松掌握Unity前向渲染_嗶哩嗶哩_bilibili

投影：角色頭部在太陽光下投在地面上的明確影子，是 Shadow。
AO：角色脖子和衣領之間的縫隙，或槍托與背包交接的縫里那一小塊暗部，是 AO。

為什么叫 `_MainTex`，卻不是拿來貼顏色的？

這是因為我們現在這個 Shader 的用途不是“常規的貼圖著色器”，而是：

?? 利用貼圖內容來擾動 UV 和/或 控制透明度 alpha

而這個作用本質上是：

用 FlowMap 的紅綠通道擾動 UV
或者
用噪聲貼圖（灰度圖）來控制 Alpha 的邊緣溶解

所以 Shader Graph 中的 `_MainTex` 實際承擔的職責有兩種可能：

用途	`_MainTex` 應掛什么
🎯 擾動流動（UV 動畫）	FlowMap（紅綠擾動紋理）
🎯 邊緣軟混合	灰度貼圖（圓形漸變、噪聲等）

你可以復用同一個 _MainTex 做兩個作用（比如先擾動 UV，再采樣它來做 Alpha），也可以拆成兩個屬性（比如 _FlowMap 和 _AlphaTex 分開掛）

鏡面高光模型視覺對比

展示了如下高光模型的點光源反射強度圖：

Blinn
Phong
Cook-Torrance
Beckmann
GGX

越往右高光越柔和、拖尾越長，尤其 GGX 是現代 PBR 中的主流微表面分布函數。

常見的漫反射 BRDF 模型

模型名稱	特點說明
Lambert	最基礎的漫反射，反射強度只與入射角余弦有關（能量守恒），不考慮粗糙度
Oren-Nayar	更真實的漫反射模型，考慮了表面微觀粗糙結構，適合模擬粉末類材質
Hanrahan-Krueger	常用于皮膚等次表面散射模型，結合體積散射計算

右側的灰球矩陣顯示了這些模型在不同視角下的明暗表現，說明了不同模型的視覺效果差異。

右下部分：更多 BRDF 模型名錄

這些是更完整的 BRDF 名稱列表，包括：

Blinn-Phong、Phong：經典高光模型
Cook-Torrance、GGX、Beckmann：基于微表面理論的現代模型
Ashikhmin-Shirley、Ward、Kelemen：各類各向異性或物理精度模型
Distribution-BRDF：強調微表面分布項
Halfway Vector Disk：用于優化中間向量計算
albedo pump-up：可能是調節反射率用于藝術控制的技巧

BRDF 結構三要素：

分布函數 D
幾何遮蔽 G
菲涅爾 F
Lambert → Oren-Nayar：從簡單漫反射過渡到考慮粗糙度的高級模型

Phong/Blinn-Phong → Cook-Torrance/GGX：從經典鏡面高光過渡到現代物理模型

🌟 圖中提到的光源類型說明：

中文	英文	說明
主燈光	Key Light	最主要的光源，定義了物體的明暗關系和方向。
反彈光	Bounce Light / Fill Light	從地面或周圍環境反彈上來的弱光，緩解陰影太黑的區域。
反向燈光（KICK Light）	Rim Light / Kick Light	從背后照射出的光，在輪廓邊緣形成高光，增強空間感和材質邊界。
輪廓光	Rim Light（有時也叫 Back Light）	強調角色邊緣或背光區域，幫助從背景中分離角色。

🎯 除了圖中的這些，還有其他常見光類型可搭配使用：

類型	說明
Fill Light（補光）	通常柔和，位于主光對側，緩解陰影對比度。和 Bounce 不同，Fill 是主動設置的光源。
Top Light / Overhead Light	頂光，有時用于模擬太陽直射或棚拍環境中的頂燈。
Ambient Light	環境光，一般是非定向的柔光，用于提供最基本的全局亮度。
Practical Light	劇中光源，比如燈泡、窗戶光等，用于增強真實感和故事氛圍。

三方向的環境光遮罩設置，用法線green通道達成目的

利用法線方向（nDir）在世界空間中的 Y 分量，來模擬三向環境光（上、下、側）

float upMask = max(0.0, nDir.y);         // 朝上的法線：上環境光強度
float downMask = max(0.0, -nDir.y);      // 朝下的法線：下環境光強度
float sideMask = 1.0 - upMask - downMask;// 剩余部分歸為側面（水平向量）
含義說明：
遮罩名	作用區域	原理（nDir.y）
upMask	向上的面（頂面）	nDir.y > 0，越朝上越亮
downMask	向下的面（底面）	nDir.y < 0，越朝下越亮
sideMask	水平面（側面）	剩余權重，用于補充側邊這三者權重之和始終為 1，所以可以安全做加權混合。

🌞 直接光源遮擋（Shadow）——投影

定義：

光線從光源出發，被物體擋住后無法照到表面，形成投影。

特征：

來源是光源方向（Directional / Spot / Point）。
遮擋后完全無光照輸入。
通常是有方向、有邊界、有模糊程度的（軟陰影/硬陰影）。
計算方式有：Shadow Map、Ray Tracing、Voxel Cone Tracing 等。

舉例：

太陽光打過來，被墻擋住形成的地面陰影，就是光源遮擋。

🌫? 環境光遮擋（AO, Ambient Occlusion）

定義：

表面由于自身結構的復雜導致接收不到環境光，形成的遮蔽暗部。

特征：

沒有特定光源方向，是基于周圍空間的開闊程度。
與光源無關，模擬“環境光無法進入的區域”。
常用于增強凹陷、接縫處的真實感。
通常是灰度圖（Ambient Occlusion Map）。

舉例：

沙發與地面交界的縫隙、小洞穴內部、衣服褶皺處的陰暗，就是 AO 提供的效果。

這些模型的資源貼圖都有了之后，這個模型才算是可以使用，所以把模型導入到unity里面，需要先把這些貼圖都得到，然后這個角色就可以去渲染了，渲染的部分和這些貼圖的制作是分開的

xxxxxx

?【技術美術入行作品準備經驗分享】原神角色渲染還原教程_嗶哩嗶哩_bilibili
老師幫大忙了

如果壓縮包里的文件亂碼，要注意先改字符編碼再轉文件

項目	`.fbx`	`.vmd`
用途	游戲/影視通用 3D 格式	MikuMikuDance 的專用動作格式
包含內容	模型、骨骼、動畫、材質等	僅包含骨骼動畫數據
骨骼命名	各不相同，無標準	MMD 有標準命名規則（日文骨骼名）
綁定關系	多種方式（Humanoid/Generic）	限定結構（PMX 模型）

所以你要做的是提取 FBX 動作 → 重定向到 MMD 骨架 → 導出 VMD。

安裝這些組件不會對你之后的軟件產生消極影響。
相反，它們的作用是確保各類軟件能正常運行，尤其是使用 C++ 編寫的程序。

它們的作用是什么？

很多 Windows 軟件都是用 C++ 編寫的，尤其是：

游戲（Unity、Unreal）
工具類軟件（Blender、OBS、各種音視頻軟件）
中間件（驅動、解碼器等）

這些程序在運行時需要依賴「運行時庫」：

就像你寫代碼時需要 .dll，它運行時也需要系統提供這些支持庫。

?? 有無副作用？

可能的疑問	實際情況
會不會導致沖突？	? 不會，每個版本的 VC++ 運行庫是獨立的 Side-by-side 安裝
會不會拖慢系統？	? 不會，它們只在被調用時才會載入，平時完全不影響性能
會不會篡改系統文件？	? 不會，它們是官方安裝包 repack（僅做了合集優化）

這么有用為什么不電腦自帶

Windows 不預裝所有 Visual C++ 運行庫，是為了保持系統精簡、降低維護負擔，并鼓勵開發者自帶依賴。

1. 🔧 每個 VC++ 版本都是獨立產品

Visual C++ 的每個版本（2005、2008、2010、2012…）運行庫并不向前/向后兼容。
比如用 VC++ 2010 編譯的軟件就必須裝 2010 的運行庫，不能用 2015 的替代。
這意味著系統無法預知你未來會用哪個版本的軟件，所以不能預裝所有版本。

2. 🎯 微軟設計哲學：“按需分發”

微軟鼓勵開發者自行打包所需運行庫，比如使用 Installer 安裝時靜默安裝對應 VC++。
這樣可以：
- 避免系統預裝太多版本造成維護冗余
- 保證軟件運行時的版本精確性
所以很多正規軟件（如 Unity 安裝器、游戲大作）都會自動附帶 VC++ 安裝步驟。

3. 💡 Windows 預裝了最常用的核心組件

Windows 確實默認包含了部分運行庫（特別是 VC++ 2015+），但：
- 很多舊版本不再被默認捆綁
- 某些 SP1/SP2 擴展包體積較大，微軟選擇由軟件商分發

4. 📉 不預裝是為了減少系統膨脹與潛在安全攻擊面

每個運行庫版本都含 DLL 和 COM 接口，預裝過多可能：
- 增加維護成本
- 引入舊版本漏洞
- 增加系統攻擊面（DLL 劫持等）

🔄 舉個例子你就懂了：

你下載一個原神 MOD 工具，它是用 VC++ 2008 寫的。Windows 11 沒有預裝 2008，所以你運行時報錯缺少 MSVCR90.dll。

但這并不是 Windows 的錯，而是開發者沒有在安裝包里帶上運行庫安裝器。

? 解決辦法（也是你現在用的）：

安裝「VC++ 運行庫合集」本質上就是為你統一解決了這些“分發責任不清”的歷史遺留問題。

你裝好一遍之后，就能跑 90% 民間工具/舊版游戲/編輯器。

PmxEditor 是專門用于 編輯/修正/導出 MMD 模型 的 GUI 工具。

它可以：

修改模型的頂點、骨骼、表情、材質、物理剛體
替換貼圖 / 調整透明 / 調整描邊
導入/導出 .pmx、.pmd 格式
可用于動作測試、附加插件（.vmd 動作可在 PmxView 中查看）

文件/文件夾名	說明
`PmxEditor.exe`	主程序，32位運行版
`PmxEditor_x64.exe`	主程序，64位運行版（建議用這個）
`.config` 文件	啟動配置參數（比如語言環境）
`readme.docx`	使用說明（通常是日文/英文）
`_plugin/`	插件目錄，比如自動權重、法線修復工具等
`Lib/`	核心運行庫（DLL）所在位置，程序調用的依賴庫
`_data/`	UI 本地化、界面配置、材質預設等資源文件