自由学习记录（208）

Sₙ₊₁ = F(Sₙ) 只写出了两个状态之间的关系，却没有说明：

为什么世界没有永远停在 Sₙ，而是真的来到了 Sₙ₊₁？

物理系统一直在变化，而这些变化反复呈现出同一个稳定关系；我们把这个稳定关系称为规则。

变化的输入 + 固定的规则 → 变化的输出

"→"究竟是什么？

​

河床形状相对静态
水持续流动
河床不主动推水
但它持续决定水流可能走向哪里

DLL 更像一张将来会被加载进机器状态中的结构描述；CPU 电路则是实际的河床；电能和信号是水。

"输入也是存"，对，但只解释了一半

但它没有完全解释：

为什么保存的状态会被下一步读取？谁规定的?

答案不是"因为规则要求读取"，否则又会出现：

谁去执行读取规则？

真正的答案是：

所谓"被读取"，就是一个物理状态与另一个物理系统发生了因果接触。

内存中的一个 bit 不会主动宣布自己的值。

它可以精确研究轨迹、稳定点、周期与混沌，却把"时间确实流逝、状态确实发生"作为模型的基本前提。​编辑Wikipedia+1

数学很好地描述"变化具有怎样的结构"，但不必回答"为什么有实际的变化，而不只有静态关系"。

谁执行物理定律？

"being"和"becoming"

DLL是静态的，只是因为它在你观察的时间尺度上变化极慢。

晶体管结构是固定的，只是因为它比信号变化得慢。

人体看似是同一个人，但组成分子、代谢和神经状态始终变化。

时间是否真实流逝

• schedule：时间安排

• scheme：方案、计划

• schema：结构规范、数据模式

在软件里，schema 更接近：

规定一份数据由哪些部分组成，以及每一部分应该怎样解释。

​

原始版本
└ 左脚起步

镜像版本
└ 右脚起步

这样一条动画资产可以给 Motion Matching 提供两组姿势候选，而不必真的再制作一个 Run_RightStart 动画文件。

└ Chooser Table └ 根据条件选出一个 PSD └ Motion Matching 搜索该 PSD ├ 使用 PSD 的 Schema 构造 Query ├ 在 PSD 的 Search Index 中比较 └ 返回 PSD 内某个 Animation Asset 的某一帧

多个 Aglina PSD 可以共享一个 Schema：

PS_Schema_Aglina
├ 被 Idle PSD 使用
├ 被 Walk Stop PSD 使用
├ 被 Run Stop PSD 使用
└ 被 Turn PSD 使用

Aglina Chooser └ Result ├ PSD_Aglina_Stand_Idles ├ PSD_Aglina_Stand_Walk_Stops ├ PSD_Aglina_Stand_Run_Stops └ PSD_Aglina_Stand_TurnInPlace 每个 PSD ├ Schema │ └ PS_Schema_Aglina │ ├ Skeleton = Aglina Skeleton │ ├ Channels = Aglina 要使用的搜索特征 │ └ Mirror Data Table = MDT_Aglina │ └ Animation Assets ├ Aglina_Idle_* ├ Aglina_WalkStop_* ├ Aglina_RunStop_* └ Aglina_Turn_* └ 每条动画各自设置 Mirror Option

Motion Matching 利用 Pose Search，代替了传统 Locomotion 动画图中大量"状态 → 过渡条件 → Blend Space → 动画"的人工选择逻辑。

Motion Matching 没有取代 Locomotion；它本身成为了 Locomotion 的动画实现方式，并把传统状态机中"具体动画选择与过渡"的工作改造成了数据库搜索。

Idea ↓ Prototype（原型） ↓ Preliminary version（初步版本） ↓ Beta version（测试版） ↓ Final release（正式发布）

技术文档、科研论文、工程报告中看到 preliminary，通常意味着：

"这个结果/设计/数据目前只是阶段性结论，还可能被修改。"

The preliminary results look promising.

初步结果看起来很有希望。

Lyra 里面叫 LocomotionSM，也是开发者给某个 State Machine 起的功能名称，并不是一个名为 ULocomotion 的资产类。

一个动画只能"是或不是 Locomotion"吗？

从项目语义上可以这样分类；从资产类型上不能。

例如：

AS_Walk_Fwd
├─ 资产类型：Animation Sequence
└─ 当前用途：Locomotion

但同一个 AS_Walk_Fwd 也可以被：

├─ 放进 Blend Space，作为 Locomotion
├─ 放进 Pose Search Database，作为 Motion Matching 搜索样本
├─ 放进 Montage，作为某段受控播放动画
├─ 放进 Sequencer，作为过场动画
└─ 单独预览或播放

Animation Blueprint
└─ AnimGraph
   └─ State Machine                 UE 提供的结构类型
      ├─ State
      ├─ Transition
      └─ Conduit / State Alias

创建时，菜单里只有：

State Machines
└─ Add New State Machine

UE 不会让你选择：

Add Locomotion State Machine
Add Combat State Machine
Add Interaction State Machine

新建之后，开发者自己给它命名。官方文档的 State Machine 属性里也只有一个普通的 Name；它本质上只是可以包含状态和转移逻辑的通用子图。

为什么几乎所有 ABP 都叫 Locomotion

它不是无理由的默契，而是一个非常稳定的领域术语和架构边界。

大多数可操控角色都必须不断回答同一组问题：

角色当前是否在地面？
├─ 没有位移
│  └─ Idle
├─ 正在位移
│  ├─ Walk
│  ├─ Run
│  ├─ Sprint
│  └─ Strafe
└─ 离开地面
   ├─ Jump
   ├─ Fall
   └─ Land

这些动作具有共同性质：

Locomotion
├─ 通常持续时间不固定
├─ 由 Velocity、Acceleration、Movement Mode 等连续数据驱动
├─ 需要频繁、可逆地相互过渡
├─ 通常负责角色的基础全身姿势
└─ 其他动作往往叠加在它的输出上
   ├─ Aim
   ├─ Fire
   ├─ Reload
   ├─ Hit Reaction
   └─ Facial Animation

Locomotion 正好是动画、机器人学和生物运动领域已经存在的词，因此大家不会各自重新发明：

BasicMovementAnimationMachine
CharacterMovingAroundGraph
WalkingAndRunningStuff

而统一倾向于使用：

Locomotion
LocomotionSM
Grounded Locomotion
Base Locomotion

Epic 自己的文档也直接说明，State Machine 主要经常被用于 把 Idle、Walk、Run、Jump 等动画与角色移动状态关联起来；这解释了为什么 State Machine 和 Locomotion 经常同时出现，但文档没有说 Locomotion 是一种 State Machine 类型。​编辑Epic Games Developers

甚至 Locomotion 不一定使用 State Machine

这一点最能证明它们不是类型从属关系。

Locomotion System
├─ 可以用 State Machine
│  ├─ Idle
│  ├─ Start
│  ├─ Cycle
│  └─ Stop
│
├─ 可以用 Blend Space
│  └─ Speed × Direction
│
├─ 可以用 Motion Matching
│  └─ Pose Search Database
│
├─ 可以用 Chooser
│  └─ 根据状态选择动画资产
│
└─ 可以用纯 AnimGraph 条件和 Blend 节点

Lyra 为什么叫 LocomotionSM

