1. 为什么需要 func_detail？（普通笔刷的灾难）
在起源引擎中，默认画出来的基础方块叫做 World Brush（世界笔刷）。引擎有一个死板的底层逻辑：所有的 World Brush 都会阻挡视线，并且引擎会自动沿着它们的所有平面延伸出去，切割空间（生成 Visleaf 和 Portal）。
如果你用 World Brush 做了一堵平整的大墙，这很好，它完美切分了房间。 但如果你用 World Brush 做了以下东西：
-
一段由 20 级台阶组成的楼梯
-
一根由 16 个面拼成的圆柱子
-
墙壁上凸起的复杂浮雕或窗框
灾难就降临了： 引擎会沿着这 20 级台阶的每一个垂直面和水平面、沿着圆柱子的 16 个面疯狂切割。原本一个干净完整的房间（1 个大 Visleaf），会被这些复杂的结构硬生生切成几百上千个稀碎的微小 Visleaf（即 Portal Spaghetti）。
-
编译时： 计算这几千个碎片之间的可见性关系，会让编译时间从 1 分钟暴增到 10 个小时，甚至导致内存溢出崩溃。
-
运行时： 玩家走上楼梯时，每上一个台阶，CPU 就要重新查几百次"可见性字典"，导致严重卡顿。
2. func_detail 的救场机制
当你把这些复杂的楼梯、柱子、装饰物框选起来，并转换为 func_detail 实体后，奇迹就发生了。它在引擎中被赋予了"双重身份"：
-
物理层面上（对玩家）：它完全正常。 玩家依然可以踩着台阶上楼，它有碰撞体积，子弹打不穿，光照也会在它表面留下正确的阴影。
-
视线逻辑上（对引擎 VVIS）：它"隐形"了。 当引擎的切空间刀刃扫过房间时，会直接穿透这些
func_detail，完全无视它们的存在。房间依然保持着完整、规整的大 Visleaf 状态，编译瞬间完成，游戏无比流畅。
3. 如何正确使用 func_detail？
这是一个区分新手和成熟地图作者的绝对分水岭：
-
必须转为 func_detail 的物体： 楼梯、柱子、栏杆、不规则的岩石、散落的小箱子、门框的包边、一切纯装饰性的复杂几何体。
-
绝对不能转为 func_detail 的物体： 构成房间的四面承重墙、地板、天花板、以及那些能完全挡住一大片区域视线的大型建筑物（比如阻断街道的巨大建筑物）。
总结：它与 Hint 的完美配合
起源引擎的底层优化，其实就是你在教引擎如何聪明地"划分布局"：
-
世界笔刷（World Brush）： 充当"承重墙"，粗略划分大房间。
-
Hint 笔刷： 充当"人工隔断"，在走廊拐角等视线死角强制切一刀，优化性能。
-
func_detail： 充当"室内家具"。它们老老实实待在房间里提供视觉细节，但绝不参与房屋面积（Visleaf）的划分，绝不给引擎的底层计算添乱。