对于5.7中关于NDC的方式的提升，特别是能够支持NDC FX吸附到移动的物体上面这个功能，有没有更详细的使用案例呢？谢谢 [Image Removed]
您好, 正如你的标题所说, 吸附到移动物体上的功能是通过新的Gameplay Burst类型的data channel实现的, 目前文档还在完善中, 这里我先大体解释下, 并附上了一个简单示例:
5.7 data channel的访问方式有所改动, 在向data channel写数据的时候, 我们不再用search parameters structure查找对应的grid进行spawn, 而是通过access context来访问, access context上定义了一些变量, 允许我们重载data channel的grid如何划分, spawn不同的niagara system响应同一个data channel等, 还可以如下获取到spawned systems来修改user parameter. 新旧两种访问方式会共存一段时间.
[Image Removed]Gameplay burst data channel的access context上包含了网格大小, 要不要attach到owning component上, 以及spawn哪种system, 如果没有设置attach, 则仍和Island类型一样, 在世界空间用grid划分/合并niagara system, 如果设置attach到某个component上, 则所有attach到这个component上的数据合入同一个niagara system, 如果niagara里的emitter设置的是local space的模拟, 就会跟随component运动, 整个system的bound大小取component bound和grid cell的最大值. 如下面视频, 我在击中物体时把hit信息写入data channel, spawn贴花粒子, attach到击中的component上, 跟随运动.
可以先参考测试工程看看, 有问题我们再沟通.
好像一次只能attach一个文件, 补上测试工程(5.7)
谢谢分享，我研究一下。这个工程是什么版本的呢？ 5.7.0-preview-1吗
看起来这个提升只是运用于一些ndc跟随某个物体移动的案例。
我们目前更希望NDC在这种案例下支持移动：比如说我们发射了很多子弹，这些子弹是有自己的移动方式（可能每一帧的位置会有改变），表现上用特效来表示的。那么如果用传统的方式来实现的话，每颗子弹的特效都会是一个新的niagara system，这样如果发射较多的子弹的时候，CPU这边会有比较大的开销。 NDC能不能支持这样的方式呢？谢谢
这里的子弹应该是在世界空间的模拟吧? (也就是emitter上不勾选local space.) 如果这样的话应该不用新的data channel类型, 老的global或island类型的data channel就可以实现, 发射子弹时写入data channel发射的位置和速度, Niagara监听这个data channel, spawn from data channel就可以了.
可以参考一下这个教程及其案例: Niagara Data Channel Into Niagara Data Channel 5.4 Update
如果效果理解有误, 我们再沟通.
是在5.7 release分支上的, cl-47947815, 看上一条回复应该可以打开了? 还是打不开的话我再传一个launcher版本.
这种方式遇到的问题是：假设子弹每一帧会更新自己的位置，怎么能够在NDC中同步更新相应的位置呢？ 销毁已有的粒子？再生成新的？但是如果说这个粒子有一些变化是依赖于粒子的生命时间的话好像也不行
请问意思是不是 子弹的位置不是Niagara system计算的, 而是游戏逻辑写的? 传统的一个system一个粒子的做法中, 粒子的位置是如何更新的呢?
是的，比如这个子弹的特效会挂载到某个子弹下面，然后子弹的位置更新是由游戏逻辑来控制的。
也就是说, 过去的做法是每个子弹下挂一个local space的Niagara system, 数量多了造成CPU开销大, 对吧?
现在的data channel支持的合批方式是: global, 全场景合成一个; island, 按grid拆分场景合批; gameplay burst, 可兼容grid拆分和按挂载的component合批, 挂在同一个component上的所有特效可合并.
现在的效果是一个子弹下只有一个特效, 这样新的data channel类型应该是没有帮助的. 不知道有没有详细看过CPU的开销是特效引起的, 还是过多子弹位置更新引起的? 我觉得可以考虑一下能不能把子弹的运动也放到Niagara中来, 再做data channel合并, 如果游戏逻辑里需要响应碰撞事件之类, 也可以在niagara里做collision trace, 把hit信息写出到data channel, 再在蓝图或其他地方响应, 而且Niagara中的collision trace还可以用async模式, query开销也有收益.
CPU的开销是因为子弹同时存在较多，这样也意味着子弹的特效也较多。在原有的情况下面，每个子弹的特效都是一个独立的niagara system，这么样就导致了很多niagara system在CPU侧进行tick，从而导致CPU的开销加剧。
把子弹的运动放到niagara来的话，感觉不太可行，涉及改动的东西比较多。而且我们是基于4.26的引擎，可能你建议的有一些功能还没有。
了解, 4.26功能确实会有一定欠缺.
不知道具体效果是怎样的, 我们自己的项目里, 如果效果不主要靠粒子运动而是靠UV动画, 先考虑的优化是能不能尽量用static mesh+dynamic material替代. Data Channel在这里帮不上忙啦