Lyra 的 AnimBP_Mannequin_Base 中确实有一个名为 LocomotionSM 的 State Machine。官方文档让用户双击它查看 Locomotion states；这只是 Lyra 对该图职责的明确命名。​编辑Epic Games Developers

它表达的是：

LocomotionSM
│
├─ 对象是什么？
│  └─ State Machine
│
└─ 对象负责什么？
   └─ Locomotion

Loop 在 UE 5.8 也是资产的默认属性，但播放节点可以覆盖它。

两个 ABP 并不会各自得到一份这些属性的副本。你修改 AS_Aglina_Run 的 Force Root Lock，所有引用它的 ABP、PSD、Montage 等都会看到修改后的值。

Animation Sequence 资产 ├─ Skeleton ├─ Enable Root Motion ├─ Root Motion Root Lock ├─ Force Root Lock └─ Loop：默认循环意图 Animation Blueprint ├─ Root Motion Mode │ └─ 决定如何处理资产提供的 Root Motion └─ 播放节点 ├─ Loop Animation ├─ Play Rate ├─ Start Position └─ Sync Group 等 Pose Search Database ├─ 引用 Animation Sequence ├─ 根据资产属性建立搜索索引 ├─ Sampling Range └─ 保存由 Schema 定义的 Pose / Trajectory 特征 Pose Search Schema ├─ Skeleton └─ Channels ├─ Trajectory └─ Pose

Enable Root Motion
└─ 这份动画允许提取 Root Bone 的位移

Root Motion Root Lock = Ref Pose
└─ 提取位移后，把输出姿势中的 Root Bone 锁回参考姿势位置

Force Root Lock = true
└─ 即使当前没有提取 Root Motion，也强制锁住 Root Bone

所以两个 ABP不能通常这样做：

ABP_A 使用同一资产
└─ Root Lock = Ref Pose

ABP_B 使用同一资产
└─ Root Lock = Anim First Frame

因为 Root Motion Root Lock 不是 Sequence Player 节点的普通实例参数，而是 UAnimSequence 上保存的属性。

要得到这两种资产级结果，通常需要复制动画：

AS_Run_RefPoseLock
└─ Root Lock = Ref Pose

AS_Run_FirstFrameLock
└─ Root Lock = Anim First Frame

但两个 ABP仍然可以不同地"消费"Root Motion

资产负责声明：

这份动画具有可提取的 Root Motion

ABP 负责决定：

提取之后怎么处理

在两个 ABP 的：

Class Defaults
└─ Root Motion Mode

Loop 是特殊情况

UE 5.8 的 Animation Sequence 资产里有一个 Loop：

Animation Sequence
└─ Loop = true

源码对它的定义非常直接：

The default looping behavior of this animation.
Asset players can override this.

所以它是资产默认值，但不是绝对不可覆盖。

脚对具体地形的适应通常来自 IK。

假设动画中的 Root Bone 在一秒内向前移动 100 cm：

原始动画
Frame 0    Root = 0 cm
Frame 30   Root = 100 cm

启用 Root Motion 后，UE 大致执行：

Root Bone 动画位移
└─ 提取 ΔRoot = 前进 100 cm
   ├─ 用这 100 cm 推动 Character / Capsule
   └─ 将姿势里的 Root Bone 锁回 Ref Pose

最终结果是：

世界空间
└─ Character 和 Capsule 前进了 100 cm

Skeletal Mesh 内部
└─ Root Bone 被锁在参考位置，不会跑出 Capsule

所以 Root Motion Root Lock = Ref Pose 的"锁定"是：

把已提取位移后的 Root Bone 锁回角色内部参考点。

不能单独决定脚应该踩在具体哪里

例如地面从平地变成斜坡：

Root Motion
└─ 仍然只知道整个角色应该向前移动多少

它通常不知道
├─ 左脚下面地面高度
├─ 右脚下面地面高度
├─ 脚底应该倾斜多少
├─ 台阶边缘在哪里
└─ 脚是否穿进石头

这些通常需要：

环境检测
├─ Line Trace / Shape Trace
│
└─ 得到脚下地面位置和法线
   └─ IK / Foot Placement
      ├─ 移动 Foot Bone
      ├─ 调整脚底旋转
      ├─ 调整 Knee
      └─ 必要时调整 Pelvis 高度

IK Goal 和 Solver 的职责就是修改输入姿势，使手或脚等末端骨骼到达目标位置。​编辑Epic Games Developers

比如翻越箱子：

场景检测
└─ 找到箱子边缘 Transform
   └─ Motion Warping
      └─ 调整 Root Motion，使身体到达箱子边缘
         └─ Hand / Foot IK
            └─ 让手脚准确贴在箱子表面

Motion Warping 官方定义就是动态调整角色的 Root Motion，使其对齐某个场景目标；它仍然主要修改整体根运动，而不是自动求解每只脚。​编辑Epic Games Developers

Motion Matching 可以据此选择一帧：

哪段动画的身体轨迹和脚部姿势最接近当前需求。

但选择结束后，它仍然不知道实际地面的每块凹凸。要精确踩地，末端仍然通常需要 Foot Placement 或 IK 修正。

USkeletalMeshComponent::NeedToSpawnAnimScriptInstance() 会执行类似这样的检查：

C++

USkeleton* AnimSkeleton =
    AnimClassInterface->GetTargetSkeleton();

bool bSkelMeshCompatible =
    AnimSkeleton->IsCompatibleMesh(MeshAsset, false);

也就是说，它并不简单要求：

C++

AnimSkeleton == MeshAsset->GetSkeleton()

而是要求：

ABP TargetSkeleton
        ↓
与当前 Skeletal Mesh 兼容

所以"不同 Skeleton 资产"不必然意味着"必须复制 ABP"。

但是 Compatible Skeleton 更适合：

骨骼名称基本相同
骨骼层级基本相同
骨骼语义相同
只是资产不同或少量附加骨

一个 ABP 编译后，相当于：

这套程序专门接受 MannyPoseSchema

而不是：

接受任意一组名字叫骨骼的对象

FBoneReference::Initialize() 会把节点里保存的骨骼名字转换成索引：

C++

BoneIndex =
    RequiredBones.GetPoseBoneIndexForBoneName(BoneName);

CachedCompactPoseIndex =
    RequiredBones.MakeCompactPoseIndex(...);

所以你在 AnimGraph 里看到的：

Bone to Modify = foot_l
IK Bone        = ik_foot_l
Root Bone      = root

编辑器里看起来是字符串名称，但节点初始化后，真正执行时更接近：

foot_l → CompactPoseIndex 57
root   → CompactPoseIndex 0

Retarget Anim Assets

这个操作面向：

AnimSequence
AnimMontage
BlendSpace

而不是 Pose Search Database。

PSD 里面会生成一份你平时看不见的 Search Index。Schema 是这份 Search Index 的格式配置。

用一个只有一项的 Schema，你就能看到它了

假设我们创建最荒谬、最简单的 Schema：

PSS_Test
├─ Skeleton = Aglina_Skeleton
└─ Channels
   └─ Velocity
      └─ Bone = foot_l

这份 Schema 的全部意思只有一句：

把每个候选动画时间点的 foot_l 速度记录下来，并在运行时拿当前角色的 foot_l 速度来比较。

没有更多东西。

UE 按照 Schema 的 Sample Rate，例如每秒 30 次，逐个时间点读取左脚速度：

Run_Forward 0.00 秒
foot_l velocity = (20, 5, 80)

