请问在editor中通过工具人为将复制出来的多个SM合批为ISM,和引擎最后在打包过程中的自动合批是否在性能方面有什么区别?
<br/>
请问在editor中通过工具人为将复制出来的多个SM合批为ISM,和引擎最后在打包过程中的自动合批是否在性能方面有什么区别?
<br/>
您好,
感谢您的询问。
请问您提到的“引擎最后在打包过程中的自动合批”是指 World Settings 中的 Transformer Stack 选项吗?
不是的,我指的是引擎的auto instancing的机制
您好,
动态实例化是按照 Static Mesh 组件上的绑定信息在运行时动态发生的。这时虽然渲染部分已经被实例化了,但是组件本身仍然是独立的个体,并且可能会有 CPU 方面垃圾回收的开销。
请查看这个文档页面中的“绘制调用合并”部分:
手动将 Static Mesh 合并成为 ISM 在 Nanite 和非 Nanite 工作流下都仍能减轻追踪多个组件时的 CPU 和内存开销。
对于 World Partition 关卡,现在有更易用的合并方案:请在 World Settings 中尝试 WorldPartitionRuntimeCellTransformerISM。这个方案可以在 Cook 和 Play In Editor (PIE) 期间自动将 Static Mesh 合并成为 ISM。更多信息请查看:https://dev.epicgames.com/community/learning/knowledge\-base/r6wl/unreal\-engine\-world\-building\-guide\#wp\-importantchangesin55
如果您有更多疑问,请随时联系我们。
感谢回复!!我还有以下进一步的疑问:
[Image Removed]
您好,
如果您有更多疑问,请随时联系我们。
上传了测试项目及文件,感谢回复!
这是项目
您好,
文档中所说的 Speed Tree Wind 阻碍动态实例化并不是指 SpeedTreeWind 这个材质函数或者 UMaterialExpressionSpeedTree 材质节点,而是指 UStaticMesh 上的属性:
/** Data that is only available if this static mesh is an imported SpeedTree */ TSharedPtr<class FSpeedTreeWind> SpeedTreeWind;
SpeedTreeWind 属性与 SpeedTreeWind.h/.cpp 中的 “FSpeedTreeUniformParameters” Buffer 相关
IMPLEMENT_GLOBAL_SHADER_PARAMETER_STRUCT(FSpeedTreeUniformParameters, "SpeedTreeData");
被不同风场影响的树木会指向不同的 SpeedTreeData Buffer,因此不能被动态实例化。
如果您想要测试动态实例化是否正常工作,可以尝试用 “r.MeshDrawCommands.LogDynamicInstancingStats 1” 命令在日志中打印实例化状态,或者进行 GPU 抓帧来查看具体网格体/材质组合的实例化情况。
希望这些信息可以帮助您。
感谢回复!
您好,
感谢您的回复!
我们可以关闭这个工单吗?如果您后续对这个问题需要任何帮助,可以随时重新开启这个工单。
好的,感谢!