自由学习记录（138）

• 完整版 ：You are (/ɑːr/)
• 缩写版：You're (/jʊər/ 或更懒的 /jər/)
• 消失的音 ：开头的元音 /ɑː/ 被前面的单词直接"吃掉"了，最后只剩下一个卷舌音 /r/ 挂在前面那个词的屁股后面。

听到 're，美国人的大脑会自动开启两个"频道"：

• 频道 A：正在做 (doing)
  • They're running. (They are running.)
• 频道 B：状态/身份 (adj/noun)
  • We're tired. (We are tired.)
  • You're a genius. (You are a genius.)

虽然听起来简单，但 're 是英语里最著名的**"拼写重灾区"**，美国人自己也经常写错：

• You're (你是) vs. Your (你的)
• They're (他们是) vs. Their (他们的) vs. There (那里)
  在口语里，这几组词的发音几乎一模一样 。所以，美国人不仅听 're 要看上下文，听 your 和 there 也要看上下文。

---

"He's told me they're coming, so I'd better get moving if I'd like to see 'em."

愿、假设或习惯。

• 句子 ：I'd go if I could.
• 还原 ：I would go...
• 判断依据 ：go 是动词原形。

随意的口语（尤其是美语）问句中，'d 甚至可以代表 did：

• "Where'd you go?" = "Where did you go?"

1. 看到 Better 或 Done → Had
2. 看到 Rather 或 Do (原形) → Would
3. 看到 Where/Why + You → Did

you've been working hard,'d love.'re readyey'd bettertell'im

UE 使用 Autodesk FBX SDK 解析 FBX 文件。

FBX 的结构大概是：

FBX Scene
├ Mesh
├ Skeleton
├ Material
├ Animation
├ Node hierarchy

此阶段的数据是 FBX SDK 的对象，不是 UObject。

Autodesk FBX SDK 解析 FBX 文件。

FBX 的结构大概是：

FBX Scene
├ Mesh
├ Skeleton
├ Material
├ Animation
├ Node hierarchy

此阶段的数据是 FBX SDK 的对象，不是 UObject。

Unity 更偏"把 FBX 当一个 Prefab/层级对象来用"。
UE 更偏"把 FBX 拆成资产，再决定要不要还原成 Actor 层级"。 AI → blockout / concept mesh

→ Zbrush / Blender retopo

→ baking → final asset真正做到**"深度 DCC / Engine integration"**的只有极少数（基本只有 Meshy 在认真做）。

其他大多数工具仍然是 Web → FBX/GLB → DCC → Engine 的传统 pipeline。SkeletalMesh 或 Skeleton 时，默认都会实例化同一个 SkeletalMesh Actor，因此表现是一样的。

Skeleton 在 UE 中只是：

• 骨骼层级结构

• bone reference

• animation binding

它 不包含任何几何体。

Skeleton

= bone hierarchy + retarget datawar_PhysicsAsset

≈ Ragdoll 碰撞体配置 + 骨骼刚体/joint 配置

Map / Level 状态（经常忘）

即使你保存了资产，如果 Level 本身有修改，也会提示未保存。

例如：

• 移动 Actor

• 改 Actor 参数

• 新增 Actor

• 删除 Actor

• 改 Light

这些修改存在：

CurrentLevel.umap

如果你只保存了 Blueprint / Material

但 没保存 Map，退出会提示。

保存系统其实是 Package-based，而不是 Project-state-based。FBX 格式其实可以包含图片（贴图） ，但默认情况下，它往往只记录贴图的路径引用 ，而不直接封装图片数据。FBX 文件内仅保存贴图在硬盘上的绝对路径或相对路径 。当你把 FBX 发给别人，但没有同时发送存放贴图的文件夹时，模型就会显示为丢失贴图（通常呈现黑色、紫色或白色）。嵌入模式（包含图片） ：

在导出 FBX 时，大多数三维软件（如 Blender、Maya、3ds Max）都提供一个**"嵌入媒体"（Embed Media）** 或"拷贝贴图"的选项。勾选此选项后，图片数据会被打包进单个 FBX 文件中，文件体积会明显变大，但移动文件时贴图不会丢失 。导出设置的 Path Mode （路径模式）中选择 Copy （复制），并点击旁边的小图标（变亮的箱子图标），这表示将贴图文件打包进 FBX。