Run_Forward 0.033 秒
foot_l velocity = (25, 4, 60)

Run_Forward 0.066 秒
foot_l velocity = (30, 2, 10)

于是 PSD 内部生成：

Search Index

Pose 0 → [20, 5, 80]
Pose 1 → [25, 4, 60]
Pose 2 → [30, 2, 10]

这些数字不是存在 Schema 里。

Schema
└─ 规定要记录 foot_l velocity

PSD Search Index
└─ 真正保存每个动画时间点的 foot_l velocity 数值

UObject │ ├─ UDataAsset │ ├─ UPoseSearchDatabase │ └─ UPoseSearchSchema │ ├─ UChooserSignature │ └─ UChooserTable │ ├─ UBlueprintCore │ └─ UBlueprint │ └─ UAnimBlueprint │ ├─ UAnimInstance │ └─ 你的 SandboxCharacter_CMC_ABP 运行时实例 │ └─ UPoseSearchFeatureChannel ├─ UPoseSearchFeatureChannel_Position ├─ UPoseSearchFeatureChannel_Velocity ├─ UPoseSearchFeatureChannel_Heading ├─ UPoseSearchFeatureChannel_Phase └─ UPoseSearchFeatureChannel_GroupBase ├─ UPoseSearchFeatureChannel_Pose └─ UPoseSearchFeatureChannel_Trajectory

源码位置：

Plugins/Animation/PoseSearch/Source/Runtime/Public/
└─ PoseSearch/
   ├─ PoseSearchDatabase.h
   ├─ PoseSearchSchema.h
   └─ PoseSearchFeatureChannel.h

其中：

C++

class UPoseSearchDatabase : public UDataAsset
class UPoseSearchSchema   : public UDataAsset

class UChooserSignature : public UObject, public IHasContextClass class UChooserTable : public UChooserSignature

UAnimBlueprint └─ 编辑器资产，保存图、节点、编译信息 UAnimBlueprintGeneratedClass └─ 编译产生的类描述 UAnimInstance └─ 游戏运行时真正存在的对象实例

Motion Matching 节点不是 UObject

是一个 USTRUCT 动画节点

Play Rate = 1.0
└─ 现实经过 1 秒，动画前进 1 秒

Play Rate = 2.0
└─ 现实经过 1 秒，动画前进 2 秒

它控制的是：

这一帧之后，播放指针要往前走多远

Animation Curve

Animation Current Time
└─ 查询 Curve 在这个时间的值

它是：

播放指针已经走到这里了
└─ 现在 Curve 的值是多少？

所以正常执行顺序是：

Play Rate
└─ 决定 Current Time

Current Time
├─ 取出当前 Bone Pose
└─ 取出当前 Curve Values

工程上你可以把某个 Curve Value 再接到 Play Rate：

Get Curve Value "SpeedMultiplier"
└─ Sequence Player.PlayRate

这样它才参与播放速度。

但这是你主动赋予它的用途，不是 Animation Curve 自带的含义。

AllowedClasses 没有把变量变成 AStaticMeshActor*。它只是给编辑器选择器安装了一个过滤器。

Property Editor 的运行时反射检查，

不是 C++ 编译器的类型检查。

它真的只能是 Static Mesh Actor，合理写法是：

C++

#include "Engine/StaticMeshActor.h"

UPROPERTY(EditAnywhere)
TObjectPtr<AStaticMeshActor> TargetActor;

实现某接口的其他 Actor

底层存储需要保持 AActor

没有一个比 AActor 更具体的共同基类

UE 5.8 甚至还支持动态过滤：

C++

meta = (GetAllowedClasses="GetValidTargetClasses")

读懂了一段 causal chain，并不等于你能在 90 秒内把它说清楚，也不等于你能现场打开工具验证。

脚落地时开启 IK

走路动画播放时：

FootPlant_L Curve

脚抬起
└─ 0.0

脚开始接近地面
└─ 0.0 → 1.0

脚稳定踩地
└─ 1.0

脚再次抬起
└─ 1.0 → 0.0

ABP 中：

Get Curve Value "FootPlant_L"
└─ Two Bone IK / Foot IK Alpha

表情 Morph Target

Curve Name = MouthSmile

0.0
└─ 不微笑

0.5
└─ 一半微笑

1.0
└─ 完全微笑

如果 Curve 名称与 Morph Target 名称一致，并将其标记成 Morph Target Curve：

MouthSmile Curve
└─ 自动驱动 MouthSmile Morph Target

不一定需要在 ABP 里手动读取。

时间 → 数值

叫 Curve

一帧的完整动画输出不是只有骨骼

Chooser：现在应该搜哪一类动作？
PSD：这一类动作里有哪些候选？
Schema：候选之间用什么特征比较？

_C 表示：

Generated Class

不是"一个单独实例"。

三层关系是：

Blueprint 资产
SandboxCharacter_CMC_ABP
        ↓ 编译

生成类
SandboxCharacter_CMC_ABP_C
        ↓ 创建对象

运行时实例
某个 SkeletalMeshComponent 当前使用的 AnimInstance

如果现在重新创建节点，发现不能重新连上，原因就是这两个类没有继承关系。当前连线很可能是复制 ABP 时保留下来的序列化连接；它能继续显示甚至编译成功，并不表示 Chooser Context 已正确迁移。

源码中的 Bool Getter就是：

bool UKismetSystemLibrary::GetConsoleVariableBoolValue(...)
{
    return GetConsoleVariableIntValue(VariableName) != 0;
}

UE 自己提供 Material Parameter Collection，就是为了把全局参数送入许多材质，避免逐个修改 Material Instance。

对象一：Evaluate Chooser 节点 类型：UK2Node_EvaluateChooser2 对象二：CHT_PoseSearchDatabases 资产 类型：UChooserTable

节点只是拿着一根指针，指向拥有 ContextData 的 Chooser 资产。

Germane /dʒɝːˈmeɪn/ 是形容词，意思是：

密切相关的；切题的；与当前问题直接有关的。

比 relevant 更正式，而且通常强调：

不是"多少有点关系"，而是"对当前主题有直接、实质性的关系"。

区别：

• relevant：相关的，最常用，范围较广

• germane：直接相关、切题，较正式

• pertinent：切中要点、恰好相关，也很正式

• The question elicited an honest response.

  这个问题引出了一个诚实的回答。

• The joke elicited laughter from the audience.

  这个笑话引起了观众的笑声。

• The interviewer tried to elicit more details.

  采访者试图引出更多细节。

不是直接"给出"，而是通过提问、刺激、情境等，把原本没有明确出现的东西引出来。

• elicit：引出对方原本未明确表达的内容

• evoke：唤起记忆、情绪或画面感

• provoke：激起反应，常带刺激或冲突意味

• extract：提取，语气更强，像把东西"取出来"

illicit /ɪˈlɪsɪt/ = 非法的、违禁的

Transistors（晶体管） └─ 组成逻辑门、寄存器、缓存、控制器等电路 └─ 这些电路组成一个 Chip / IC（芯片、集成电路） └─ 某些芯片承担 Chipset（芯片组）的功能 └─ Chipset 通过 Buses / Interconnects 与 CPU、内存、GPU、设备通信

核心不是"看一眼"，而是：

observe repeatedly
└─ collect status
   └─ detect changes or problems

相关词：

surveillance = 监视，通常更偏安保、执法

monitor 通常是"显示器"

