简介：这份UE4传送门案例集适合已入门虚幻引擎4的开发者进阶学习，围绕蓝图系统梳理了传送门设计的完整流程，涵盖空间定位与坐标转换、碰撞检测、触发机制、多传送门逻辑、物理模拟保持、网络同步及场景切换等关键知识点。压缩包共232个文件，以124个uasset蓝图资源、10个umap地图文件为主体，配合41个ini配置、14个json数据及少数日志、图片，构成可直接浏览的工程结构，整体大小75.68MB。目前已有498人学习下载。通过这套案例，开发者可以参考各个模块的具体实现，理解从单机传送门到多人同步状态的设计差异，并学习延迟加载、简化渲染等优化手段，从而搭建稳定、流畅且富有沉浸感的传送机制，为后续独立开发传送门玩法提供坚实的实践参考与排错思路。
1. UE4传送门是什么：从一个渲染黑匣子说起
UE4传送门，说白了就是让玩家在A房间看到一个完全连贯的B房间画面，走进去之后自己真的到了B房间。我第一次在项目里碰它，是给一个科幻解谜Demo做“墙上开洞看另一个世界”的效果，当时天真地以为是放个平面贴图，结果画面上那个洞的边缘怎么都对不上，建筑轮廓在门框位置全是错位的，翻车翻得非常彻底。后来才搞清楚，传送门根本不是“贴一张图”，而是一整套基于摄像机重投影和模板缓冲的渲染方案，它把“门后的视角”重新投射到门前那块平面上，再靠Stencil裁剪掉越界像素，让画面看起来就像墙被挖穿了一样。
这篇东西适合谁？正在做场景展示、逃生解谜、或者科幻题材关卡的UE4开发者，也适合被美术追问“门口那棵树怎么是歪的”的程序员。我不会讲教科书原理，只讲我在本地Demo里复现这套方案时，哪些参数必须动、哪些坑必须躲，以及几类经典案例各自要怎么改。
2. 传送门的核心原理：Stencil Buffer与递归渲染的配合
2.1 为什么传送门不能用“把角色传过去”的思路做
最常见的错误思路是先别管画面，等角色碰到门框碰撞体，直接SetActorLocation把人挪到目标点。这套逻辑在“走过去”这个动作上成立，但画面里那个洞口显示不了任何东西，因为你只是改变了角色的位置，并没有改变摄像机看到的画面来源。传送门技术的本质是：门洞平面上一块区域，显示的是另一台摄像机从另一个位置拍摄的画面，而且这个画面要和玩家当前所在场景的透视关系完全一致，不能穿帮。
举个例子，玩家站在门前，看到门里有个书架。书架的位置信息是相对于“门后那台摄像机”的，而不是相对于玩家摄像机的。如果你只是把角色传送过去，玩家看到的是门框后面原本那面墙，而不是书架。所以必须把“门后摄像机的画面”实时渲染到门洞平面这块几何体上，玩家看到书架时，书架的光照方向和遮挡关系都要符合“玩家站在门前朝门里看”的直觉。
2.2 Stencil模板描摹：让门框遮住不该出现的东西
UE4里实现传送门，绕不开Stencil Buffer。Stencil是一个逐像素的模板缓冲，它记录每个像素是否被某种标记覆盖，渲染时可据此决定丢弃或保留某个像素。常见做法是给门框几何体指定一个自定义Stencil值，比如数值2，然后把门洞平面这个片元的材质设为“仅当Stencil值匹配时才显示画面”，否则输出全透明或直接Clip掉。
这样做的意义在于：“从门洞平面看到的画面”必须严格限制在门框以内，哪怕画面中有些物体因为透视关系延伸到了门框之外，也不能显示。否则画面就穿帮了，比如书架的一部分浮在门框边缘上。Stencil在这里相当于剪刀，把渲染结果裁剪成门洞的形状。我一般会把门框的Stencil值单独拿出来，设为2，和场景里其他需要用Stencil的特效（比如角色描边用的1）区分开，避免相互干扰。
2.3 视口重投影：从门内的第二台摄像机拉画面
有了Stencil裁剪，接下来要让画面内容正确。做法是放第二台摄像机（SceneCapture2D）在门后的对应位置，方向对准门的另一侧，Capture出来的画面作为门洞平面的自发光颜色输入。关键一步是：第二台摄像机的位置不能随便放，它是“玩家摄像机关于传送门平面的镜像”。玩家站在门口距门0.5米，门后摄像机就要站在门内侧距门0.5米，方向也要镜像反转，这样画面里物体的透视关系才和玩家视角衔接得上。
这一步就是很多案例里“看起来像真的”和“看起来是贴图”的分水岭。位置和朝向只要偏差超过几厘米，门里的物体就会明显漂移。更麻烦的是递归渲染：当两扇传送门互相能看到对方时，你需要在SceneCapture2D里再捕捉“另一扇门看到的画面”，这就成了“门里有门里有门”，每一层都需要一次额外的场景渲染，层数一多就是性能黑洞。
参数对照表：
| 参数 | 作用 | 我的常用值 |
|---|---|---|
| CustomDepth Stencil Value | 标记门框几何体 | 2 |
| 门框材质 Stencil Comparison | 读取模板值做裁剪 | Equal 2 |
| SceneCapture2D Texture Target | 渲染目标纹理 | 新建RenderTarget，尺寸512x512或1024x1024 |
| Capture Source | 捕获源 | SceneColor (HDR) 或 FinalColor (LDR) |
| 递归捕获深度上限 | 防止无限循环 | 3 |
3. 搭建第一扇可用的传送门：完整蓝图流程
3.1 场景准备与门框模型规范
先搭一个测试场景：一间小房间A，一间小房间B，中间用一堵墙隔开，墙面上做一个门洞形状的凹陷。别用真正的门模型，用一个简单的平面放在凹陷处，这个平面就是“门洞画面”的载体。平面尺寸要和门洞完全贴合，偏差超过1厘米，画面边缘就露馅。
门框可以是墙体本身的边缘，但更方便的做法是：单独创建一个Box或Plane组件，套在门洞凹槽的位置上，用来写Stencil。这个组件的材质不必是实体，可以是半透明或Unlit，关键是它的Stencil值要能写进缓冲。如果门框几何体和墙体重叠，模板比较会出问题，所以门框最好稍微凸出墙面一点，哪怕0.5厘米，保证它的轮廓清晰可辨。
我习惯把门框模型命名为PortalFrame，门洞平面命名为PortalSurface，两个Actor分开管理。这样做的好处是调试时能单独开关其中任何一个，快速定位是裁剪问题还是画面问题。
3.2 设置SceneCapture2D与RenderTarget
右键内容浏览器，创建RenderTarget，命名RT_PortalView，尺寸先设512x512。尺寸不是越大越好，SceneCapture会把整个场景再渲染一遍，256x256到512x512是通用选择，性能敏感场景用256，画质优先用1024。
然后在门后位置放一个SceneCapture2D，它本质上是一个额外的摄像机。把它的TextureTarget设为RT_PortalView，CaptureSource选SceneColor，勾选CaptureEveryFrame。位置放哪？我要强调一个原则：它的位置是动态的，需要在蓝图里每帧根据玩家摄像机位置做镜像计算，而不是摆一个固定位置。固定位置只适合门位置完全固定、且玩家活动范围很小的演示，一旦玩家左右走动，门里的画面就会“平移”，透视完全错位。
3.3 Stencil参数设置与材质开关
选中门框模型，在细节面板里找到Render CustomDepth Pass，勾选它。然后在CustomDepth Stencil Value里填2。注意：UE4的CustomDepth默认只写深度，不写Stencil，需要在项目设置里把Custom Depth-Stencil Pass改为Enabled with Stencil，否则你填的2根本写不进Stencil缓冲。
接下来是门洞平面材质。创建一个材质M_PortalSurface，Blend Mode选Masked，Shading Model选Unlit。Color连接到RT_PortalView的纹理采样，Opacity Mask连接到一个自定义节点，这个节点读取当前像素的Stencil值，和2比较，相等则输出1，否则输出0。这样画面只出现在门框Stencil覆盖的像素上，其他区域全部被裁剪成透明。
材质蓝图里的关键逻辑：
// 伪代码：在Material Editor里通过Custom节点实现Stencil裁剪 // SceneTexture节点，选择 CustomStencil 作为SceneTextureId float StencilValue = SceneTextureLookup(UV, CustomStencil, 0); // 比较后输出OpacityMask if (StencilValue == 2) { return 1.0; } else { return 0.0; }逻辑说明：SceneTextureLookup是材质编辑器里的SceneTexture节点，它能读取当前像素的几种缓冲值，CustomStencil就是其中之一。把读取到的值和门框的Stencil标记值2比较，只有相等的像素才让Masked材质的Opacity Mask通过。这段代码本质是“用模板值从渲染结果里裁出门的形状”，配合SceneCapture2D输出的画面，就是传送门的第一层真实画面。
参数说明：CustomStencil这个SceneTextureId在老版本里叫PostProcessStencil，如果找不到，检查项目设置里Custom Depth-Stencil Pass是否已启用；值“2”是我自定义的，你也可以用其他整数，只要门框和材质两处保持一致即可。材质必须设为Masked而不是Translucent，因为Translucent不写CustomDepth，模板读不到有效结果。
3.4 最小可行测试：从门里看到另一个房间
搭建完成后，先做一次静态测试：把玩家角色放在房间A，面朝门洞，预览画面。如果你看到门洞里显示的是房间B的完整静态画面，透视方向和房间B实际布局一致，说明SceneCapture2D的位置和朝向是对的。如果画面是黑的，优先检查RT_PortalView有没有分配正确；如果画面有但边缘有杂色，检查材质裁剪和门框Stencil是否匹配。
能通过静态测试，再做动态测试：让玩家左右平移，门里的画面应该跟着“视差”变化，就像透过真窗户看外面一样。这个效果的关键就在SceneCapture2D每帧跟随玩家摄像机镜像移动。
用蓝图补上动态更新逻辑：
Event Tick -> Get Actor Location (玩家摄像机) -> Transform Position to Portal Space (把玩家位置换算到门A的本地坐标) -> Mirror the Z/Y axis (对传送门平面做镜像) -> Transform Back to World Space (得到门后摄像机位置) -> Set Actor Location (SceneCapture2D) -> 同理计算旋转，把SceneCapture2D的朝向也做镜像逻辑说明：这里不能直接把玩家位置复制给SceneCapture2D，必须算镜像。传送门平面的法线方向决定了镜像的坐标轴，墙的正面朝向决定了左右方向是否正确。门后的摄像机看的方向是“玩家所看方向的镜像”，所以Rotation也要做对称处理。
参数说明：Transform Position换算时，最好基于门的Actor的本地坐标做计算，而不是直接套世界坐标，否则门一旦旋转，镜像计算全部错乱。测试场景里如果门是正的，世界坐标也能跑通，但你要养成本地坐标的习惯，后面做斜墙上的传送门就省事多了。
4. 传送门案例的变种：从单门到无限镜像
4.1 单门单向：最基础的观测型传送门
单门单向是入口级案例。它只解决“看到”的问题，不做位置传送。适合做科幻窗户、展示橱窗、或游戏里“看另一个空间的监控画面”这类需求。实现方案就是上面那一整套。要注意的是：如果画面不需要实时跟随玩家视角，比如那个空间是固定角度展示，SceneCapture2D可以直接摆一个固定位置，省掉每帧镜像计算的性能开销。但代价是玩家走近或走远时透视不变化，稍有经验的玩家一眼就能看出来是“贴图”。
4.2 双门互通：传送门套传送门的经典死循环
双门互通是最能体现“案例集”价值的一类。它的视觉冲击力在于：从门1里能看到门2，而门2的画面里又捕捉到了门1，门1的捕捉再包含门2，这就形成了无限递归。
实现上，你需要在门后放两个SceneCapture2D：一个捕捉门1外的世界，一个捕捉门2外的世界。门1洞面显示的是“门2的SceneCapture2D画面”，门2洞面显示的是“门1的SceneCapture2D画面”。而每个SceneCapture2D在渲染时，又会把对方的传送门画面当作场景的一部分渲染进来，于是递归出现了。
这里最关键的技能是限制递归深度。UE4的SceneCapture2D默认不会自动限制递归，你必须用蓝图控制它的Active状态，或者用材质上的粗糙度做深度判断（不推荐）。我常用的做法是做一个整数变量RecursionDepth，在Tick里++，超过3层就把SceneCapture2D的HiddenActors列表加上对方传送门，强制它不再捕捉下一层。超过3层之后，视觉上的递归画面已经足够密集，肉眼分辨不出第3层和第10层的差异，但性能差异巨大。
Event Tick RecursionDepth++ if (RecursionDepth > 3) SceneCapture2D.HiddenActors.Add(OtherPortal) else SceneCapture2D.HiddenActors.Remove(OtherPortal)逻辑说明：通过把对方传送门Actor加入HiddenActors，阻止SceneCapture2D继续捕捉对方，渲染循环到此终止。这个方案牺牲了一点递归层数，但每一帧的渲染开销都被锁死了。
参数说明：3不是一个绝对标准，如果两张门离得近，可以降到2；如果门距离远，3层在画面里会显得稀疏，可试5层，但你要做好帧率骤降的心理准备。机器配置不同，这个数要按目标平台的性能调。
4.3 完整穿越：角色位置与旋转的瞬间重定向
传送门案例最终要回答的问题是：玩家走进去，真的到了另一边，并且转身逻辑不出错。这一块是很多人“抄完视觉案例后卡住”的地方。视觉通了，穿过去却穿到墙里，或者穿过去后方向反了。
我的做法是：在门框位置放一个Box Collision，Overlap时触发传送。传送时不是简单SetActorLocation，而是计算“玩家相对门1的位置和朝向”，换算成“相对门2的位置和朝向”，再写回玩家。换算公式是：门2的世界位置 + 门2的本地旋转 * (门1的本地坐标) ，其中门1的本地坐标是把玩家位置转换到门1本地空间得到的。旋转同理：门2的世界旋转 * (玩家相对门1的旋转) ，再乘以门1的逆旋转。
蓝图逻辑：
OnActorBeginOverlap -> Get Actor Transform (门1) -> Get Actor Transform (门2) -> PlayerLocationInPortal1 = 门1.InverseTransformPosition(玩家位置) -> NewPlayerLocation = 门2.TransformPosition(PlayerLocationInPortal1) -> PlayerRotationInPortal1 = 门1.InverseTransformRotation(玩家朝向) -> NewPlayerRotation = 门2.TransformRotation(PlayerRotationInPortal1) -> SetActorLocationAndRotation (玩家, NewPlayerLocation, NewPlayerRotation)逻辑说明：InverseTransformPosition是把世界坐标转换成相对于门1本地坐标系的坐标，相当于把玩家位置“钉”在门1的坐标系里。TransformPosition再把那个相对坐标应用到门2的坐标系，得到新的世界坐标。这样玩家从门1的左边进去，就会从门2的左边出来，前后关系不会错。
参数说明：这里绕不开的一个坑是角色胶囊体旋转与网格体旋转不一致。角色蓝图里MovementMode为Flying或Walking，胶囊体的旋转是控制器控制的，你设置角色Rotation后，控制器可能又把它拉回去。解决方法是同时调用SetControlRotation同步摄像机朝向，否则玩家传送后视角会“归零”，头晕非常明显。这个点是我调试中最久的一次，血泪教训。
5. 传送门避坑指南：透视穿帮、递归爆炸与性能黑洞
5.1 现象：门框边缘出现黑边或半透明残影
原因：门洞平面的Masked材质裁剪边缘太锐利，像素覆盖不完整时会出现黑缝。另一个常见原因是CustomDepth Stencil Pass没有开启，Stencil读取结果是0，裁剪逻辑把门洞整体删掉了，剩下一个半透明灰块。
解决：先确认项目设置里Custom Depth-Stencil Pass设为Enabled with Stencil。黑边是门洞平面比门框几何体小一圈，肉眼可见的亚像素缝隙都会变黑线。把门洞平面放大2%到3%，覆盖住门框内侧边缘，黑边基本消失。
5.2 现象：传送门套传送门时帧率断崖式暴跌
原因：递归渲染的每一层都要完整渲染一遍场景，两台SceneCapture2D各渲染一次，两层递归就是四次全场景渲染，三层就是八次。性能以指数级恶化，完全不带商量。
解决：架上深度限制开关，我一般限制到3层。如果两份场景的复杂度和光照都很高，就只能减到2层。另外可以把RT_PortalView的尺寸从512降到256，虽然画面会糊一点，但能保住帧率。项目里的演示场景我通常还会把门后场景的粒子特效和动态阴影关掉，给Capture节省Shader开销。
5.3 现象：摄像机穿过门时画面抖动或闪一下
原因：玩家角色的碰撞体先碰到了传送Volume，触发传送，但摄像机还在门平面内，此时门后SceneCapture2D的位置和玩家位置几乎重合，渲染出一帧极近或极远的异常画面，视觉上就是“闪”或“抖”。
解决：触发传送后，把玩家位置再向前推出一小段，比如沿着门2的向前方向推30到50厘米。这样摄像机立刻离开传送平面，不会出现两个空间重叠的过渡帧。同时传送瞬间对SceneCapture2D强制隐藏一帧画面，或者把它的CaptureEveryFrame临时关掉再打开，也能消除闪烁。
5.4 现象：角色穿过门后角度反了
原因：方向换算时用了开关式的判断，比如“玩家从正面走就旋转180度”，这种硬编码在斜门上全部翻车。真实原因是旋转的镜像没算完全，少乘了门1的逆旋转。
解决：严格用InverseTransformRotation加TransformRotation的组合，永远不要自己手写角度加减。还有一个习惯：调试时在地上放一根箭头模型，材质用一红一绿两面，红色代表前方，绿色代表后方。传送后看一眼箭头朝向，就能快速确认旋转算对没有，省得每次都是“看起来好像对了”的玄学。
5.5 现象：移动平台打开门就掉帧
原因：SceneCapture2D每帧渲染整个场景是桌面端的做法，移动端GPU顶不住。而且RT_PortalView的尺寸如果按桌面经验设1024，带宽消耗直接炸。
解决：移动端策略是：门洞画面不逐帧捕获，用固定帧率捕获，比如每秒15帧，再把RT_PortalView降到256。另一个经验是把门后区域的场景简化，去掉投影和粒子。若门是静态的且玩家活动范围小，SceneCapture2D可以直接只捕获一次静态帧，玩家移动时画面不更新，配合上门的动画遮挡，大多数玩家不会察觉异常。
6. 把传送门案例做出质感：进阶调优与验证技巧
视觉通过的传送门和“能直接上线”的传送门之间，还差几个细化步骤。第一是光照衔接。SceneCapture2D默认捕获的是SceneColor，它会带入门后空间的光照信息，但门前空间的动态光影变化不会传递过去。比如玩家站在阴影区，门内画面应该偏暗，但Capture的画面不会自动调暗。做法是给RT_PortalView材质串节点，把玩家所在区域光照强度作为multiplier乘到自发光上，虽然不算物理精确，但能明显增强“门连着两个世界”的说服力。
第二是门框阴影。门洞平面是自发光材质，不会被角色遮挡投射阴影。比如角色站在门前，应该在地面留下一条从门里透出来的影子，但默认状态下完全没有。给门框Actor加一个Spot Light，方向对着门外地面，强度调到0.2左右，影子就出来了，且不会影响门内画面。
第三是验证方法，也是最值得花时间的一步：重复测试。我习惯在Game View模式下围着门走一圈，蹲下、跳跃、贴墙、跑动，每一种姿态都检查门框边缘有没有穿帮。另一个技巧是把RT_PortalView临时设为1024，截图看门内远处物体的轮廓线和门框贴合度，如果贴合好再调回256，能过滤掉多数模糊造成的假性贴合。
这套方案值不值得做？如果你要做的是视觉展示、解谜关卡或科幻风格的场景过渡，传送门技术带来的体验提升是明显的。它的代价是每多一层递归就多一次全场景渲染，性能预算必须提前留好。做完上面这些步骤，你能得到的不只是一扇能看的门，而是一整套理解“场景捕获、模板裁剪、坐标重映射”三个环节的动手经验。我在项目里最大的教训就是没有一开始做深度限制，结果测试时一走到双门中间，编辑器直接卡到2帧，从那以后我把递归深度开关放在了第一个实现，而不是最后一个。希望帮到你。
本文还有配套的精品资源，点击获取