Skeleton Editor / Skeletal Mesh Editor 里完成

• 在 mesh 上 放置新的 bone

• 调整骨骼链

• 改 parent hierarchy

• 批量 rename bones

• 调整 bone orientation

• 修改 skin weight

这些操作现在都可以直接在 UE 中完成。

UE 现在甚至可以从 Static Mesh 生成骨架

你刚刚截图的那个功能：

Static Mesh → Convert to Skeletal Mesh

UE 会：

mesh
↓
生成 root bone
↓
生成 skeleton asset
↓
生成 skeletal mesh

也就是说：

UE 可以完全不依赖 FBX 导入骨骼。 Epic Games Developers

这是 UE5 新加的重要能力。

UE 的动画工具链已经比较完整

如果全部在 UE 内做动画，流程可以是：

Static Mesh
↓
Skeleton Editor
↓
Control Rig
↓
Sequencer
↓
Anim Blueprint

UE 仍然不适合做完整角色 Rig

UE5.7 的限制主要是：

1 权重工具不够强

和 Blender / Maya 比：

• 没有高级 weight smoothing

• 没有高级 mirror

• 没有 topology-aware weight transfer

复杂角色会很痛苦。

没有自动 humanoid rig

UE 目前没有类似：

Blender Rigify
Mixamo AutoRig
Maya HumanIK

这种自动骨架系统。

UE 的工具更偏：

runtime animation editing

而不是：

asset production

前提是 FBX 里包含动画数据，并且在导入时启用了动画导入选项。

抓型

Interchange 导入管线里，设置被分为几层：

• Common：通用规则（骨架/动画相关的全局行为）

• Static Meshes：只影响 Static Mesh 的设置

• Skeletal Meshes：只影响 Skeletal Mesh

• Animations：只影响动画

• Materials / Textures：材质和纹理导入

因此 Common 是一个"上层控制区"。

Notify（Animation Notify） 是动画时间轴上的事件触发点 。

当动画播放到某一帧时，Notify 会触发一段逻辑或事件。

可以把它理解为：
"动画里的回调 / 关键帧事件"。

如果用 Unity 心智类比：

• Unity：Animation Event

• Unreal：Animation Notify

Param2D

和
Param Tex Object

它们的区别可以直接理解成：

一个是"直接采样后的纹理值" ，
一个是"纹理资源对象本身"。

Texture Sample Parameter 2D

它的含义是：

• 这是一个可实例化的 2D 贴图参数

• 节点内部已经包含了 sample 行为

• 输出的是采样结果

所以它直接输出：

• RGB

• R

• G

• B

• A

你可以直接拿去接：

• BaseColor

• Normal

• Roughness

• Mask 之类

它相当于：

Texture2D + Sample

输出的是一个 Texture Object，需要再配合别的节点去 sample。

它相当于：

Texture2D resource handle

或者更接近 HLSL 语义：

hlsl
Texture2D MyTex;

还没到：

hlsl
MyTex.Sample(...)

把纹理对象传进函数或自定义采样逻辑

比如你这个图里的 SDF_Tex，它后面进了一个 Custom 节点。

这种时候经常需要：

• 自己控制 UV

• 自己控制 sample 方式

• 在材质函数里重复采样

• 在 Custom HLSL 里调用采样

• 做特殊滤波 / SDF / 多次 lookup

这时就不能直接给"已经 sample 完的颜色值"，而要给：

Texture Object Parameter

因为下游逻辑需要的是"纹理本体"。

• Skeleton → 默认仍然共享

• ⚠️ Material → 默认仍然共享（Material Instance 指针拷贝）

• PhysicsAsset → 共享引用

  Morph / Skin / Vertex 数据

  这个是安全的：

  • 顶点数据在 SkeletalMesh 内部

  • 复制后是独立 buffer

  蓝图影响路径通常是：

  • MPC（全局）

  • Light（全局）

  • 或 Component 参数（实例级）

  不是 Mesh Asset 层

  用 Custom Primitive Data

  适合：

  • per-character shading

  • 不增加 draw call state

  

  

