自由学习记录（176）

​

2026 年官网已经更新到 2025 年报和 2026 年股东大会资料。

资产负债表、利润表、子公司业务、保险浮存金、股票持仓、公允价值变化、现金规模、回购政策等。不要只看新闻总结，要直接看年度报告。伯克希尔官网有年度和季度报告页面。

股东信比财报更好读。伯克希尔官网有 1965 年以来的巴菲特股东信页面；2026 年官网也列出了 Greg Abel 的股东信入口，因为巴菲特已经开始交棒。

​

​

​

而 UPrimitiveComponent 是 USceneComponent 的子类，表示"有几何表达"的 Scene Component，通常用于渲染或碰撞。Epic Games Developers

所以层级大概是：

UActorComponent

└─ USceneComponent

└─ UPrimitiveComponent

├─ UStaticMeshComponent

├─ USkeletalMeshComponent

├─ UBoxComponent / USphereComponent / UCapsuleComponent

├─ UBillboardComponent

└─ ...

UBillboardComponent 本质上属于 PrimitiveComponent 体系，所以它会显示很多 On Component Hit、On Component Begin Overlap、On Clicked、On Begin Cursor Over 这类事件。

Billboard1 → On Component Begin Overlap
Spline1    → 可能没有同样的碰撞事件，或者即使有，也取决于它是否具备可碰撞/可查询能力
BoxCollision → On Component Begin Overlap
StaticMesh → On Component Hit

如果你在 Billboard1 的 Details 里点 On Component Begin Overlap 的 +，生成的节点通常会带组件名：

OnComponentBeginOverlap (Billboard1)

这表示：只有 Billboard1 这个组件发生 overlap 时，才执行这个事件图逻辑。不是 Actor 上任意组件 overlap 都触发。

On Component Hit 是"阻挡型接触事件"。两个物体发生 blocking collision，且相关设置允许生成 hit event 时触发。官方文档也区分了 blocking collision 的 Hit 和 overlap 的 Overlap；物理模拟生成 hit 还需要对应 collision 设置。Epic Games Developers

它的真实用途不只是"撞墙打印文字"，而是：

投射物撞到表面 → 生成弹孔、火花、Decal、声音

物理物体撞地 → 根据冲击速度播放不同强度音效

车辆轮胎/底盘碰撞 → 反馈冲击、损伤、震动

武器挥砍命中可破坏物 → 触发碎裂或受击逻辑

On Component Begin Overlap / End Overlap 是"非阻挡接触范围事件"。官方文档说 Begin Overlap 是某物开始 overlap 这个组件时调用，典型例子是玩家走进 trigger；如果是 blocking 碰撞，则应该看 Hit 事件。

进入 AI 感知区域 → 激活警戒逻辑

进入交互范围 → 显示 Press E 提示

角色进入风场/水体/毒雾区域 → 添加状态或环境力

物体进入传送门体积 → 开始准备传送

武器攻击判定盒扫过敌人 → 记录命中

并不一定是碰撞表现：

On Clicked / On Released / Cursor Over 属于输入拾取/鼠标交互事件。它们依赖 PlayerController、碰撞查询、鼠标事件设置、组件可被 trace 到等条件。用途通常不是物理，而是编辑器式、RTS、点击交互式逻辑：

点击场景里的 Actor 或组件 → 选中单位

鼠标悬停到交互物 → 高亮轮廓

点击建筑部件 → 打开属性 UI

拖拽控制点、样条点、机关把手

Wake / Sleep / Physics State Changed 是物理状态事件。不是"碰撞发生"，而是物理对象从休眠到激活，或从运动状态进入休眠。用途偏系统层：

刚体休眠 → 停止循环音效或粒子

大量碎片静止后 → 降低更新成本

一个机关 Actor 里可能有：

Root SceneComponent：只负责空间层级，不负责碰撞
StaticMeshComponent：显示机关主体
BoxCollision：检测玩家是否靠近
SphereCollision：检测是否有可吸附物体进入范围
BillboardComponent：编辑器中显示图标
SplineComponent：定义移动路径

这时你不会把所有事件都写在 Actor BeginOverlap 里。你会让不同组件各自处理自己的职责：

BoxCollision BeginOverlap → 玩家进入交互范围