ABP 换了，并不能推出 Chooser 资产也必须换。

所以 UE 不会自动删除或替换原来的 Chooser 引用。

为什么不能看到 ABP 不同就自动换掉

因为"节点所在的 ABP 类型"和"Chooser 需要读取的对象类型"并不必然相同。

例如：

当前节点所在对象
Aglina_ABP

Chooser Context 要求
Sandbox_ABP

这仍然可能是合法设计，因为你可以显式传入另一个对象：

Aglina_ABP
└─ Evaluate Chooser
   └─ Context Pin ← 某个 Sandbox_ABP 实例

所以从 UE 的角度：

节点放在 Aglina ABP 中

不能直接推断：

Chooser Context 必须是 Aglina ABP

The group is heterogeneous.

这个群体由不同类型的人组成。

内部各部分不相同

例如"一杯完全混合均匀的盐水"是 homogeneous；"沙子、石块和泥土混在一起"是 heterogeneous。

• comprise 本身已经有"由......组成"的意思

• 因此传统语法更推荐：

  • The system comprises three modules.

  • The system is composed of three modules.

  • The system consists of three modules.

• The chip is soldered to the motherboard.

  芯片被焊接在主板上。

• The wires are soldered to the terminals.

  导线被焊接到接线端子上。

• The RAM chips are soldered to the board.

  内存芯片直接焊接在电路板上。

• soldered RAM

  板载内存、焊接式内存

• socketed CPU

  插槽式 CPU

window ├─ 名词：窗口 └─ windowing └─ 创建、显示、排列、移动、缩放、管理窗口这一整套活动 windowing system └─ 用于完成 windowing 的系统

基础词：

capable
/ˈkeɪ.pə.bəl/

然后加上：

capable + -ity
→ capability
/ˌkeɪ.pəˈbɪl.ə.ti/

Editor Utility Widget（EUW）就是：你自己做的一块 UE Editor 内部面板。

普通 Widget Blueprint └─ 运行在游戏里 ├─ 游戏菜单 ├─ HUD ├─ 血条 └─ 背包界面 Editor Utility Widget └─ 运行在 Unreal Editor 里 ├─ 批处理面板 ├─ 资产检查器 ├─ 场景布置工具 └─ 自定义编辑器操作

为什么需要四个 Schema

因为不同状态对"什么最重要"的定义不同：

• 移动：未来轨迹、方向、速度很重要。
• Idle：姿势连续性更重要，轨迹几乎没有信息。
• Jump：垂直速度、腾空和落地状态更重要。
• Stop：减速、停止距离和朝向变化更重要。

四个 Schema 本质上是在说：

面对不同动作问题，要换一套特征、采样时间和权重来评分。

Motion Matching 不是直接识别动画名称，而是由 Schema 把当前角色状态和数据库动画帧编码成相同格式的特征向量。系统计算当前 Query 与每个候选 Pose 之间的加权距离，再叠加数据库、循环动画、继续播放和 Notify 等 Cost 修正，最后选择总 Cost 最低的姿势。Chooser 决定搜索哪些数据库，NormalizationSet让多个数据库的评分尺度更适合相互比较。

NormalizationSet 确实只有数组

官方类基本就是：

class UPoseSearchNormalizationSet : public UDataAsset
{
    TArray<TObjectPtr<const UPoseSearchDatabase>> Databases;
};

它自己的 .cpp 也只是遍历数组、收集数据库：

for (const UPoseSearchDatabase* Database : Databases)
{
    UniqueDatabases.AddUnique(Database);
}

所以如果只看这个资产类，你说得对：

它自己没有计算 Cost，也没有运行时搜索逻辑。

真正影响发生在哪里

影响发生在 PoseSearchDerivedData.cpp，也就是数据库索引构建阶段。

构建某个 PSD 时，代码会检查：

Database->NormalizationSet

然后递归读取：

NormalizationSet->Databases

把数组中的 PSD 收集成一个数据集合。之后 FMeanDeviationCalculator 会：

1. 收集这些 PSD 的 Schema；
2. 找出不同 Schema 中可以共同归一化的 Channel；
3. 读取这些数据库建立的特征数据；
4. 计算这些特征的 Mean Deviation；
5. 用结果生成数据库索引里的归一化权重。

源码甚至明确按兼容性分组：

Channel->CanBeNormalizedWith(OtherChannel)

所以四个 Schema 不要求完全相同。能够共同归一化的 Channel 放在一起计算，不兼容的 Channel 分开处理。

NormalizationSet 不直接修改运行时 Cost，也不包含评分算法。它在 PSD 索引构建阶段指定联合统计的数据范围；PoseSearchDerivedData 根据数组内数据库的特征数据计算共同的 Mean Deviation，并把结果固化进搜索索引，从而间接改变运行时特征距离和最终 Cost。

• His actions amount to betrayal.

  他的行为等同于背叛。

• This amounts to a complete failure.

  这实际上等于一次彻底失败。

• This amounts to a 20% increase.

  这相当于增加了 20%。

• The total bandwidth amounts to 1 TB/s.

  总带宽达到 1 TB/s。

核心是：

经过汇总或分析后，最终归结为某个数值或结论。
"The author's argument is that rendering performance is limited by memory bandwidth."

意思：

作者的核心论点是：渲染性能受到内存带宽限制。

个意思其实有共同核心：

argument = 被"提出/传递"的东西

Parameter vs Argument

严格区分：

C++

id="xjz6ai"
void Move(float speed)
             ↑
          parameter

这里的 speed 是：

参数声明（parameter）

调用：

C++

id="g8x8h3"
Move(100);
     ↑
  argument

这里的 100 是：

实际传入的参数值（argument）

关系：

Parameter
= 函数定义时的占位符

Argument
= 调用函数时实际给的东西

为什么"争吵"和"参数"用同一个词？

因为它们历史上都有：

"向某个目标提出一个东西"

实际情况：

函数定义：

void SpawnActor(ClassType Class, FVector Location)
                      ↑              ↑
                  parameters


函数调用：

SpawnActor(MyCharacter, FVector(0,0,100))
           ↑                 ↑
        arguments

严格说：

• parameter = 函数/方法声明里的变量

• argument = 调用时传进去的实际值

为什么这个词会进入编程？

因为早期计算机科学大量借用了数学语言：

数学里：

function f(x)

调用：

f(5)

这里：

• x 是变量

• 5 是输入值

英文里把传给函数的东西叫：

argument

来自数学里的：

argument of a function

意思是：

函数的输入量。

例如：

sin(x)sin(x)sin(x)

这里：

• x 是 argument of the sine function

所以编程继承了这个说法。

Civilization VI is a turn-based 4X strategy game developed by Firaxis Games and published by 2K.

aptitude适合学习某领域的潜在能力

​

Mutualistic symbiosis

蜜蜂 ↔ 花

Commensalism

藤壶附着在鲸鱼身上

Parasitic relationship

寄生虫 → 宿主

a symbiotic relationship between humans and AI

coexistence = 只是同时存在

• high volume of data

  大量数据

• high volume of assets

  大量资产

prefabricated object（预制对象）

nested = 嵌套的

所以：

nested prefab
=
Prefab里面包含Prefab

不是"完全相同"。

例如：

• A car engine is analogous to a human heart.

  汽车发动机类似于人的心脏（功能上有类比关系）。

范围是：

UMaterial
└─ UMaterialInterface
   ├─ UMaterialInterfaceEditorOnlyData
   └─ UMaterialEditorOnlyData