• 省去美术工作： 美术人员不再需要花费大量时间制作低模、生成LOD层、烘焙法线贴图等繁琐工作，大幅提高开发效率。

• 无缝导入： 可以直接使用Quixel Megascans等高精度资产。

• 变形与动画： 并非所有复杂的骨骼动画（Skeletal Mesh）都能完美启用Nanite（UE5.1+已有改进，但仍有限制）。不支持某些功能： 不兼容一些特定的流体、体积纹理等功能。 UE 里没有"蓝图 → 材质"的直接引用关系，只有 间接数据绑定路径 ：Blueprint (CPU)
  → UMaterialInstanceDynamic（CPU对象）
  → 参数缓存（Uniform Buffer更新）
  → RHI Update (SetShaderUniformBuffer)
  → GPU Pixel Shader

  Per-instance Custom Data / Primitive Uniform

  典型路径：

  • SetCustomPrimitiveDataFloat

  • 或 AnimInstance / Vertex Factory 数据

  数据流：

  Blueprint / Component
  → PrimitiveSceneProxy
  → Primitive Uniform Buffer
  → Vertex/Pixel Shader

  特点：

  • 不走 MaterialInstance

  • 通过 GetPrimitiveData() 访问

  • 常用于角色定制 shading（比如脸部 shadow mask）

  RDG / Mesh Pass

  进入：

  FMeshPassProcessor → BuildMeshDrawCommand

  这里发生关键绑定：

  📌 关键：MeshDrawCommand 生成

  里面绑定：

  • Vertex Buffer

  • Index Buffer

  • Material Uniform Buffer

  • Primitive Uniform Buffer

  • Pass-specific Uniform（如 Light）

  👉 也就是你问的：

  用了什么 buffer？

  类型	内容
  Material UB	材质参数（MID / MPC）
  Primitive UB	Actor/Component级数据
  Pass UB	Light / Shadow / View
  Vertex Buffer	Skeletal mesh skinning 后数据

  关键的不是 SetMaterialAttributes，而是左侧这几个配置：

  • Material Domain = Surface

  • Blend Mode = TranslucentGreyTransmittance

  • Shading Model = Unlit

  这三个一组合，渲染语义基本已经定了。
  "打包属性"graph 级别的"结构化聚合节点"，

  先走 BasePass，写入：

  • GBufferA/B/C...

  • SceneDepth

  • Velocity（如果需要）

  然后在 lighting pass 里基于 GBuffer 做光照累积。

  Translucent

  大多数情况下不写标准 GBuffer

  SetMaterialAttributes 只是属性打包节点；真正让它"特殊"的，是它被编译成了 Translucent + Unlit 材质，因此它不走标准 deferred GBuffer lighting，而是作为透明覆盖层在 translucency pass 里混合到场景中。

  

  Light Function 虽然在资源形态上是 Material，但它不是"作用在被照物材质上的材质"，而是一个给 Light 用的投光函数。渲染阶段里它通常不是去改 GBuffer，而是进入该灯光的 shadow / light attenuation 路径，最终参与的是这盏灯的可见性或强度分布。

  更准确一点说：

  Light Function 本质上是在"这盏灯照到某点时，额外乘一个空间分布函数"。

  所以它影响的不是 surface shading model，而是 light attenuation。很多路径里它会和 shadow term 放在同一类乘法链路里，结果看起来就像"写进了 shadowmap / shadow factor"。

  可以近似理解成：

  Lighting = BRDF * LightColor * NdotL * ShadowTerm * LightFunctionTerm

  因此从效果上，Light Function mask 的灰度值确实会像"半透明阴影"那样工作：

  • 0 = 完全压黑

  • 0.5 = 只保留一半这盏灯的贡献

  • 1 = 不衰减

  

  阴影不是一个单独晚到最后的纯后处理 overlay，而是每盏灯在做 deferred light accumulation 时的一部分输入。Light Function 不是在 Base Pass 生效，而是在这盏灯的 light pass 里和 shadow 类似一起参与 attenuation。所以它不会影响 GBuffer 内容，也不会改几何属性；它只影响这盏灯打到该像素时最终还剩多少强度。Epic 现在的文档依然把默认桌面渲染器描述为 Deferred Renderer；对 Light Function 的说明也仍然是它要先在屏幕空间累积贡献，再在后续阶段参与 lighting evaluation。

  你脑子里那版教材式 deferred，大概是：

  BasePass 写 GBuffer → shadow map 准备 → light pass 读 GBuffer+shadow → 累加到 SceneColor。

  这没错，但 UE 里真正跑的路径会被很多条件分叉：桌面 deferred、forward、mobile deferred、virtual shadow maps、Lumen、Nanite、Strata/Substrate 材质体系、不同平台 feature level、不同 AA 与 upscaler、不同 translucency/volumetric/fog/reflection 组合。也就是说，骨架没变，但分支极多。Epic 对 UE5.7 的图形编程文档和 RDG 文档都强调，现代 UE 渲染器已经通过 Render Dependency Graph 把 deferred 和 mobile renderer 等路径统一进一套 graph-based pass orchestration 体系里，重点变成"如何调度大量 pass 与资源依赖"，而不是"有没有 deferred 这个概念"。

  你听起来觉得简单，是因为你抓到的是渲染器最重要的 invariant。

  但工程上，一个"光照阶段"会裂解成很多 pass：阴影深度生成、阴影投影/过滤、light function、screen-space 或 ray/path hybrid 的 direct/indirect lighting、reflection、SSAO、fog、volumetric、translucency resolve、post chain。以 Light Function 为例，Epic 文档明确说它跟动态阴影类似，要经历额外的屏幕空间累积和后续评估，是顺序化 GPU 操作，还可能因为同步和 cache flush 带来成本；这说明它已经不是"一个乘法"那么朴素，而是一个被工程化拆开的子流程。Epic Games Developers

  "现代复杂度集中在数据组织和调度，不在公式本身"。
  BRDF、NdotL、ShadowTerm、LightFunctionTerm 这类公式，今天看起来和十年前区别不大；难的是：
  资源生命周期怎么管，哪些 RT/UAV 可以 alias，哪些 barrier 可以 split，哪些 pass 能并行录制，哪些异步计算能 overlap，哪些 pass 可以被 graph cull 掉。
  UE5.7 的 RDG 文档把这些点写得很清楚：它负责资源生命周期、sub-resource transitions、parallel command list recording、pass culling、async compute fences 等。也就是说，代码量大，很大一部分是"图调度器和资源编排器"的复杂度，而不是"deferred lighting 数学"本身的复杂度。

  第四层是"UE 的 deferred 已经不是老式 textbook deferred 的边界"。

  例如现在 direct lighting 之外，经常混着 Lumen、virtual shadow maps、Nanite、screen-space 技术、ray tracing 或 hardware RT 的局部替换。你看到的仍然像 deferred，是因为最终很多不透明表面仍以 GBuffer/深度为核心输入来做 lighting；但具体阴影来源、可见性来源、GI 来源、反射来源，已经可以不是同一套传统 shadow map + SSR + probes 的旧组合了。Epic 也在 5.7 文档里给出了像 MegaLights 这种"新的 direct lighting path"，说明"默认 deferred 的骨架"之上，直接光照本身都可以被更激进的系统替换或扩展。Epic Games Developers+1

  第五层是"很多代码是在处理例外情况"。

  教材只讲 opaque。真正引擎要处理：

  masked、translucent、single layer water、hair、subsurface、decals、DBuffer、velocity、depth prepass、custom depth/stencil、editor overlays、debug view modes、VR、TSR/TAAU、platform fallback。

  所以你感觉"概念好像一直没变"，其实是因为你抓的是最底层抽象；而引擎代码多，是因为每个例外都要在这套抽象周围接好。

  GBuffer/Depth 是不透明表面的主输入；阴影、light function、AO、GI、reflections 等在后续 pass 中共同调制 lighting；不是"最后贴一层阴影"。

  Deferred 只是一个高层 shading architecture；真正复杂度来自 RDG pass 图、资源状态转换、平台路径、feature permutations，以及大量非 textbook 的特殊材质和系统整合。

  

  相比法国大革命时期，如今"左和右"的含义已更加宽泛 ，在不同国家存在区别划分，不能简单把"左"划成"激进"，把"右"等同"保守"，需要分具体问题来讨论；而且"左和右 "是相对概念，要在具体情境下看是跟谁比。

  左------支持平等原则，限制权贵富裕阶层，倡导社会资源分配平等，社会财富向多数人倾斜，缩减贫富差距，主张政府干预经济，反对资产阶级独大、垄断；

  右------追求自由主义，最大限度地为权贵松绑，倡导利己主义，能者多得，反对政府干预经济，维护既得利益者的地位，拒绝以高福利政策滋养闲人。

  translucent 不进这套 GBuffer 主链decal 有 DBufferfog、volumetric cloud、sky atmosphere 看似后处理，实际上和深度、阴影、light shaft 强耦合Depth、GBuffer、Shadow data、HZB、Lumen scene、history buffers这些数据分别由哪些系统生产

  BasePass、Nanite、Shadow system、Lumen、Post/Temporal谁消费这些数据

  Deferred light pass、reflections、fog、translucency、post哪些 feature 在修改或绕开默认链路

  Substrate、VSM、Lumen、Nanite、forward translucency、mobile fallback谁消费这些数据哪些 feature 在修改或绕开默认链路

  Details 面板Actor + Component 分层叠加的反射结果 。

  • Replication / Networking

  • Actor / 生命周期 / Collision Handling

  • Data Layers / Level Instance

  全部来自：

  AActor

  而不是：

  UExponentialHeightFogComponent

  为什么你选的是 Fog，却看到 Actor 属性

  关键在于：

  UE 里选中的对象其实是 Actor，不是 Component

  你现在选中的是：

  ExponentialHeightFog (Instance)

  它的类型是：

  AExponentialHeightFog

  而这个类结构是：

  AExponentialHeightFog : public AActor
  {
  UExponentialHeightFogComponent* Component;
  }

  所以：

  👉 Details 面板展示的是 整个 Actor 的反射属性树

