地图比较大，屏幕外的场景和人物会被渲染么？如果渲染的话怎么进行优化呢？
1赞
超出屏幕的元素，设置active为false反之为true
如果我没有理解错的话是不会被渲染，但对象剪裁算法貌似是爆力法的视锥体裁剪，不是基于八叉树的快速裁剪法，也没有基于BSP的潜在可见集那种预处理流程。
小体量游戏使用爆力法也可以，但暴力法的性能与场景规模大小(对象多少)线性相关。
所以我最近在做一系列测试，看看引擎性能是否能满足产品开发需求，如果真不行的话只有换Unity了。
顺便转载一个粉丝制作<zelda时之笛>的地图大小示意图
当然大不代表每帧渲染的面数就多，有些一个巨大的岩石只有很少几个面。
当然不会哦
就是说超出屏幕的也会运行渲染？需要手动设置active？
测试结果方便分享么，基于什么引擎版本
不会，但是会递归检查，最好还是手动一下
没啥好分享的，测试方法不是很专业。就是根据想做的游戏内容体量，去sketchfab上找到相应的素材，然后把场景堆积到跟预定目标差不多大的场景，然后进行一些场景漫游和物理方面的测试。
测试不是是十合理的，只是有一个大致的底子，因为实际开发产品用心优化的话场景应该有按需要加载/卸载(level streaming)的能力，而且没有实际的音效，粒子，特效，基于顶点着色器的植被动画等，并不能反应客观真实的引擎性能。
这是一个voxel场景的测试，200多万三角面，4K帖图，渲染性能还是可以的，但我手里的android手机不支持4K帖图暂时没法测试。
场景如果做合适的切分，然后用一些root node进行动态的active设置协助引擎进行快速剔除节点，应该能扛住体量不太大的产品。
我在想不搞太复杂的话，可以写一个四叉树脚本进行场景的node管理，实现level streaming应该可以
这个场景的大小是(105x125米)差不多就是2个足球场大，根据我上面发的zelda时之笛对比图，除了两块最大的地图，都<=2个足球场大小的样子，只要场景做好优化，应该能搞得定zelda时之笛这种体量的产品，前提是不要用太多高大上的PBR帖图。
希望引擎组继续优化引擎，提升渲染效果，对Cocos Creator还是很有信心的！加油，国产之光！让那些U管上喷国产引擎的go die!
这里有一个不错的场景，几千个cube，但帖图非常小，理论上这是一个对手机性能要求不高的场景，是个不错的压测场景。
Desktop Web构建运行还算流畅，中低端手机上很卡顿，渲染场景时culling算法如果能优化到让这个场景在中端手机上不卡，引擎就很合用了。
https://sketchfab.com/3d-models/voxel-kakariko-full-scene-6ef46d45927945259127a73484f10d24
vivo z3 骁龙710, 64G手机运行效果，5 FPS，ppt效果
你这感觉完全没合批呢
确实没有，gltf下载回来就是这样的。
然后我导入blender里合并全部为1个mesh, pc上可以跑起来，手机上跑不了模型不会显示，考虑是一个drawcall无法支持那么大数量顶点数，然后又尝试用loose by parts自动切分模型，再跑有部分可以渲染部分不渲染，猜测不渲染的还是因为顶点数太大，但帧率提高到4-50 FPS.
这样大致心里就有底了，模型即要合批，又需要适当拆分，有几个要点:
- 不能合成太巨大的模型, 手机上一个drawcall能支持的顶点数有限
- 不能不合批直接渲染数量巨大(但每个模型顶点数很少)的小模型
- 要在场景中模型数量和模型的顶点数量之间均衡进行合并
这样就知道下一步性能测试的要点了，要测出场景中模型数量和每个模型顶点数量的最佳组合值
引擎文档上我没看到或是没有找到限制说明，但猜测+google搜索，在手机上一个drawcall顶点数量可能不能超过65535
要看 GL 的限制
期待老哥的测试总结
恩，测来测去对引擎还是基本满意的，无非就是渲染器起步稍晚效果上还差一点，但这个有google filament这种成熟的移动端PBR渲染器可以参考，相信引擎组的大大们很快可以追上。
物理引擎这块都很成熟相信后面也不会有什么问题，那么最后一块可能是瓶颈的地方就是culling算法了，当场景比较大对象比较多的时候，需要算法能快速收捻而不是线性相关，我觉得初期可能八叉树算法搞一下就差不多了。