以及 Details 中展开的结构体：
├─ FMaterialOverrideNanite
├─ FDisplacementScaling
├─ FDisplacementFadeRange
├─ FLightmassMaterialInterfaceSettings
└─ FParameterGroupData

主要源码：

Engine/Source/Runtime/Engine/Public/Materials/Material.h
Engine/Source/Runtime/Engine/Public/Materials/MaterialInterface.h
Engine/Source/Runtime/Engine/Public/Materials/MaterialOverrideNanite.h
Engine/Source/Runtime/Engine/Classes/Engine/EngineTypes.h
Engine/Source/Editor/MaterialEditor/Private/
    MaterialEditorDetailCustomization.cpp

Decal Response (DBuffer)

UMaterial::MaterialDecalResponse

类型：EMaterialDecalResponse

Material.h:495--496

Thin Surface

UMaterial::bIsThinSurface

Material.h:564--565

[C] 没有启用 Substrate 时，编辑器直接隐藏。

Generate Spherical Particle Normals

UMaterial::bGenerateSphericalParticleNormals

Material.h:666--667

[A]

Cast Dynamic Shadow as Masked

Whether the Material should cast shadows as masked even though it has a translucent blend mode set.

Dither Opacity Mask └─ Blue Noise └─ Screen Coordinate + Frame Index └─ 会随帧变化，适合由 TAA / TSR 积分 传统 Dithered LOD Transition └─ 基于屏幕像素坐标生成稳定随机值 └─ 旧、新 LOD 使用互补判断

Nanite 渲染路径中，不使用传统 Static Mesh 的 Dithered LOD Transition。

Traditional LOD
└─ 几何版本是离散的
   └─ 需要 Dither 隐藏版本切换

Nanite
└─ 几何层级是 Cluster 化、细粒度选择的
   └─ 不使用传统 Dithered LOD Transition

不过，其他 dither 功能不会因此消失：

Nanite Mesh
├─ Dithered LOD Transition
│  └─ 不用于 Nanite 内部 Cluster 层级切换
│
└─ Dither Opacity Mask
   └─ 属于材质 Masked coverage
      └─ 与几何 LOD 切换是不同功能

Dither 本身不是性能优化 Dither = 用额外计算换取更平滑的视觉过渡

Dither Opacity Mask：通常比普通 Opacity Mask 更贵

clip(Mask - 0.333);

Dither Opacity Mask：

采样 Mask
+
根据屏幕坐标、Frame Index 查询蓝噪声
+
Mask 与蓝噪声结合
+
clip

最终是增负还是略有节省，取决于材质、覆盖率、Early Z、平台以及过绘制情况，不能把 dither 本身当成减负功能。

Dither Opacity Mask 成本 = 原有 Mask 成本 + 蓝噪声查询与比较 + discard 带来的执行效率问题 - 被裁剪 fragment 的部分后续工作

GPU 通常按 quad、wave 或 warp 成组执行。

例如一个 2×2 quad：

A 保留    B discard
C 保留    D discard

不一定意味着 B 和 D 一被 discard，计算资源立即全部释放。为了：

ddx / ddy
纹理 mip 选择
SIMD/SIMT 成组执行

这些 lanes 在部分阶段仍然要跟随整个组执行。

LOD 过渡期间，几何成本反而可能上升

假设：

LOD0 = 100,000 triangles
LOD1 = 20,000 triangles

没有过渡时：

近处：只画 LOD0
→ 100,000 triangles

远处：只画 LOD1
→ 20,000 triangles

Dithered LOD Transition 过渡期间：

同时画 LOD0 + LOD1
→ 120,000 triangles 被处理

随后像素阶段：

LOD0 保留部分像素
LOD1 保留互补部分像素

真正降低顶点数的是 LOD 选择完成之后

完整过程是：

阶段 A：近距离

只绘制 LOD0
100,000 triangles

阶段 B：过渡

绘制 LOD0 + LOD1
100,000 + 20,000 triangles

Dither：
LOD0 逐渐减少像素覆盖
LOD1 逐渐增加像素覆盖

阶段 C：过渡结束

停止提交 LOD0
只绘制 LOD1
20,000 triangles

真正的性能收益发生在阶段 C：

LOD0 不再提交
→ 顶点数下降
→ 三角形数下降
→ 光栅化负担下降

Dither 只负责阶段 B 的视觉隐藏。

Motion Matching 可以立刻搜索到向后启动或转身动作，但角色当前身体仍处于向前运动状态。如果动作库没有对应的：

• 急停
• 180° 转身
• 向后启动
• 高速改变方向
• 不同速度下的刹车过渡

它只能从"不完全匹配"的候选里选一个最低 Cost。

官方 IK Batch Retarget 的支持范围是硬编码的。

在 UIKRetargetBatchOperation::GenerateAssetLists() 中，输入资产只接受两类：

if (UAnimationAsset* AnimAsset = Cast<UAnimationAsset>(Asset))
{
    AnimationAssetsToRetarget.AddUnique(AnimAsset);
}
else if (UAnimBlueprint* AnimBlueprint = Cast<UAnimBlueprint>(Asset))
{
    AnimBlueprintsToRetarget.AddUnique(AnimBlueprint);
}

而 UPoseSearchDatabase 是 Data Asset，不是 UAnimationAsset，也不是 UAnimBlueprint。因此把 PSD 交给批量重定向时，它会被直接忽略。

即使勾选 Include Referenced Assets，官方代码也只会：

• 收集 AnimBP 引用的动画；
• 调用 UAnimationAsset::HandleAnimReferenceCollection()；
• 用 ReplaceReferredAnimations() 修复 Montage、BlendSpace 等动画资产内部引用；
• 用 ReplaceReferredAnimationsInBlueprint() 修复 AnimBP 引用。

它没有处理：

Pose Search Database
Chooser Table
Normalization Set
其他保存动画引用的 Data Asset

UMaterialInterface 是一个真正的抽象 UObject 父类：

C++

class UMaterialInterface : public UObject

它的作用是定义：

任何能被当作"材质"塞进 Mesh 材质槽的对象，都必须提供哪些能力。

UObject └─ UMaterialInterface ├─ UMaterial └─ UMaterialInstance ├─ UMaterialInstanceConstant └─ UMaterialInstanceDynamic

因此一个 Mesh 材质槽写成：

C++

UMaterialInterface* Material;

它就可以同时接受：

基础 Material
Material Instance Constant
Material Instance Dynamic

如果材质槽类型写成：

C++

UMaterial* Material;

那它只能接受基础 Material，不能直接接受 UMaterialInstance，因为 UMaterialInstance 并不继承 UMaterial。

hasattr(...) 是什么

这是 Python 表达式，不是 CVar。

hasattr(unreal, "AssetReferenceReplacementLibrary")

意思是：

检查 Unreal 的 Python 模块里，是否已经存在名为 AssetReferenceReplacementLibrary 的类型。

返回：

True  = 插件已加载，Python 找到了函数库
False = 插件未加载，或者反射类型没有注册成功

可以在 UE 底部命令框使用 py 执行：

py print(hasattr(unreal, "AssetReferenceReplacementLibrary"))

这里：

• py：让 UE 把后面的内容交给 Python 执行。
• print(...)：把结果输出到 Output Log。
• hasattr(...)：检查成员是否存在。
• unreal：Unreal Python 提供的模块。
• AssetReferenceReplacementLibrary：我们 C++ 插件暴露的类。