what to look，what to exist，

see the mountain，didn't in the mountain，what remain，for ？

Slate 本身是 UE 的独立 UI 框架，用来做编辑器和游戏内 UI。Epic 文档把它定义为"完全自定义、平台无关"的 UI framework；UMG 则是建立在这套 UI 工具链上的更高层系统。配合 UMG Styling 文档里"为 Slate 编译不同 shader specifically for Slate"这句话，可以合理推断：UI 材质的目标不是进入场景的 deferred/forward surface shading，而是进入 Slate/UMG 的 2D 绘制链路。
UMG (Unreal Motion Graphics) 是虚幻引擎（Unreal Engine）中用于创建 UI（用户界面）的强大可视化系统

。它是虚幻引擎内置的界面设计器和功能框架，用于制作游戏 HUD、菜单、HUD 元素、视口内界面等内容。

Slate 和 UMG (Unreal Motion Graphics) 是两套用于创建用户界面（UI）的系统，它们之间是底层基础与顶层封装的关系。
Slate (底层 UI 框架)

• 本质：是一个基于 C++ 的自定义界面渲染和布局框架。
• 用途：它是虚幻编辑器（Editor）本身所使用的 UI 系统，同时也用于创建复杂的、高性能的游戏内 UI。
• 特点：
  • 纯 C++：没有蓝图可视化界面，需要通过 C++ 代码编写布局、风格和逻辑。
  • 强大而灵活：适合制作功能非常复杂、需要高级自定义或编辑器扩展的工具。
  • 声明式语法：使用特定风格的 C++ 代码（像描述结构一样）来声明 UI 元素。
  • 不属于 UObject 系统 ：Slate 控件不是 UObject 类型，它们在垃圾回收系统之外工作，因此在编写某些涉及自动内存管理的逻辑时需要特别小心。

