找回密码
 立即注册
查看: 350|回复: 0

Unreal虚幻引擎常见的衬着问题解答!建议保藏

[复制链接]
发表于 2023-5-21 14:50 | 显示全部楼层 |阅读模式
提示:文章较长,阅读时间10分钟摆布,如何提升Unreal衬着速度,文末有解决方案。
一、常见的问题

扩展衬着引擎的最佳实践是什么,最好以可维护的方式?

  • 避免更改引擎代码,并在插件或项目模块中尽你所能。如果没有用于您想要进行的衬着更改的 API,请与我们合作添加一个。**
  • 在使用 VR 前向衬着但并非所有玩家都不是专门使用 VR(例如 PC)时,在应用法式中切换衬着技术的最佳方式是什么?**
  • 每个设备都呈现本身的内容,而不是其他设备的内容,因此您可以按照客户端运行的设备做出决定。处事器从不衬着任何东西。**
任何具有简单数据流的 CustomMeshFactories 的简单示例?在策动机或其他方面?

  • LidarPointCloud 可能是插件的主要示例,否则您可以查看引擎中包含的顶点工厂**
典型的电影衬着工作流程是什么?

  • 衬着电影队列 (4.25) 允许您在衬着场长进行批量衬着或在当地计算机长进行无头衬着。目前,我们拥有任何人(工程师)都可以将衬着电影队列与他们的衬着农场打点系统集成的基础设施。对于 4.26,我们打算开箱即用地集成截止日期。**
  • 衬着(长途)选项启动衬着队列中所有序列的外部进程。您必需将更改保留在项目中,以便外部进程可以从磁盘读取文件。**
  • Render Remote 选项还允许您实现长途衬着农场,同时在调整设置时仍保留编纂器内衬着以便快速预览。衬着选项的默认行为由项目设置确定,而且可以调整以运行您本身的代码,例如调整衬着(长途)以使用第三方衬着农场打点软件。**
  • 此外,您还有 cvar 命令,可以作为构建您本身的自动衬着农场的起点。**
  • 使用衬着电影队列,您可以措置去噪技术并移除时间抗锯齿。您可以进行二次采样、覆盖游戏设置和调整 cvar,例如:**
  • r.AmbientOcclusion.Denoiser.TemporalAccumulation 0**
  • r.GlobalIllumination.Denoiser.TemporalAccumulation 0**
  • r.Reflections.Denoiser.TemporalAccumulation 0**
  • r.Shadow.Denoiser.TemporalAccumulation 0
  • 目前输出格式为:bmp 序列、exr 序列、jpeg 序列、png 序列、音频 wav。
二、衬着功能问题

我们已经不雅观看了 GDC2019 中有关可粉碎 HLOD 的视频。从那时起,Fortnite 已经成长了很多。这种方式还成立吗?从那以后有什么新的学习吗?

  • 自 GDC 以来,销毁 HLOD 没有真正的变化。
  • 只有合并的 HLOD 在 Fortnite (HLOD0) 中是可粉碎的,而不是代办代理 HLOD (HLOD1)
  • 我们将顶点颜色添加到 HLOD,使用颜色将对象 ID 分配给顶点,在材质中我们使用 vis 缓冲区来切换图元的开/关**
  • 几何交换:以不异的方式工作,隐藏,然后更新可见缓冲区,如果一切都是静态的,那么您可以只显示交换部门,允许 HLOD 显示几何(合并 HLOD,而不是代办代理)
  • 对顶点进行更多的纹理采样,不是减少顶点,而是减少三角形
  • General Chaos Destruction 文档
将 HLOD 集成到资产经常变化的活动开发工作流程中的保举做法是什么?

  • 4.25 及更高版本对 HLOD 构建进行了优化,按照内容快 10 倍
  • 一些集群选项存在一些已知问题,每个级此外单个集群非常快。我们可以提供一些没有达到 4.25 的版本
  • 保举的做法是有一个过程来重建无效的 HLOD,收集已更改 HLOD 的列表,然后将工作负载拆分到多台机器上