它与 CVar 不同：

CVar
→ 引擎控制台变量
→ 例如 a.MotionMatch.DebugDraw 1

py
→ 执行 Python
→ 例如 py print(unreal.SystemLibrary.get_engine_version())

C++ 类为什么会出现在 Python 中

头文件里写了：

UCLASS()
class UAssetReferenceReplacementLibrary
    : public UBlueprintFunctionLibrary
{
    GENERATED_BODY()

public:
    UFUNCTION(BlueprintCallable)
    static ... ReplacePoseSearchDatabaseAnimationReferences(...);
};

编译时，Unreal Header Tool 会读取：

UCLASS()
UFUNCTION()
UPROPERTY()

并生成反射信息。

Editor 启动并加载插件模块后，Unreal 会注册这个 UClass。PythonScriptPlugin 再把反射类型转换成 Python 类型：

UAssetReferenceReplacementLibrary

在 Python 中去掉 UObject 类常用的 U 前缀：

unreal.AssetReferenceReplacementLibrary

C++ 函数名：

ReplacePoseSearchDatabaseAnimationReferences

在 Python 中通常变成 snake_case：

replace_pose_search_database_animation_references

因此后面可以这样调用：

unreal.AssetReferenceReplacementLibrary \
    .replace_pose_search_database_animation_references(...)

**Chooser 绑定的不是"某个 ABP 资产"，而是该 ABP 生成的实例类型。**例如：

AglinaCharacter_CMC_ABP_slash
        ↓ 编译
AglinaCharacter_CMC_ABP_slash_C
        ↓ 作为 Context 类型
Chooser

绑定这个类型的目的，是让 Chooser 知道运行时可以从传入对象读取哪些数据，例如：

• MovementMode
• Gait
• Stance
• LocomotionMode
• 其他 ABP 变量或函数

于是 Evaluate Chooser 节点会生成一个指定类型的输入 Pin：

Self（slash ABP 实例）
        ↓
Evaluate Chooser
        ↓ 读取 Self 上的状态变量
筛选并返回合适的 PSD

因此它不是给 Chooser"使用 ABP 上面所有节点的能力"。Chooser 通常不能随意执行 AnimGraph 节点；它获得的是：

• 读取该 ABP 类型公开给绑定系统的属性；
• 必要时调用可绑定函数；
• 根据这些值执行表格中的筛选条件。

绑定具体 ABP 类型的代价也很明显：Chooser 的输入 Pin 就被限定成该类型。另一个并列 ABP 即使有完全相同的变量名，类型仍然不同，Self 也接不上。

Bitmain（比特大陆）2013 年成立，主要制造 Antminer 蚂蚁矿机 ，即专门计算 Bitcoin SHA-256 工作量证明的 ASIC 机器。它还在历史上创建过 AntPool 和 BTC.com，不过 Bitmain 官方称两者后来已经拆分独立。​编辑Bitmain

Bitmain
├─ 设计 ASIC 芯片
├─ 制造 Antminer 矿机
├─ 将矿机卖给矿工
└─ 历史上通过矿池和矿机市场影响比特币升级投票

它之所以和后面三个名字经常同时出现，是因为在 2015---2017 年的"区块大小战争"中，Bitmain 联合创始人吴忌寒及其矿池阵营支持扩大区块，2017 年 AntPool 曾公开准备转向 Bitcoin Unlimited。​编辑CoinDesk

Bitcoin XT：激进、预先写好增长时间表

Bitcoin XT 是从 Bitcoin Core 代码分出的另一套完整节点软件。它承载的主要扩容方案是 BIP 101：

Bitcoin XT / BIP 101
└─ 区块上限
   ├─ 从约 1 MB 提高至 8 MB
   ├─ 此后约每两年翻倍
   └─ 最终上升至约 8 GB

它需要最近 1,000 个区块中至少 750 个表示支持，也就是约 75% 算力支持 ，然后才准备激活硬分叉。这个门槛最终没有达到，BIP 101 已关闭，XT 的扩容路线没有成为 BTC 的规则。​编辑BIPs

Bitcoin Classic：先只扩大到 2 MB

Bitcoin Classic 是后续较温和的方案。它没有像 XT 那样直接跳到 8 MB，而是主张先进行一次明确、有限的扩容：

Bitcoin Classic / BIP 109
└─ 区块上限
   └─ 1 MB → 2 MB

BIP 109 同样规定约 75% 算力触发，随后留出 28 天升级期；它还增加了签名运算和哈希计算限制，避免两兆字节区块被构造成极其消耗 CPU 的攻击载荷。该方案最终也没有在 BTC 网络激活。​编辑BIPs

不要把它和 Bitcoin Cash 混为一谈：

Bitcoin Classic ≠ Bitcoin Cash

Classic 主要是一套没有成功激活的 BTC 客户端和协议修改方案，并不是今天仍在交易的一种主流币。

Bitcoin Unlimited：不由开发者写死统一上限

Bitcoin Unlimited 的思路比前两个更根本：

Bitcoin XT
└─ 开发者写好增长曲线

Bitcoin Classic
└─ 开发者写死 2 MB

Bitcoin Unlimited
└─ 不设统一固定答案
   ├─ 节点选择愿意接受的最大区块
   ├─ 矿工根据市场和其他矿工调整
   └─ 通过 Emergent Consensus 形成实际大小

也就是把决定权更多交给矿工、节点和市场，而不是由 Bitcoin Core 开发者在代码中规定一个所有人统一遵守的固定上限。Bitcoin Unlimited 官方将其理念概括为市场驱动决策、Emergent Consensus，以及给予用户选择。​编辑GitHub

但这里存在一个严重的协议问题：不同节点如果设置了不同的可接受区块大小，就可能对同一个大区块作出不同判断：

矿工产生 4 MB 区块
├─ 接受上限 ≥ 4 MB 的节点：认为区块有效
└─ 只接受 ≤ 1 MB 的节点：认为区块无效
                         ↓
                    网络可能分链

Unlimited 最终没有取代 Bitcoin Core 成为 BTC 的主导实现。2017 年 Bitcoin Cash 分叉出现后，Bitcoin Unlimited 转向成为 Bitcoin Cash 生态中的一种完整节点实现；其当前代码说明也主要将自己描述为支持 Bitcoin Cash 的软件。​编辑GitHub

• 抑制、壓制(常用於比喻)------regulations that throttle economic growth(抑制經濟成長的法規)
• (技術用語)節流、限制流量------throttle bandwidth(限制頻寬)

a worker in a skilled trade, especially one that involves making things by hand.

"street markets where local artisans display handwoven textiles, painted ceramics, and leather goods"

Slack 本质上是公司/团队内部用的聊天和协作平台 ，类似"企业版 Discord + 微信群 + 邮件 + 项目讨论记录"。它不是给普通朋友聊天用的，主要服务工作团队。​编辑Slack+1

你截图里的意思是：

把 Slack 接入 ChatGPT，让 ChatGPT 可以读取 Slack 里的消息、频道、文件、讨论线程等上下文，帮助工作。

比如一个游戏公司：

Slack Workspace（公司空间）