SphereCollision BeginOverlap → 可吸附物进入磁场范围

StaticMesh Hit → 被投射物击中

Spline → 不负责碰撞事件，只提供路径数据

Billboard → 通常只作为编辑器视觉标记，不参与运行时逻辑

一个对象 = 空间层级 + 可视表现 + 交互检测 + 路径数据 + 物理反馈 + 编辑器辅助 + 调试接口

聚焦到全局是home 键，也就是小数字键盘的7 ，按下num切换成非数字模式，可以聚焦到整个节点图

Blueprint 的运行时事件逻辑没有写在 Event Graph 里 ，它的主要逻辑写在 Construction Script / UserConstructionScript 里。

这份 Graph 是在构造阶段沿 Spline 自动添加 Static Mesh Component。也就是你改 Number of meshes、移动 Spline 点、拖动 Actor、刷新蓝图时，它会重新构造出一串 Mesh。UE 官方文档把 Construction Script 定位为 Blueprint 实例创建时、组件列表之后执行的脚本；它适合用来初始化或根据参数搭建 Actor 结构。Unreal Engine

不会依赖 BeginPlay 才开始生成 。

如果逻辑在 Event Graph 的 BeginPlay，那通常是 Play 以后才执行。

但你这里在 Construction Script，所以你在编辑器里就能看到它生成出来的组件布局。

这解释了为什么你打开 Event Graph 是空的，但场景里仍然有"自动沿样条线摆模型"的效果：
因为这个效果不是由 Event Graph 驱动，而是由 Construction Script 驱动。

运行时是否还会执行，要谨慎区分。

​

DLSS Super Resolution ：低分辨率渲染，再用 AI 放大到目标分辨率。这里才有 Quality / Balanced / Performance 这些档位。NVIDIA 官方文档也把 DLSS Super Resolution、DLAA、Frame Generation、Ray Reconstruction 作为不同功能模块来说明。NVIDIA Developer+1

Balanced 意味着：游戏不是按显示器原生分辨率完整渲染，而是用较低内部渲染分辨率，然后 DLSS 放大。Quality 更清晰但帧数少一点；Performance 帧数更多但更容易糊、闪、拖影或细节不稳。

DLAA，它比较特殊：它不属于"提高帧数"的 DLSS 用法，而是"用 DLSS 的 AI 技术做抗锯齿"。

Frame Interpolation / Frame Generation 是另一类东西：

DLSS 4/4.5 之后 NVIDIA 还把模型、覆盖预设、Multi Frame Generation 等做得更细，甚至可通过 NVIDIA App 对已有游戏启用部分 DLSS 覆盖功能。

从游戏渲染管线角度看，它们争的是同一个位置：最终图像重建 / 抗锯齿阶段。

3D 场景渲染 → 得到一张低分辨率或原生分辨率画面 → 用某种方法做重建/抗锯齿 → 输出到屏幕。

DLSS Super Resolution 的 Quality / Balanced / Performance，以及 DLAA，都是在这个"重建/抗锯齿"位置工作，所以只能选一个。

DLAA：内部渲染分辨率 ≈ 屏幕分辨率。它主要做 AI 抗锯齿和细节重建，目标是画质，不是提帧。

Quality / Balanced / Performance：内部渲染分辨率低于屏幕分辨率。然后 DLSS 把它升采样回屏幕分辨率。Quality 内部分辨率较高，Performance 内部分辨率更低。

DLAA 和 DLSS SR 的目标输出相同。两者都会接管最终抗锯齿/重建。如果你先用 Performance 升采样，再套 DLAA，等于对已经重建过的画面再重建一次，容易引入额外模糊、鬼影、锐化冲突和时间稳定性问题。

它们需要不同的输入分辨率假设。DLAA 假设输入基本是原生分辨率；Quality / Balanced / Performance 假设输入是不同倍率的低分辨率图。Unity HDRP 的 DLSS 设置也是把它作为一个 Mode 属性选择，而不是多个并列开关，这正是因为这些模式互斥。

https://docs.unity3d.com/Packages/com.unity.render-pipelines.high-definition%4017.3/manual/deep-learning-super-sampling-in-hdrp.html?utm_source=chatgpt.com