签出关卡时会发生什么?

  • 数据存储在关卡本身中,因此它会跳过特定的更新
  • 我们正在测验考试将 HLOD 数据移出关卡以降低成本
由于我们的动态照明设置,我们目前依赖 CSM 进行暗影措置以适应可粉碎的架构。一旦 CSM 淡出,我们就缺少中景和布景的暗影机制。除了后期措置材料之外,我们还缺乏任何类型的 AO 解决方案,但这有很多错误谬误。是否有任何潜在的机制可以在暗影和 AO 方面辅佐我们?如果目前没有其他选择,我们可以本身实施任何建议的解决方案吗?

  • ES3.1 是我们目前的最低要求,之前我们还不能撑持移动设备的距离场暗影,因为我们需要计算着色器来合并距离场。我们想测验考试一下,但我们还没有任何性能数据。也是内存权衡。
  • 我们想降低更新频率和质量以使其在移动设备上运行。
  • 此刻我们没有任何元数据可以添加它,但在 Fortnite 中,技术艺术家为暗影的假着色器做了一些技巧。
  • AO - 实现技术
  • 获取其他平台基于距离的技术
  • 假装
  • 着色器为两者遍历不异的数据,这就是为什么两者都没有实现
  • 是否可以选择启用 SSAO?(有一些性能命中)
  • 我们在当地实现了,但是还没有提交,还在进行中
  • 性能是可以接受的,但确实有副感化:在 base pass 之后衬着,所以效果不是很准确
  • 我们不能进行时间​​过滤,因为我们不保留以前的帧数据
  • 在 4.26 中实施
我们但愿视频源的纹理查看器中的颜色可以在 3D 场景中显示而无需任何更改。我们知道光照和色调映射,所以我们测验考试使用 Unlit 材质或 Composure 插件,但没有得到想要的成果。使这项工作的任何提示?

  • 至于颜色,我们没有将色调映射器应用于 3D 场景子集的机制。我们在其他处所解决这个问题的方式是使用 Composure,它允许您为媒体内容和 3D CG 内容设置单独的层。可以每层启用或禁用色调映射器,这将允许视频没有色调映射器,而 CG 内容将具有凡是的 UE4 色调曲线。这是我们操作的途径,但如果您无法使其满足您的需求,请告诉我们。
我们使用“真实世界”的太阳/天空亮度值,这会导致物理上正确的概况亮度和预期的相机曝光值。这些真实世界的值具有很大的数值范围,而且似乎粉碎了一些照明组件;是否有可能不明显的设置我们应该按照这些灯进行更改?

  • 预曝光应该可以解决这些精度问题。在 4.24 中修复了一些错误(例如场景颜色节点未使用预曝光),还有一些较小的错误将在 4.25 中修复(皮肤着色镜面反射)。预曝光应该持之以恒地工作,但如果不是,请陈述错误。
目前构建反射环境只是编纂器。在运行时这样做有什么问题?

  • 在运行时执行此操作的功能已被删除以撑持 SM4,但如果您不关心 SM4,可以阅读。
对于按法式放置然后不再移动的对象,我们可以使用哪些其他静态照明系统?

  • Lightmass 是独一的静态光照系统,需要在编纂时烘焙关卡。也就是说,如果您的法式化是在烹饪时,您可能可以将系统连接在一起以生成/烘烤它们而无需人工干与干与。
当概况上有直射光时,我们的动态照明环境看起来不错,但是当依靠间接照明时,我们的内部非常平坦。我们应该使用与体积光照贴图等效的动态吗?我们应该在室内放置“假”动态灯吗?对于室内动态间接照明,我们可以查看一些好的内容示例吗?

  • UE4 只有少数动态间接的可能性。如果动态天窗是室内照明的主要贡献者(凡是不是这种情况),距离场 AO 会有所辅佐。Light Propagation Volumes 也可以使用,但会呈现轻微出血,最好在户外使用。4.24 增加了 Screen Space GI 可以增加一个很好的效果。否则,如果您有良好控制的环境,您可能正在寻找某种假光的技术艺术解决方案。**
