借这个帖子，说说想法，现阶段官方推荐3d项目需要不错的画面和不错的功能的都迁移到最新的render graph。早期在cocos刚刚推出render graph的时候我们就基于render graph开始定制功能。但是当时第一版简直不正常。比如地形不渲染啊，透明材质不渲染啊，摄像机矩阵传递bug啊。基于render graph定制的复杂管线在runtime下跑得越久 cpu就越炸，整个render graph的依赖分析是随着时间增长而增长的，然后里面各种render graph data的stringify和parse，各种用超大graph data做超大key的实现，等等各种问题。当时还没有pipeline cache。所以整个render graph的每帧重建很多对象都是疯狂创建的。然后我们对于cocos render graph的研究止步了，因为当时还不具备release的能力。贴一张图证明一下我不是瞎吹牛逼。的确是做过。
因为当时在render graph上遇到了整个render graph的依赖分析是随着时间增长而增长的巨大问题(从fps和chrome的dev面板上实测而来)而放弃转而采用基于cocos经典管线的方式开始构建适用于项目的渲染管线。我们在cocos经典管线上投入很多，实现了以下功能，
1，超级好用的后处理，bloom，colorgrading，dof，edgedetect，fxaa，grain，smaa，ssao，tonemaping等等
2，pre z pass
3，grab pass
5，非常方便的使用dephtmap和grabmap的方式
6，超大包含很多功能surface shader，比如风吹动顶点动画，下雨打上去的涟漪，覆盖的雪，hue shift等等
7，河，湖，海
8，在opaque和transparent中插入一个cutout。利用pre z pass做overdraw 优化（听起来很奇怪）等
9, 强大的材质系统下各种定制的shader就不说了
但是现在cocos最新版render graph开始支持compute shader和在第一版到3.8中做了很多优化，以及要在原生上使用的话，需要采用render rgaph。因为cocos native整个都是建立在render graph上的。我们打算把功能迁移到render graph上去。所以我上面也说cocos native editor preview目前不算是试验品算残次品，也是希望功能要是正常的。对于做2d游戏的研发来讲也许无所谓。但是对我们来说很重要。因为你提供了compute shader。但是in editor这个功能却是残次品，这意味着研发每次都得发包才能观察是否有问题？毕竟一个空场景在editor中preview都需要大量的加载时间，更不说我们较大的场景了，bug飞起。编辑器随便搞两下就闪退。所以现在editor中preview我们是不用的，但是接下来如果用了compute shader要怎么办？我现在还是在纠结。
来一张图镇贴
cocos render graph和我们自定义的管线后处理对比
再说点cocos 3d体验，cocos 到目前3.8版本为止，已经初步具备了制作复杂3d游戏的能力。我从cocos2dx，cocos js到cocos 1.0到现在cocos 3.8一路走来。做过的项目大小无数。见证cocos的巨大进步。就差一个shader graph了。
对于cocos即将到来的船新vfx和render graph，gpu driver，compute shader能力保持强力的好奇心和应用到我们项目中的提升画面的巨大需求，再次感谢cocos团队的努力。
游戏画面就不展示了，到了要展示的时候再展示。 
算了，我目前用手动拷贝effect uuid的方式也是能写的。麻烦是麻烦了点，能用就行。
其实你点击编辑器里面刷新所有effect，有报错的effect都会暴露出来的，比如刚刚你们把材质系统里面number.chunk的函数迁移到到common-define里面。我们启动编辑器的时候如果不点击刷新所有effect就不会报错的。或者不点击使用了number.chunk的effect文件也不会报错。所有点击刷新所有effect文件是可以检查effect文件错误的。但是现在我已经全部fix了，effect文件已经无问题。只不过下拉菜单出不来而已