• 可视化编辑器：可以在编辑器中像搭积木一样拖拽控件、设置属性，类似于 Unity 的 UGUI。
• 支持蓝图：UI 逻辑完全可以使用可视化蓝图脚本编写，极大降低了开发门槛。

UMG 中嵌入底层的 SlateUE 的文档把这三个核心属性分得很清楚：Material Domain 决定材质会被用在什么上下文里，Blend Mode 决定它如何和后面的像素混合，Shading Model 决定它如何受光。也正因为这三者职责不同，某些 domain 根本不需要、也不适合暴露 Blend Mode。决定深度写入、早深度、GBuffer 参与方式、光照路径和与背景的合成关系。像 Light Function 这种 domain，给 Blend Mode 反而会造成语义混乱。

它不是在"画一个表面"，而是在定义灯光空间中的调制函数。它的输出不是表面颜色，不是往场景里盖一层半透明片，而是参与灯光衰减/调制。因此"Translucent 还是 Additive"在这里没有标准意义。

材质路径。

这个是你前面一直在碰到的，尤其 UE 里最常说。

它的意思通常是：
材质在编译期和渲染期被归到哪类着色/合成契约。

例如：

• Material Domain 决定 domain path

• Blend Mode 决定 visibility/composition path

• Shading Model 决定 lighting response path