我们将 LPV 用于动态全局照明。它在大大都情况下都可以正常工作,但不是一个完整的功能,我们的理解是进一步的工作不在路线图中。我们应该测验考试做出哪些改良?

  • 我们没有在 LPV 上做进一步的工作是正确的。我们从来没有开发它们的内部路线图,因此我们没有可以直接测验考试的改良列表,但您可能会按照要优化的特定用例进行改良。
4.24中新的屏幕空间GI是LPV的替代品吗?我们应该使用更好的动态 GI 解决方案吗?

  • SSGI 与其说是替代品,不如说是 LPV 的补充,但您绝对应该测验考试一下。您应该使用没有更好的现有“动态” GI 解决方案。
引擎是否提供多通道发抖解决方案以实现柔和边缘?

  • 没有明确提供这样的系统。材质图中的发抖功能可以很好地使用 TAA 填充孔并提供一种透明的外不雅观。它可能适用于这个用例,也可能不适用。按照性能要求,您可能可以在 Composure 中编写像这样的多通道系统。
虚幻引擎有逐像素位移吗?

  • 我们有每顶点位移“世界位置偏移”和每像素深度改削(与物理位移分歧)“像素深度偏移”。
Unreal 在建模东西中有网格细分吗?

  • 从 4.25 开始,此功能在 UE 中不存在,而且目前没有实现此功能的打算。
如何为骨架网格物体启用静态衬着路径?

  • 在“优化”类别下的骨架网格体组件详细信息中,有一个“衬着静态”复选框。这会设置用于标识表记标帜静态衬着路径的网格的标识表记标帜。
为什么“曝光/测光模式:手动”和“auto_exposure_histogram”光值如此分歧?

  • 这是一个解释手册为什么分歧以及如何将其与自动匹配的博客。
与 auto_exposure_histogram 中的真实世界值对比,光流明值是否意味着什么?

  • 不会。无论当前视图是什么 EV,Auto_Exposure 总是以适当的曝光结束。有关自动曝光的更多信息,请访谒以下博客文章
在 auto_exposure_histogram 中,光圈、ISO 和速度是否对照明有任何影响,还是只是为了调整景深?

  • 从 UE 4.25 开始,光圈/ISO/速度对曝光没有任何感化。只有 DOF 会受到 Aperture 的影响。
光线追踪撑持的路线图是什么?

  • 从 4.24 开始,PC 光线追踪已筹备好投入出产,尽可能不变、高效且功能齐全。
  • 我们正在努力为下一代硬件添加光线追踪撑持,但这可能要等到 UE5 发布后才能投入出产。
光线追踪全局照明的打算是什么?

  • 有关信息,请参阅光线追踪文档。
按照您在光线追踪方面的经验,以及在他们的 UE4 游戏中实现光线追踪的外部团队,您是否见过一种方式/过程/公式可以将游戏从尺度延迟光栅化衬着转换为光线追踪?

  • 我们没有看到任何一种方式呈现。按照您的专业程度,您可以遵循分歧的路径。
衬着性能:
如果我们的模块化部件有 LOD,那么使用 Hierarchical Instanced Static Meshes 是首选的实例化方式吗?

  • UE 可以动态地批量衬着实例。这不是完美的批措置,HISM/ISM 可以按照条件提高性能。您将需要测试哪个最适合您的游戏。
与非分层的对比,使用分层实例化静态网格体有哪些长处/错误谬误?

  • HISM 创建实例集群。对于 HISM,剔除、遮挡和“填充”是在每个集群的基础上完成的,而对于 ISM,则是在 Actor 上完成的。