UI 上放在一个下拉菜单，是为了表达"选择一个重建策略"。不是"开不开 DLSS"，而是"这一帧的最终重建由哪种 DLSS 模式负责"。

"Anti-Aliasing" 不是一个单独动作，而是一类方案。你不能同时选择 TAA、FXAA、MSAA、DLAA、DLSS Quality 作为最终 AA，因为它们都会处理同一个图像阶段。游戏通常让你选其中一种主方案。

而 Frame Interpolation / Frame Generation 之所以单独一行，是因为它不在同一个阶段。它是在两帧之间生成额外帧，和 Super Resolution/DLAA 可以组合使用。

DLAA最高最低原生分辨率 + AI 抗锯齿，不做升采样

需要在 chrome://extensions 里点击这个扩展的 Reload/重新加载，只刷新 YouTube 页面不够，因为 CMk9RVmh.js 是 background service worker，旧版本可能还在跑。

原本快，主要可能是因为旧逻辑不是"浏览器直接下载 YouTube 临时直链"，而是走了更成熟的服务端链路。

几个关键差异：

1. 服务器可能做了代理/中转

   以前远程服务拿到 YouTube 源后，再由服务器或 CDN 发给用户。服务器带宽、机房线路、连接复用可能比你本地浏览器直接连某个 googlevideo.com 节点更稳定。

2. 服务器可能做了多线程分片

   Chrome 扩展的 chrome.downloads.download() 通常就是普通下载。旧服务端如果用了 range 分片、并发拉流、断点续传、缓存，就会明显更快。

3. 服务器可能会选更好的客户端/格式

   旧逻辑也许会用特定 YouTube client、刷新签名、处理 n 参数、选更快的 CDN 节点或备用 host。现在免费版兜底主要是拿"能用的直链"，不一定是最快的直链。

4. 旧服务可能有缓存

   热门视频如果服务器已经下载过或部分缓存过，用户下载其实是在从你的服务器拿文件，而不是实时从 YouTube 拉。

5. 浏览器直链更容易被限速

   YouTube 对非播放器下载、长连接、大文件、某些 client 直链可能会限速或返回 403。服务器端实现通常会更容易控制 headers、range、重试和 fallback。

简单说：原本快，不一定是 gating 本身的原因，而是 gating 后面的远程下载基础设施承担了"解析 + 加速 + 稳定化"。

做本地多线程下载器

浏览器自己的 chrome.downloads.download() 很难做出专业下载器速度。要明显提速，需要自己实现：

• 对 googlevideo URL 发多个 Range 请求。
• 并发下载分片。
• 本地合并文件。
• 失败分片重试。
• 下载前测试多个候选 URL，选最快的。

但纯 Chrome 扩展里做这个比较麻烦，MV3 service worker 生命周期、文件写入、长时间下载都不舒服。更靠谱的是配一个 native helper，比如本地 yt-dlp / aria2 / Node helper，通过 Native Messaging 调用。

缺点是用户需要安装额外组件，不像普通扩展那么轻。

并发 Range 拉流

大文件下载慢时，常见优化是把文件切成多个 byte range：

Range: bytes=0-10485759 Range: bytes=10485760-20971519 Range: bytes=20971520-31457279

后端同时拉多个分片，再按顺序合并。这样可以：

• 跑满带宽
• 避免单连接限速
• 某个分片失败时只重试该分片
• 做断点续传

浏览器 chrome.downloads.download() 基本是把 URL 交给 Chrome 下载，控制力弱很多。

缓存

缓存能解决两个问题：

• 热门视频不用每个用户都重新从 YouTube 拉
• 同一个用户重复下载不用重新解析和下载

如果服务器已经缓存了文件或分片，用户实际是在从你的服务器/CDN 下载，速度通常更稳定。

重试

YouTube 链接失败原因很多：403、429、连接超时、CDN 节点慢、range 请求失败、签名过期。后端可以做细粒度重试：

• 当前 URL 403，刷新 player response
• 当前 CDN host 慢，换备用 host
• 某个 range 分片失败，只重试这个分片
• 当前 client 失败，换 Android/iOS/Web client

扩展直接下载时，失败通常就是失败，最多重新点一次。

选节点

