泉州专业网站制作定制,南京网站搜索排名,成都建设网站的,网站的维护和推广其他脚本语言也可以热更新#xff0c;但 Lua 特别适合#xff0c;游戏主程序通常是 C#xff0c;Lua 只是逻辑脚本#xff0c;改 Lua 不影响主程序运行
语言应用场景PythonWeb 后端 / 数据处理服务JavaScript浏览器端热重载 / React HMRC#Unity 的 ILRuntime / HybridCLR …其他脚本语言也可以热更新但 Lua 特别适合游戏主程序通常是 CLua 只是逻辑脚本改 Lua 不影响主程序运行
语言应用场景PythonWeb 后端 / 数据处理服务JavaScript浏览器端热重载 / React HMRC#Unity 的 ILRuntime / HybridCLR 实现 DLL 热更新TypeScript前端构建工具支持热替换WASM支持在不重启主进程的前提下动态替换模块
框架特点XLuaUnity支持 Lua 脚本与 C# 混合调用Tolua早期流行框架适配 UnityCocos2d-x Lua天然支持热更新如 loadstring、requireSkynet服务级热更新服务器端框架
XLua 是 Unity 官方推荐的 Lua 热更新解决方案 它允许你在 Unity 项目中使用 Lua 脚本写逻辑并在运行时替换、更新这些逻辑而不重新打包整个程序。 你可以写 C# 脚本Unity 编译器会把它们 编译成 DLL然后随游戏一起打包发布。 但是这些 DLL 是 不能在运行后更换的尤其是用 IL2CPP 发布后代码会被转成 C 编译成二进制
文件能否在运行时执行原因.csC# 脚本❌ 不行要编译成 DLL运行时不能改.luaLua 脚本✅ 可以Lua 是脚本语言由运行时解释器解释执行.jsUnityScript✅/❌已废弃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文本向量化将所有笔记内容编码入一个向量数据库 你提问时通过语义相似度找到相关笔记片段再由模型生成最终回答 这是典型的“RAGRetrieval-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-pnucleus sampling、temperature 会影响下一个词的选择是否更“保守”或更“发散” 这部分可以固定设定 temperature0 表示 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, size500, overlap100)for chunk in chunks:vector embedding_model.encode(chunk)store_in_vector_db(vector, metadata{source: file})第 3 步提问时检索相关段落 输入模型 当你问问题时系统先找出最接近你问题的文本片段再和你的问题一起发给语言模型 所以最终表现是 模型本身不记得资料内容但它每次回答前都“临时借用”你给的资料内容来判断。 每次回答都等价于你给它说“你看一下这些段落帮我回答这个问题。” 这个过程会自动进行但你需要先把资料转换好预处理阶段
❓那你说的“之后回答的时候就按照这个来”是不是只要文件放进去就行
不是自动的你必须手动做一次预处理但可以自动化
操作是否自动遍历 text 文件夹✅ 可以自动分段处理✅ 可以设定 chunk 大小向量化文本✅ 用本地 embedding 模型构建索引库✅ 一次性构建后反复使用问题→相似段落→模型回答✅ 每次对话中自动运行 截止训练数据时间点Unity 2022 LTSLong-Term Support 是主要参考版本。 核心 API 覆盖范围Unity 20182022包含大量关于 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.32022.3 为主URP/HDRP 较稳定阶段。 Shift 空格Shift Space最大化 你提到的设置项实际设置项是否存在 / 替代方案Surface: Transparent✅ 已存在Surface Type → TransparentAlpha Clipping: Off✅ 存在Alpha Clipping 复选框未选中ZWrite: Off✅ 可通过 Depth Write → Auto / Off 控制Blend: Alpha✅ 存在Blending Mode → AlphaTwo 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 KWindows 调出 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 和 AlphaAlpha 值自动随时间衰减。 如果你现在连线中用了 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 LightRim 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 本地化、界面配置、材质预设等资源文件 ❓需要安装 VC 运行库吗 是的推荐先安装你上面贴的 VC 运行库合集尤其是 VC 2010PmxEditor 是 C# C 混合开发的 VC 2013 和 VC 2015部分 DLL 插件也可能依赖 如果你不装运行库可能会遇到 ❌ 启动直接闪退无提示 ❌ 报错缺失 MSVCP*.dll 或 .NET Framework 组件 ❌ 插件无法加载、无法导出 .pmx
【动作配布】甘雨·杰克逊_哔哩哔哩_bilibili mikudance简单接触
