【性能优化】共享节点-动效复用方案

Creator 2.x
#22

zindex怎么处理

#23

根据我的需求，测试了，发现还是可以解决zindex,不过对静态比较好使，如果让复制节点，移动的话，就比较麻烦了，先处理静态，就是对_copyChidrens数组进行排序,在CopyNode里面加入一个zIndex属性，然后根据这个zIndex属性进行排序，
如果调整了复制节点的问题，就又得排序，所有得节点都需要刷新，哇，想想都是性能受到极大得损耗啊，不知道其他同学有啥解决方式每
this.nodeContainer["_copyChidrens"].sort((a, b) => {

        return b.zIndex - a.zIndex

    })

//后续，刷新CopyNode里面得setPosition就可以静态排序一次zIndex

#24

接上、使用藏标记模式，能够稍微在处理zindex上有性能提升，
如果得复制节点有位置变化我们使用脏标记记录，然后update里面检查藏标记然后重新刷新复制节点

y坐标有变化zindex就有更新，然后针对_copyChidrens得排序也是使用脏标记记录，根据脏标记重新排序
（排序_copyChidrens要在刷新复制节点之前）iphone手机抖音测试效果还不错，1000个精灵，500个运动，cpu能保持在60%左右（初始化空场景大概在50%）所有还是不错得哦！

微信图片_20230503181522
微信图片_202305031815221125×2436 390 KB

#25

牛逼……牛逼啊…。

#26

试过，没效果

#27

检查哪个地方没对哦

#28

没仔细看。可能是fillBuffer合批处

#29

应用不多，就被我弃用了

#30

3.x 早就支持 GPU INSTANCING 啦~

#31

确实是这个问题，方案并不通用

#32

还是有点差别的。gpu instancing技术。你还是要创建n个节点，只是n个节点你预先知道了它们很相似，然后渲染的时候，只发了一个渲染对象的数据，和n个各异的数据。而这个共享节点的方案，其实只创建了一个节点，其余的复制节点里面只有最少的那些差异信息。所以在动态创建节点时会更快捷。当然了，一般情况下，使用对象池已经够用了。这个的应用场景的确不多。

#33

mark mark mark

#34

有原生环境的代码么？大佬

#35

做成插件，然后加入scale ，rotate，这些。 放上商店卖99

#36

战略性MARK

#37

确实很不错,思路也很清晰.

私以为, 适用于场景, 背景等不需要交互操作的物体,

不适合需要操作的东西, 而且共享的spine动作都一致, 这个局限性还是有点大了

#38

mark一下

#39

大佬，这东西可以用来实现可以合批的粒子系统吗？自带的粒子系统不能合批

#40

你做了吗？我的项目也遇到了问题，很多prefab会很卡

#41

2024年的我先Mark一下，空了再研究