googlevideo.com 会分配不同 CDN host，比如 rr1---sn-*、rr5---sn-*。不同节点速度差异很大。后端可以对多个候选 URL 或 host 做小 range 测速，选最快的那个。

所以总结一句：

后端的价值不是"绕过付费"，而是把 YouTube 临时媒体链接变成一个稳定、可加速、可恢复的下载任务。

​

Post-Processing：如果游戏把接触阴影、屏幕空间阴影、环境遮蔽、体积雾、泛光、景深等都归到后处理里，阴影观感可能会受它影响。但严格来说，传统 Shadow Map 本身不一定属于 Post-Processing。

View Distance：远处物体、草、建筑、NPC 是否投影，阴影绘制距离，常常和这个绑定。你把 View Distance 调到 Very Low，远处阴影、远处物体的投射关系很可能会被裁掉。

Foliage：草、树叶、灌木的数量、LOD、动画、阴影开关经常归在这里。很多游戏最耗的是植被阴影，不单独叫 Shadow，而是跟 Foliage 档位绑定。

Rendering Accuracy 或类似选项：有些游戏把阴影分辨率、SSR、AO、光照质量、特效精度归到一个综合渲染精度选项里。

游戏为了简化 UI，把阴影质量做成自动档；或者这个游戏美术风格不依赖复杂实时阴影；或者为了移动端/多平台兼容，把阴影和整体质量预设绑定了。

Texture 一般指"贴图质量/贴图分辨率"

Texture Mapping 更像是"贴图采样/贴图映射方式"，很多游戏里它实际对应的是各向异性过滤、mipmap 偏移、纹理流送策略，或者材质贴图如何贴到模型表面的质量。它影响的不是贴图文件本身的分辨率，而是贴图在斜角、远处、运动中看起来是否清楚稳定。

很多 PC 游戏里，Texture Mapping 可能对应的是 Anisotropic Filtering。如果是这样，它对性能影响通常很小，但对斜视角地面清晰度影响明显。

Rendering Accuracy 或类似选项：有些游戏把阴影分辨率、SSR、AO、光照质量、特效精度归到一个综合渲染精度选项里。

Roblox 不是单纯"一个游戏"，也不是传统意义上和 Unity、Unreal 并列的通用游戏引擎。更准确地说，它是一个 UGC 游戏平台 + 自家引擎 + 创作工具链 + 分发/社交/支付生态。

它包含几层东西：

Roblox 客户端：玩家用来进入各种体验/小游戏。

Roblox Studio：创作者做内容的编辑器，有点像简化封装后的游戏开发工具。

Roblox Engine：运行物理、动画、网络同步、渲染、脚本逻辑的引擎层。

Roblox Cloud：账号、服务器、多人体同步、资产、数据存储、经济系统等平台服务。

Luau：Roblox 使用的脚本语言，接近 Lua，但做了类型系统和性能扩展。

Roblox 是你在 Roblox 平台里做"Experience"，发布、联机、社交、变现都在它自己的生态内完成。

最近这波讨论，主要是因为 Roblox 公布了一个叫 Roblox Reality 的方向。官方说这是一个混合架构：用 Roblox Engine / Roblox Cloud 维护游戏世界的"真实状态"------例如玩家位置、物理、碰撞、分数、同步、规则；再用边缘端的 Video World Models 做类似"超采样/视觉生成"的层，把传统 Roblox 画面变成更写实的实时视觉输出。官方把它描述为面向多人写实体验的混合架构，早期版本计划在今年晚些时候或明年初推出。

这和传统游戏引擎的关键差异是：传统引擎通常是"几何体、材质、灯光、阴影、后处理"一步步渲染出画面；Roblox 这个方向更像是"引擎只负责可验证的游戏逻辑和世界状态，AI 模型负责把结果视觉化得更真实"。所以很多人会把它类比成"DLSS 的更激进版本"，但它不只是普通升采样。DLSS Super Resolution 主要是从低分辨率重建到高分辨率；Roblox Reality 想让 AI 根据世界状态生成更丰富的真实感细节，比如雨水、叶片、灰尘、材质观感等。这个比普通 DLSS 更接近"视频世界模型参与最终画面生成"。

为什么开发者会吵？核心争议有三点。