树叶系统是基于 HISM 的吗?使用树叶系统是操作 HISM 的独一方式吗?

  • 树叶系统使用 HISM。您可以手动或通过编纂器中的“Merge Actors”东西聚合 HISM 中的实例。HISM 也只是组件,因此您也可以在 HISM 之上构建本身的系统。
HISM 是否也撑持 4.25 中实例静态网格体的新自定义每个实例数据?

  • 是的,HISM 撑持它。
我们是否通过线程安全保证覆盖了所有衬着组件?

  • 我们的一些组件,包罗衬着,仍然在游戏线程上创建它们的状态,因此不能保证线程安全,而且需要针对这些组件进行措置。实现中可能存在一些错误,但目前(截至 4.25)只有 1 个衬着组件完全在衬着线程上创建。
当我们可以确定该组件不需要衬着代办代理时,我们是否从衬着队列中删除衬着组件?

  • 可能不会,因为我们仍然需要措置线程之间排队组件发生的任务,这样可能会引入一些线程安全问题
对于网格贴花或延迟贴花,是否可以使用烘焙或动态光照?有什么要注意的吗?

  • 对于烘焙照明,您需要使用 DBuffer 贴花,因为它们在基本通道(在预通道中)之前被衬着。对于动态照明,都可以使用。
  • 我们正在查询拜访弃用延迟贴花,因此我们只有一张通行证
UE4如何最好地撑持分歧功率级此外平台的高质量LOD0?

  • 我们只撑持分歧平台的分歧MinLOD
  • 可扩展性会改变过渡距离,但不会改变 LOD 本身
我们是否开箱即用地输入纹理?

  • 默认情况下,应该为不在 UI 类别中的纹理启用纹理流,任何带有 mips 的纹理
  • 如果您在流媒体上花费大量时间,则可以通过提前加载所有 mip 来节省 0.5-1 毫秒
对于下一代平台,曲面细分的表示如何?

  • 可能与当前 PC 上的情况一样糟糕,不应该更糟,但可能不会更好。我们积极测验考试不使用它,因为随着时间的推移需要进行大量维护以使其保持最新状态,尤其是与 UE5 中 Nanite 的持久潜力对比。
一般来说,为我们的游戏设置材质架构的最佳实践是什么?

  • 在这里很难提出最佳实践,因为它非常依赖于内容。
  • 凡是,您必需在功能和灵活性之间取得适当的平衡,而不能过度使用实例。您可能会拥有每种主要项目类型的主材料。抱负情况下,定制将通过标量、向量等参数进行。
  • 尽可能避免静态开关。最好注意创建摆列,许多开关 + 使用标识表记标帜会创建许多摆列。使用标识表记标帜是杀手,即:应避免在静态网格物体和骨架上使用不异的材​​质。如果不加以打点,这会很快溢出。
  • 我们在材质分层系统上的工作可能会有所辅佐。如果您交换不异的图层类型,您可以创建图层实例而且不会导致从头编译/摆列。
为什么从 UE4 中删除了纹素密度视图?

  • 在从 UE3 迁移到 UE4 时,这已作为断根的一部门被删除,因为它受到太多遗留假设的承担。将来不太可能添加此功能。
暗影是我们最大的性能问题,因为我们不能使用光照贴图。有没有法子在运行时优化“静态”对象的暗影?

  • 暗影的技术选择有限,尤其是定向灯。
  • 例如,将对象移动性设置为“静态”将允许对聚光灯进行暗影缓存。
  • 有关法则的更多信息,请参阅这些文档。
  • 定向灯可以在远处切换到距离场暗影,进一步降低成本。
  • 看这个,这个,主要是这个
  • 此外,您可以测验考试一些代码更改 - 添加暗影 LOD 偏差(使用较低的 LOD 进行暗影衬着)或添加代码以跳过将小对象衬着到暗影贴图中。