├── #character-team
│     ├── 美术讨论角色A
│     ├── FBX导入问题
│     └── 文件链接
│
├── #rendering
│     ├── Nanite问题
│     ├── Shader优化讨论
│     └── RenderDoc截图
│
├── #release
│     ├── 版本计划
│     └── Bug列表
│
└── 私聊
      └── 程序员 ↔ 美术沟通

Slack把这些长期保存，并且可以搜索。它的核心设计就是：

人
 ↓
频道(Channel)
 ↓
消息(Thread)
 ↓
文件/链接/机器人/App
 ↓
团队知识库

FactSet AI-Ready Data

FactSet 是传统机构投资数据库。

例如：

你问：

NVIDIA 最近5年的收入增长是多少？

它可以提供：

Revenue:
2021  $26B
2022  $27B
2023  $60B
2024  $130B
...

以及：

• EPS

• P/E

• Analyst estimates

• 财报数据

"AI-Ready"意思是：

数据已经整理成适合 AI 查询的结构。

不是说它里面有 AI 股票。

Public Equity Investing Connector ，大部分不是普通用户注册一个账号就能免费获得完整数据的服务。

大致情况：

服务	普通人能否免费注册	专业数据通常是否收费
PitchBook	可以了解，但完整数据库基本不开放给个人	是，昂贵的机构订阅
FactSet	可以注册了解产品	是，主要卖给机构
Morningstar	有免费账户	高级数据、评级、研究报告收费
LSEG（Reuters 数据）	Reuters新闻部分免费	金融终端/数据 API 收费

---

具体区别：

Morningstar

最接近普通用户。

例如：

免费：

• 股票基本信息

• 部分基金资料

• 新闻

付费：

• 深度估值

• 基金评级细节

• 研究报告

很多大公司不用 Slack，而用 Teams。

微软企业聊天工具。

SharePoint

SharePoint
Read and write

微软企业文件系统。

可以理解：

公司内部 Google Drive

Third Bridge

Third Bridge
Read

比较特殊。

它提供：

行业专家访谈数据库

例如：

投资机构想研究：

电动车供应链怎么样？

他们可以买：

• 汽车行业专家访谈

• 前员工访谈

• 行业分析

Alpaca

Alpaca
Read and write

这个和其他不一样。

它是：

股票交易 API

类似：

给程序连接股票账户。

可以：

• 查询账户

• 获取行情

• 自动交易

所以它有：

Read and write

因为可能涉及执行操作。

很多 B2B（企业服务）公司在 YouTube 上几乎没人关注，但在行业里非常重要。

circuit 不是「日常流通」的意思,而是取「巡迴、圈子」的引申義:

英文裡 circuit 除了「電路」之外,還有一個常見比喻用法是「(某個領域人士活動的)巡迴圈、社交圈」,類似:

• the lecture circuit(巡迴演講圈)
• the comedy circuit(喜劇演出圈)
• the social circuit(社交活動圈)

"The Circuit" 作為節目名稱,暗示這是一個「帶你走訪科技/商業圈重要人物」的節目,比較接近「科技圈巡禮」的概念,而非字面上「電路」或「日常流通」的意思。

彭博社(Bloomberg)由 Emily Chang 主持的一個訪談節目名稱,

"the Architect of ChatGPT"

這裡的 architect 不是「企業架構師」,而是比喻用法,指「(這個東西的)締造者、主要設計者」------修飾的是 Mira Murati 這個人(她曾任 OpenAI CTO),意思是「ChatGPT 的締造者/幕後推手」。architect 字面是「建築師」,引申為「(計畫、系統、政策等的)主要設計/推動者」,常見用法如:

• the architect of the peace deal(和平協議的締造者)
• the architect of modern economic policy(現代經濟政策的設計者)

一个基金经理可能同时开：

Bloomberg Terminal
        |
        |-- 看实时市场
        |-- 看新闻
        |-- 联系交易员


FactSet
        |
        |-- 做财务模型


PitchBook
        |
        |-- 看私募机会


Third Bridge
        |
        |-- 听行业专家


Excel / Python
        |
        |-- 自己计算

Bloomberg Terminal 有内部聊天系统。

很多交易员直接：

交易员A
    ↓ Bloomberg Message
交易员B

这形成了金融行业内部通信网络。

​

Salomon Brothers
└─ 以债券交易著称的华尔街证券商
   └─ Michael Bloomberg
      ├─ 做过机构股票大宗交易
      └─ 后来负责内部信息系统
         └─ 看到交易员真正缺的不是"更多新闻"
            而是：
            ├─ 报价
            ├─ 证券主数据
            ├─ 收益率计算
            ├─ 历史数据
            └─ 能立即操作这些数据的终端

Salomon Brothers 当时尤其以债券业务闻名；Michael Bloomberg 在那里既接触过交易，也负责过信息系统。因此，他创建的产品天然不是面向普通股民，而是按照银行、券商和大型机构交易台的工作方式 设计的。​编辑The New Yorker+1

1981 年，Salomon Brothers 被 Phibro 收购后，Bloomberg 离开公司，拿到约 1,000 万美元的合伙权益结算，和几名原 Salomon 同事成立了 Innovative Market Systems。准确说，Bloomberg 的公司成立于 1981 年 ，不是我前面含糊提到的 1979 年。​编辑WIRED+1

原本： 一家银行自己的内部信息优势 变成： 一家不直接参与证券做市的独立数据公司 为许多彼此竞争的银行和机构提供同一套系统

今天大众看到的顺序容易造成错觉：

大众看到：
Bloomberg News
└─ 以为它是一家新闻社
   └─ 顺带做了一个金融终端

a small particle rubbed off by a file when smoothing or shaping something.

"iron filings"

• iron filings(鐵屑)------物理課常做的實驗,用磁鐵吸鐵屑來觀察磁場線
• metal filings(金屬屑,泛指各種金屬打磨/銼削下來的碎屑)

動詞 file(銼、磨),

不同詞源的同形詞(homograph),恰好拼字相同,意思完全無關,

"CMDs" 在財經/投資語境裡通常是 Capital Markets Day(資本市場日)的縮寫。

Capital Markets Day 是什麼:

上市公司定期(通常一年一次或幾年一次)舉辦的活動,邀請分析師、機構投資人、媒體參加,管理層會深入說明公司的:

• 長期策略與願景
• 財務目標與展望(guidance)
• 各事業部門的表現與規劃
• 資本配置計畫(股利、回購、投資方向等)

earnings calls(財報電話會議)------每季公布財報後,管理層跟分析師的電話會議

CMDs(Capital Markets Day)------較深入、較不頻繁的策略說明會

conferences(產業會議/投資人會議)------如摩根大通、高盛等券商舉辦的產業論壇,多家公司同台

inflection point(名詞片語)= 轉折點、拐點

spot(動詞)= 發現、識別出(口語,比 identify 更輕快)

inflection point 詳解:

這是個借自數學/物理的比喻用法:

• 原意(數學):函數圖形上「凹凸性改變」的那個點(曲線從凹向上轉成凹向下,或反之)
• 商業/投資引申義:事情發生根本性轉變 的關鍵時間點,常用來形容:
  • a company at an inflection point(公司處於轉折點,可能是成長加速、策略轉向、獲利模式改變等)
  • the inflection point in the market(市場的轉折點)

(公司)隨時間在對外說法(messaging) 、關鍵績效指標(KPIs)、**策略重心(strategic focus)**上的變化」

• ER = Earnings Release(財報發布)或 Earnings Report(財報)
• EPS = Earnings Per Share(每股盈餘)