第一，这会模糊游戏引擎和生成式视频的边界。开发者熟悉的是可控资产、可控 shader、可控光照、可调性能预算。AI 生成视觉层之后，画面更像一个模型输出，精确可控性、稳定性、可调试性都变复杂。

第二，它可能改变创作价值链。如果平台能把普通 Roblox 场景"AI 写实化"，那传统建模、材质、灯光、环境美术的门槛会下降；但同时也可能让很多人工美术工作被平台级 AI 吸收。

第三，多人游戏对一致性要求很高。AI 生成视频可以很好看，但游戏不是视频。玩家 A 看到的掩体、阴影、烟雾、障碍物，玩家 B 也必须一致，否则会影响公平性。Roblox 官方强调用 Engine/Cloud 保存"结构化世界状态"，AI 只做视觉层，正是为了解决这个问题。

另外，Roblox 最近不只是 AI 渲染这一件事。它还在推进 AI 创作工具，例如 Cube/4D creation，用自然语言生成可交互的模型或对象；Reuters 报道过 Roblox 在 2026 年推出 4D creation beta，让用户用自然语言生成具备物理和交互能力的游戏内模型。Reuters

同时 Roblox 也因为儿童安全、年龄验证、沟通限制等问题受到很大压力。Reuters 今天的报道提到，Roblox 下调了 2026 年 bookings 预期，原因之一是新的安全功能影响了沟通参与度、传播和平台指标；但它的 Q1 日活仍同比增长到 1.32 亿。Reuters

​

CDPR 是 CD Projekt Red，波兰游戏开发商，最知名作品是：

《巫师》系列，尤其是 The Witcher 3: Wild Hunt

《赛博朋克 2077 / Cyberpunk 2077》

《赛博朋克 2077：往日之影 / Phantom Liberty》

CDPR 曾经展示过一个市场场景，里面有大量 NPC，大概几百个角色在同一个区域活动，好像每个人都有自己的行为、路线、生活状态、互动逻辑。这个演示给人的感觉是：这个城市不是单纯的背景板，而是一个有密度、有行为深度的开放世界。

​

Epic 正在做的下一代动画运行时框架，目标是逐步替代 Animation Blueprint。UE 5.7 里它已经能看到 API / Experimental 插件痕迹，但官方 5.7 技术博客明确说：原本计划发布 UAF 示例内容，但推迟了；预计 UE 5.8 才会展示 GASP 角色的纯 UAF 设置，而且 5.8 仍然会是 Experimental。

ABP 默认密度下，大概 16 个 MetaHumans，Game Thread animation 花 1.24 ms。

UAF 最大密度下，大概 263 个 MetaHumans，Game Thread animation 仍然只有 1.35 ms。

大量动画工作不再以同样方式压在 Game Thread 上。也就是说，性能提升主要来自架构换代，不是单个节点优化。

ABP 为什么容易贵？因为传统 Animation Blueprint 不是只负责"播动画"。它通常混在一起处理很多东西：状态机、BlendSpace、Montage、Layered Blend、IK、Control Rig、Root Motion、Anim Notify、曲线、同步组、蓝图逻辑、角色组件之间的数据读写。单个角色还好，几十上百个角色同时跑，就会变成大量分散对象、虚函数、图节点调度、数据依赖、Game Thread 同步、缓存不友好的访问。

角色组件状态又来自 movement / AI / gameplay；

Root Motion 可能要反馈到 Actor movement；

Notify 可能触发 gameplay；

Control Rig / IK 可能还要读世界碰撞或目标位置；

最后结果要写回 Skeletal Mesh。

动画系统就不再是一个纯粹可并行的"输入姿势 → 输出骨骼姿势"的函数，而变成了和 Game Thread 紧耦合的一坨执行逻辑。

传统 ABP 更像"每个角色一个复杂对象图"，而 UAF 更像"把动画逻辑编译/组织成更紧凑的数据和任务"。这对 CPU cache 很关键。几百个 NPC 时，cache miss 往往比算术成本更致命。UAF 如果能让同类动画节点、同类 trait、同类数据连续处理，就会明显减少随机访问。

Root Motion / Motion Matching / Control Rig 等被重新纳入统一框架 。