我们有许多可以从预先计算的对象可见性中受益的内饰。有没有法子在运行时对对象进行分组以优化剔除?

  • 有一个 PVS 系统,但它可能不适用,具体取决于您的世界布局的法式性。详情在这里。
是否有解决反射捕捉硬限制的方式?

  • 反射捕捉限制没有现有的解决方式,但您可以更改代码。
对于布景对象的廉价景深,您有什么建议?

  • 当前的景深具有良好的成本权衡质量。理论上,您可以恢复此刻仅限移动设备使用的高斯自由度,但有时它实际上并没有更快。还有一个“深度模糊”,可以模拟嵌入在 DOF 中的大气模糊,即使在没有“掉焦”的情况下也能运行相当便宜。你可以测验考试增加它。
  • r.DepthOfField.DepthBlur.Amount
  • r.DepthOfField.DepthBlur.Scale
  • r.DepthOfField.DepthBlur.ResolutionScale
分歧级此外预烘焙有哪些好的设置?

  • 我认为 [我们的这个视频课程] 中有一些很好的答案。](使用虚幻引擎大师班进行光照 | 2017 年蒙特利尔虚幻开发日 | 虚幻引擎 - YouTube ]
  • 烘烤一切将是最快的。有一些很好的权衡,例如固定灯,您可以更改灯光的参数但不能更改位置。光线追踪甚至会成为下一代游戏机的一个选项,我们对此提供撑持。LPV 出格不是一个很好的解决方案,因为我们从未将其置于出产就绪状态。高性能的全局照明仍然是一个开放的挑战,但我们确实有一个团队正在探索新的选项,而且随着下一代游戏机的新功能,它可能会成为一个更现实的选项。
LightBaking:我们将如何烘焙一个大世界的一小部门并将其与其他烘焙(或未烘焙)区域融合在一起?

  • 我们目前不撑持仅烘焙选定的actors,但即使实施,混合可能仍然存在问题。目前最好的选择是始终烘焙体积光照贴图并在某些对象上烘焙一些概况光照贴图,让未烘焙的人使用体积光照贴图。**
SDF-AO vs 烘焙世界?

  • 目前无法将烘焙的天窗遮挡(正常弯曲)与来自 DFAO 的遮挡混合。我们按照天窗的移动性使用此中一种。但是没有基本限制,您可以通过改削引擎来混合这两者。**
当地化环境(“沙漠中的帐篷”-场景)

  • 如果帐篷不成移动而且您可以将其烘焙到体积光照贴图或光照贴图中,那么它可以使用弯曲法线。如果它是可移动的,那么它可以使用 SSAO 或 DFAO
带有正常衰减的贴花?

  • 贴花使用材料图,就像概况材料一样。Decals 能够从 GBuffer 读取法线并基于此输出属性。贴花还可以改削 GBuffer 中的法线。
一旦将级联暗影从 Epic 降到 Medium 可扩展性,级联暗影的质量就会受到巨大影响,是否有任何设置可以稍微提高 Medium 的质量?

  • 暗影的高和中可扩展性设置之间最大的区别是级联数从 3 变为 1。为了提高视觉质量,您可以更改相应的 ini 设置,当然要知道这是有代价的。这是为引擎配置的/Engine/Config/BaseScalability.ini。要在每个项目的基础上覆盖它,您可以改削/创建[ProjectDirectory]\Config\DefaultScalability.ini
  • 要类似地覆盖平台添加[ProjectDirectory]/Config/[Platform]/[Platform]Scalability.ini
  • 有关 ini 文件覆盖法则,请参阅这些文档。
保举的抗锯齿方式是什么?

  • TAA 是所有 UE4 衬着的预期抗锯齿方式。
有没有法子解决 TAA 造成的细节损掉?

  • TAA 固有的基本技术无法避免,但可以通过更高的细节内容来缓解。TAA 会吃掉亚像素特征,而且对非常高的对比度很敏感。**