具体一点：

Surface + Opaque

通常意味着：

• 进入 opaque/base pass

• 写 GBuffer

• 走 deferred lighting 主链

Surface + Translucent

通常意味着：

• 不走标准 opaque GBuffer 主链

• 进入 translucency 相关 pass

• 光照和排序语义变化

Light Function

意味着：

• 不是表面路径

• 是灯光调制路径

Post Process

意味着：

• 不是几何表面路径

• 是屏幕后处理路径

所以很多人口中的"材质走哪条路径"，本质上在说：
这个材质编译成哪类 shader，在哪类 pass 被执行。

图形里的"路径"不是单一术语，它泛指从编译、调度、数据生产、着色求值到资源流转任一层面的实现分支；讨论时必须先明确分叉所处层级，否则"路径"这个词几乎没有信息量。

引擎层，大家讨论的是frame rendering organization ，不是单个 draw 的硬件 stage。

比如说：

• base pass pipeline

• shadow pipeline

• translucency pipeline

• post pipeline

这里的"pipeline"其实是在说：
一帧中大量 draw/dispatch 如何被组织起来完成场景渲染。

这已经不是 IA→VS→PS 那个严格意义的 pipeline 了，而是"渲染流程"或"渲染架构"。

实际上不是。真实情况更接近：

• BasePass 里有很多 draw，每个 draw 各自经历自己那套 graphics pipeline

• ShadowPass 里又有很多 draw，再各自经历一套 graphics pipeline

• Translucency / Depth / Velocity / CustomDepth 也是一样

所以从 frame 角度看是：
Pass A -> Pass B -> Pass C

从 draw 角度看则是：
Draw1: IA->VS->...->PS->OM
Draw2: IA->VS->...->PS->OM
Draw3: IA->VS->...->PS->OM

也就是：

场景级流程是"许多 draw/dispatch 的调度顺序"；单个 GPU pipeline 是"某次 draw 的阶段执行链"。

draw 的 vertex/index stream

Graphics pipeline 是 GPU 对一次 draw 提交的图元批次所执行的固定阶段处理链，而不是整个场景在一帧内统一经过的一条全局流水线。

然后再补一句：

所谓场景级"render pipeline"，通常只是对整帧 pass 调度和数据依赖组织的高层称呼，不应与单次 draw 的硬件 pipeline 混为一谈。

再往下拆，你会发现"pipeline"这个词至少有三个严格不同的层级：

第一层，hardware pipeline

就是你写的：
IA -> VS -> HS/DS -> GS -> Raster -> PS -> OM

对象是 draw/primitive batch。

第二层，PSO contract

也就是当前这次 draw 绑定的那套：

• shaders

• blend/depth/raster states

• topology 等

  这是决定"这次 draw 用哪种 pipeline 形态"的配置。

第三层，frame render pipeline

也就是：

• base pass

• shadow pass

• lighting pass

• post pass

  对象是整帧的渲染组织。

如果把这三层混成一个词，就必然脏。