层采用正交投影方式进行投影，对所述3d渲染层采用透视投影方式进行投影。

而这两种投影涉及到的计算都极其庞大。

尤其是透视投影是典型的计算密集型投影，这个过程涉及到三角计算。

并不是sinx、cosx那种简单的三角计算，涉及到这个过程中的三角计算通常伴随附加有包括矩阵和矢量相乘的运算。

随着场景中所记录细节的量的增大时，用来渲染该场景的冗长计算的数量也将增大，这对cpu是个极大的考验。

常规情况下，涉及到一般物体的投影计算都很吃cpu。

更何况是涉及到下雨这个场景，如果按照你说得这种办法进行透视投影的话。

实时计算量将随着雨滴数量的增多而呈现出指数增长。

恕我直言，别说5s中的a7处理器是一枚桌面级处理器。

就是a7处理器的处理效能在此基础上再翻一番恐怕也只能勉强满足这种运算需求。

巧妇难为无米之炊，如果真的是采用这种方式的话，现有的cpu水平根本无法提供技术支撑。

假设grayforest所采用的真是这种方式的话。

那么在现有的技术水平下，运行这么一款计算量超级多的游戏时会出现什么样的反应呢？

这些额外的计算大概率会要求以移动设备减小的帧速率进行游戏。

但经过我们的实测同样的5s机型在运行《hillclimbracing》这款游戏时在屋顶场景的小雨环节并不会出现帧速率减小的情况。

这也从侧面验证了我们先前的判断。

即—grayforest在《hillclimbracing》用的绝对不是引入3d渲染区域而后构建折叠册的方式。

除此之外，我觉得grayforest所采用的方式也不是传统意义上的游戏渲染。

一般来说涉及到2d