Temporal AA 还可以,但会导致各种奇怪的重影,凡是会使屏幕看起来很泥泞。按照您的经验,您是否发现任何对 Temporal AA 的调整或使用其他方式(如 MSAA)效果更好?

  • r.TemporalAA.HistoryScreenPercentage 200
  • 当 TAA 的输入噪声太高时,可能会发生重影。“vis SceneColor UV0”命令将显示这一点。**
  • r.TemporalAA.HistoryScreenPercentage 很昂贵,但这种技术依赖于 Nyquist 定理,以在 TAA 中从头投影帧时保持细节的清晰度。自反射演示以来,我们在许多演示中都使用了它。例如,这允许在角色不竭移动时保留皮肤的所有细节。
RHI

扩展衬着引擎的最佳实践是什么,最好以可维护的方式?

  • 避免更改引擎代码,并在插件或项目模块中尽你所能。如果没有您想要进行的衬着更改的 API,请与我们合作添加一个。
当使用 VR 前向衬着但并非所有玩家都不是专门使用 VR(例如 PC)时,在应用法式中切换衬着技术的最佳方式是什么?

  • 每个设备都呈现本身的内容,而不是其他设备的内容,因此您可以按照客户端运行的设备做出决定。处事器从不衬着任何东西。
任何具有简单数据流的 CustomMeshFactories 的简单示例?在策动机或其他方面?

  • LidarPointCloud 可能是插件的主要示例,否则您可以查看引擎中包含的顶点工厂**
典型的电影衬着工作流程是什么?

  • 衬着电影队列 (4.25) 允许您在衬着场长进行批量衬着或在当地计算机长进行无头衬着。目前,我们拥有任何人(工程师)都可以将衬着电影队列与他们的衬着农场打点系统集成的基础设施。对于 4.26,我们打算开箱即用地集成 Deadline。
  • 衬着(长途)选项启动衬着队列中所有序列的外部进程。您必需将更改保留在项目中,以便外部进程可以从磁盘读取文件。
  • Render Remote 选项还允许您实现长途衬着农场,同时在调整设置时仍保留编纂器内衬着以便快速预览。衬着选项的默认行为由项目设置确定,而且可以调整以运行您本身的代码,例如调整衬着(长途)以使用第三方衬着农场打点软件。
  • 此外,您还有 cvar 命令,可以作为构建您本身的自动衬着农场的起点。
  • 使用衬着电影队列,您可以措置去噪技术并移除时间抗锯齿。您可以进行二次采样、覆盖游戏设置和调整 cvar,例如:
  • r.AmbientOcclusion.Denoiser.TemporalAccumulation 0
  • r.GlobalIllumination.Denoiser.TemporalAccumulation 0
  • r.Reflections.Denoiser.TemporalAccumulation 0
  • r.Shadow.Denoiser.TemporalAccumulation 0
  • 目前输出格式为:bmp 序列、exr 序列、jpeg 序列、png 序列、音频 wav。
三、移动衬着

移动衬着

是否有关于视口 ES2 预览和设备衬着器中纷歧致的 z 深度等内容的参考?

  • 2020 年 Q2:Z 深度分歧,Android 和 IOS 之间存在差异
  • 帧缓冲区用于辅佐解决此问题
  • 我们也使用GL扩展,iOS无法获取深度
  • 我们将 16 位深度衬着到 alpha 值中
  • 在 4.26 中,我们更改了计算深度的方式以提供更高的精度。可能对远处的物体发生奇怪的影响