以前这些功能经常像外挂模块一样接在 ABP 旁边：能用，但数据流不总是干净。UAF 的目标是让这些东西成为动画运行时的一等组成部分，而不是每个系统单独和 Game Thread 交换状态。Epic 5.7 的 GASP 技术博客也提到，他们正在把多个 procedural nodes 移到 Control Rig，并为 Control Rig 与 UAF 更紧密集成打基础。Unreal Engine

concept sculpt / kitbash / blockout / shape design。艺术家先把球、柱体、管子、牙齿、触手、装饰件不断叠在一起，优先解决的是"外轮廓、体块、比例、节奏"。这时内部那些互相穿插的面通常不重要，因为镜头、雕刻、材质展示看到的是外表面，不是内部拓扑。

常见处理方式有三类。

一种是 Boolean Union 。如果你想把多个相交体真正合成一个外壳，可以用 Boolean Modifier 的 Union。Blender 5.0 官方手册里 Boolean 的 Exact solver 明确是复杂求解器，支持 overlapping geometry，但速度更慢；Manifold solver 则要求输入本身是流形体。也就是说，Blender 确实有专门处理重叠几何的布尔体系，但不同 solver 对输入质量有不同要求。docs.blender.org+1

Voxel Remesh 。雕刻流程里很常见：先把很多形体堆起来，然后 Voxel Remesh，把它们重新体素化成一个新的连续外壳。Blender 文档描述 Voxel Remesher 的逻辑是把网格放进一个虚拟 3D grid，按接近外表面的点重新生成网格；Voxel Size 决定重建后的细节密度。这个方法适合雕刻，但会重建拓扑，不会保留你原来的边线结构。docs.blender.org+1

手动清理 / Retopology。如果最终要进游戏、动画、绑定、表情、布料模拟，就通常不能只靠布尔或体素重建。你会在高模外面重新建一个干净低模，用来变形、UV、烘焙 normal/AO/curvature。重叠高模可以存在，但最终用于引擎的 skinned mesh 通常要干净。

​

右侧的 Boolean 面板有一个核心选项：Operand Type 。它可以是 Object ，也可以是 Collection。Object 就是你现在看到的"一次指定一个对象"；Collection 则可以让一个 Boolean Modifier 使用整个 Collection 里的多个物体作为运算对象。

Exact solver 支持更复杂的重叠几何，但更慢。

​

"块状堆叠阶段"误认为"最终布线阶段"。

​

Lyra 是 Epic 官方给 UE5 做的"示例游戏工程 / Sample Game Project"，不是单独的引擎功能，也不是插件本身。

更准确地说：

Lyra = 一个可运行的多人射击/动作游戏示例项目，用来展示 UE5 的现代游戏项目架构。

Epic 官方文档对它的定位是：Lyra 是一个学习用游戏示例，帮助理解 UE5 框架；它的架构是模块化的，由核心系统和插件组成，并且会随着 UE5 开发持续更新。Epic Games Developers

https://github.com/liuhuagang/XG-UE-Cpp-Course-Skill/tree/main

第一层：人直接看 knowledge/

第二层：把 .trae/skills/xg-uecpp-course/ 配到 Trae / Cursor / Windsurf 这类 AI IDE，让 AI 在写 UE C++ 时自动引用这些知识。

这个仓库 README 写得比较清楚：它包含课程知识文档、AI Skill、以及课程工程说明；其中 Skill 的定位是"在 Trae / Cursor / Windsurf 等 AI IDE 中使用"，用于动手开发时快速定位 API 用法和理解架构设计。

Skill 覆盖反射系统、TArray、容器选型、委托、异步、多线程、配置与依赖注入、ControlFlows、HTTP、WebSocket、TCP、Slate、第三方库封装、GAS 等主题。GitHub+1

​

Non-Dedicated 是非专用会话，通常是某个玩家自己开房间，你加入后会受房主联机限制，不是长期独立服务器。

​

Day 是这个服务器世界内已经过了多少天，不是现实日期。

Build 是服务器游戏版本。你图里是 85.44，和底部状态栏 Online (v85.44) 对上了。

Hide Full 是隐藏满员服务器。

Show Password Protected Servers 是显示有密码的服务器。

PC-Only Online Multiplayer 是平台/跨平台相关筛选。

Sort Order 是排序规则，比如按人数、Ping、名称之类排序。

​

​

​

​

​