KPI = Key Performance Indicator

YoY / QoQ = Year over Year / Quarter over Quarter(年增率/季增率)

同一家公司在其他渠道的数据完全不同：

Quartr
├─ YouTube：88 subscribers
├─ LinkedIn：约 36,000 followers
├─ 移动 App：公司称累计下载超过 100 万
├─ 企业及技术客户：公司称超过 700 家
├─ 团队：140+ 人
└─ 覆盖：15,000+ 上市公司、65+ 市场

更准确的层级是：

Bloomberg / LSEG / FactSet
├─ 大型综合金融信息平台
├─ 行情、基本面、新闻、分析工具
├─ 机构通信与工作流
└─ 数十年积累的金融基础设施

Quartr
└─ 专门处理上市公司 IR 原始材料
   ├─ 电话会议
   ├─ Transcript
   ├─ Filings
   ├─ Slides
   └─ 面向 AI 的结构化接口

Quartr 官方明确写明：通过 ChatGPT/Codex 使用 Quartr，必须有有效的 Quartr Pro subscription ；普通免费账户不能使用这套集成。Quartr+1

这场真正补充了官方页面缺少的"整体因果链"

官方 Material Properties 页面会告诉你：

Used with Skeletal Mesh
Used with Niagara
Used with Clothing
Automatically Set Usage in Editor

以及"启用某个 Usage Flag 会编译相应 Shader"。Epic Games Developers

但这场演讲把实际乘法关系说清楚了：

Material Shader 数量 ≈ Material / 独特静态参数组合 × Vertex Factory Type × Shader Type × Quality Level × Shader Model

其中：

Usage Flag
└─ 决定该 Material 要支持哪些 Vertex Factory
   ├─ Skeletal Mesh
   ├─ Niagara
   ├─ Clothing
   ├─ Instanced Static Mesh
   └─ 其他 Primitive Type

Static Parameters
└─ 决定同一个 Parent Material 生成多少个独特静态配置

所以 Parent Material 增加一个 Usage Flag，效果并不是：

增加 1 个 Shader

而更接近：

新增 Usage Flag
└─ 每个独特 Material Instance 静态配置
   └─ 都增加一整组对应 Vertex Factory × Shader Type 的 Shader

演讲用三个独特 Material Instance、两个 Usage Flag 举例：已经形成六组 permutation；Parent 再加一个 Usage Flag，会给三个实例分别增加一组，而不是只增加一次。

官方 Shader Development 页面解释了 FMaterialShaderMap、FVertexFactoryType、FMeshMaterialShaderType 和 ShouldCache/ShouldCompilePermutation 的源码关系，但没有像演讲这样连接到美术资产层的实际失控过程。Epic Games Developers

replicate └─ 產生一個對應副本，使某個狀態在另一處重現 network replication └─ 透過網路，讓另一台機器上的副本保持相應狀態

你這張圖中的 AC Traversal Logic 是一個 Actor Component 引用節點。要讓它變成帶有那兩個白球的 Replication 狀態：

打開擁有它的 Character／Actor Blueprint
└─ Components 面板
   └─ 選中 AC Traversal Logic
      └─ Details
         └─ Component Replication
            └─ Replicates／Component Replicates = Enabled

要真正通過網路複製，外層 Actor 也必須打開：

Character／Actor Blueprint
└─ Class Defaults
   └─ Replication
      └─ Replicates = Enabled

完整條件是：

Owning Actor：Replicates
└─ AC Traversal Logic：Component Replicates
   └─ Component 才能跟隨 Actor 的網路通道
      ├─ 複製 Component 內的 Replicated Properties
      └─ 執行 Component 類別中定義的 RPC

Actor Component 預設不參與複製；官方要求其 Owner Actor 和 Component 本身都啟用複製。

以 UE 的 Health 為例：

Server 記憶體
└─ ServerCharacter.Health = 80

Client A 記憶體
└─ ClientCharacter.Health = 100

Client B 記憶體
└─ ClientCharacter.Health = 100

Server 發送更新後：

網路封包：Health → 80
├─ Client A 本地 Health 改成 80
└─ Client B 本地 Health 改成 80

這三個 Health 位於不同程序、甚至不同實體電腦的記憶體中，根本不可能是同一個記憶體引用。UE 官方描述也是：Server 發送更新，每個 Client 把新值套用到自己的本地 Actor 版本。​编辑Epic Games Developers+1

因此最準確的對照是：

Duplicate
= 建立副本

Replication
= 建立／維持分散在不同位置的對應副本

Reference
= 指向同一個記憶體物件

還要注意，Replication 也不是毫無延遲、每次修改都完整同步：

Server：10 → 20 → 30
Client 可能只收到：30

Property Replication 保證 Client 最終會反映 Server 的權威值，但不保證 Client 看到 Server 上每一次中間變化。

你把「每個型號一款電池」近似理解成了「每個型號都要重新建立一套電池產業」。實際上不是。真正昂貴的生產系統被大量共用，單一型號主要改的是尺寸、接口和封裝。

每款手機需要專用的，主要是：

外形尺寸
＋電極耳位置
＋排線形狀
＋接頭
＋電氣參數
＋識別／通訊要求

而不是每個型號都重新發明正極、負極、電解液和整套生產線。

軟包電芯工廠本來就能在同一套塗布、分切、疊片或卷繞、封裝、化成設備上製造很多尺寸。改一款尺寸仍然需要模具、參數調整和測試，但成本遠低於為一款手機建新工廠。ATL甚至把自己的消費電池能力描述為既能提供電芯，也能提供電池包設計、製造、測試和認證的一站式方案；德賽電池的核心業務則包含電源管理系統和電池封裝整合。​编辑ATL Battery+1

同一塊原廠電池也不一定全部由一家公司完成：

公司 A：製造電芯
公司 B：製作保護板與電源管理系統
公司 C：把電芯、排線、框架組裝成 Battery Pack
手機品牌：完成認證並貼原廠料號

也可能由欣旺達、ATL這類具備完整能力的企業一體化完成。

圖中帝彪這類是另一條「副廠售後鏈」

第三方品牌通常不參與手機最初的設計，而是在手機上市後做反向適配：

購買原廠電池和手機
↓
測量尺寸、厚度、接頭、極性和識別方式
↓
尋找相應尺寸的電芯或委託生產
↓
重新製作 FPC、保護板、接頭和固定結構
↓
委託電池包工廠組裝
↓
貼帝彪、品勝、諾希等零售品牌
↓
電商銷售＋拆機影片＋售後

因此，「帝彪電池」不必意味著帝彪自己擁有從電極材料到電芯化成的完整工廠。它可能掌握的是產品定義、適配、採購、品質抽檢、品牌和銷售，而實際電芯及電池包由合作工廠生產。

目前公開資料只能把帝彪產品與「深圳市豐達強通科技有限公司」等經營資訊聯繫起來；相關市場抽檢資料使用的是「生產者或經銷者」欄位，因此不能據此確認其真正的電芯製造廠。​编辑Cpqr

一款手機只需很小的更換比例

做一個純示意計算：

某型號市場存量：100 萬台
一年內選擇第三方換電池：0.5%
需求量：5,000 塊

每塊零售價：60～100 元
單一 SKU 年銷售額：30萬～50萬元

0.5%看上去極低，但手機基數足夠大。品牌同時經營幾十或幾百個有效 SKU，就能形成業務。