在 Android/iOS 上实例化我们应该注意哪些限制?

  • 使用 HISM 等组件进行实例化时,iOS 没有任何限制。
  • 在 Android 上,使用基于 Mali GPU 的设备需要注意以下几点:首先是基于 Midgard 架构的设备(Mali-T8xx 系列及更早版本),使用 16 位时相邻顶点索引的范围存在限制索引缓冲区,因为某些数据被从头用于实例化目的。使用实例化衬着此类网格将导致损坏的三角形。4.25 添加了解决方式 r.Android.MaliT8Bug=1,它将检测存在此问题的内容并在加载时将它们扩展为 32 位索引缓冲区。
  • 其次,Mali GPU 运行一次顶点着色器并将成果存储在参数缓冲区中。然后依次运行片段着色器措置每个屏幕图块。参数缓冲区的大小有限,当它填满时,需要刷新并从头启动完整的衬着管道。在正常衬着中可以解决此问题,但在实例化的情况下,当您在一次绘制调用中衬着数百万个三角形时,可能会溢出此缓冲区。发生这种情况时,您的一些实例化网格将无法衬着。没有机制可以检测到这种情况,除了中断你的绘图调用之外,没有太多可以减轻它的方式。我们在 Fortnite 树叶的实践中没有看到它,但我们已经在合成测试场景中看到了它。
  • 对于自动实例化,我们有在 UE 4.24 和 UE 4.25 中撑持移动设备的 GPU 场景功能,但是移动 GPU 没有针对我们用来查找顶点数据的随机缓冲区访谒模式进行很好的优化,因此这比没有实例化要慢用于常规几何,HISM 用于特殊情况,例如典型游戏场景中的树叶。
  • 我们还在一些基于 Mali T8xx 的旧移动设备上看到了此功能的衬着损坏,我们认为这是由于驱动法式错误造成的。
分层材料的最佳实践?移动限制?

  • 我们所知道的移动设备上的分层材料没有限制。它们在移动设备上使用起来太贵了,所以我们从不在内部使用它们。
  • 移动硬件采样器限制为 16 个采样器。
  • 景不雅观系统使用多个纹理将图层混合在一起(前两层加上法线贴图一个纹理,每应用 4 个图层一个额外的纹理)。
  • 移动衬着器还使用了一些纹理:如果使用动态暗影,则为 CSM 暗影贴图,或者为预计算的光照/暗影贴图提供 2 个纹理,以及反射环境或天光。
  • 综上所述,5 或 6 层听起来差不多。限制每个组件的层数是关键,因为这是重要的数字。有一个景不雅观可视化模式可以显示这一点。
有没有法子禁用已知在移动设备上使用不切实际的功能?

  • UE4 具有移动衬着器,该衬着器颠末调整专门为低端市场提供移动游戏。UE4 中的移动衬着器当前默认为 Fortnite 中使用的最低规格,但这些可以通过数十个(如果不是数百个)控制台变量或使用设备配置文件进行改削。
重要提示:如何快速提升unreal引擎的衬着速度

Unreal软件电脑配置的要求是斗劲高的,出格是实时衬着,前期的硬件成本是斗劲高的,这里有一个简单的节省硬件成本的方式,使用呆猫云桌面,即使当地普通的电脑也能运行Unreal软件,且普通电脑也能享受行业最高端的CPU和GPU,极大提高制作效率和使用体验,且使用便利快捷,全面撑持3D应用软件插件运行,随时调用百余款软件插件,高效作业。
呆猫云桌面可以为UNREAL 用户提供云端制作输出方案,提高工作效率。为Unity用户提供灵活、高效、低成本的云端烘焙处事,享受游戏制作的乐趣。用户在全国各地通过呆猫直接连接处事器,共享一套资产, 可以直接在呆猫上制作 / 改削工程文件,减少数据传输成本,高性能云办公选呆猫!!

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

×
懒得打字嘛,点击右侧快捷回复 【右侧内容,后台自定义】
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|手机版|Unity开发者联盟 ( 粤ICP备20003399号 )

GMT+8, 2024-4-29 11:00 , Processed in 0.136728 second(s), 27 queries .

Powered by Discuz! X3.5 Licensed

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表