毕业论文unity图形渲染

1、在unity场景中创建一个立方体。

2、在项目脚本文件夹中创建一个“Hidden”脚本。

3、在start方法中关闭渲染。().enabled=false。

4、在update方法中监听按键，在按下S键渲染显示物体。

5、把Hidden脚本添加到立方体上面。

6、现在按下“S”键，立方体就显示出来了。

Graphics Job 勾选时，将允许Unity 使用Worker threads 来处理原本在主线程和渲染线程 减少可见的物体数量 调整摄像机的远裁剪面并使用雾效来弥补远处物体无法被看见的失真现象 使用摄像机（camera）组件的layer cull distance 属性为不同层次的物体设置裁剪距离，如此可以保持场景的真实的前提下减少需要被渲染的物体数量 使用occlusion culling 技术 实时光照、阴影和反射等效果可能会导致物体被渲染多次，从而影响性能。挑选合适的渲染路径对渲染性能有很大影响。一般情况下，Deffered Rendering 更适合使用大量实时光照、阴影和反射效果的高端设备，Forward Rendering 更加适合低端设备。 渲染实时阴影时，首先需要将会产生阴影的所有物体渲染进shadow map，因此有明显的渲染消耗。 对于静态物体（不会移动的物体）可以使用烘焙技术来预计算光照从而减少实时光照计算。 对于使用实时阴影的项目，使用Shadow Distance、Shadow Cascades 等技术有效优化实时阴影造成的渲染消耗。 反射探针可以创建非常真实的反射效果，但是会造成batches 上的开销，应该尽量减少使用。 可以合并为同一个批次（batch）的物体必须满足两个条件：使用同一个材质的同一个实例；拥有完全相同的材质设置（texture、shader、shader 的参数等）。尽量让更多的物体使用相同的材质以更好地利用合批（batching）技术 通过图集技术可以增加合批物体数量：对于那些使用相同材质，仅仅是材质实例使用不同贴图的情况，使用图集技术将不同的贴图打包进一个图集中，这样就可以使用同一个材质实例，达成合批条件。 注意 和 的区别，前者被修改后将会创建一个新的材质实例（无法合批）。 对于Shadow Caster Pass，只要其内部使用的属性相同，即使其在不同的材质中仍然可以和合批。 静态合批（static batching）可能会导致更高的内存和存储消耗：静态合批前，每个参与合批的物体都会创建一个副本，因此不适合密集型显示的物体群（例如茂密森林中的树木） 动态合批会导致一定的cpu 消耗。 目前支持合批的组件有MeshRenderer、Trail Renderers、LineRenderers、Particle System 和Sprite Renderers。 SkinnedMeshRenderer 不支持合批，可以使用 方法创建一个合适的pose 后改用MeshRenderer 以支持合批技术。 如果目标平台支持，尝试开启Player Settings 中的GPU Skinning，让GPU 接管蒙皮。 由于半透明物体需要严格按照从后往前的顺序渲染，相较于不透明物体而言，他们更难达成合批条件。 降低片元着色器的计算复杂度 检查透明材质、粒子系统和UI 元素的重叠情况，防止过量的overdraw 过量的后处理很容易导致像素填充率问题，如果需要用到大量的后处理效果，考虑将这些后处理合并到一个pass 中，例如Unity 提供的PostProcessing Stack 通过降低纹理内存占用来解决内存带宽问题。 使用纹理压缩技术可以极大减少纹理的大小。 使用Mipmap 技术可以降低远处物体占用内存带宽的问题。

所谓GPU的渲染管线，听起来好像很高深的样子，其实我们可以把它理解为一个流程，就是我们告诉GPU一堆数据，最后得出来一副二维图像，而这些数据就包括了”视点、三维物体、光源、照明模型、纹理”等元素。 在各种图形学的书中，渲染管线主要分为三个阶段：应用程序阶段、几何阶段、光栅阶段。 1，应用程序阶段。 这个阶段相对比较好理解，就比如我们在Unity里开发了一个游戏，其实很多底层的东西Unity都帮我们实现好了，例如碰撞检测、视锥剪裁等等，这个阶段主要是和CPU、内存打交道，在把该计算的都计算完以后，在这个阶段的末端，这些计算好的数据（顶点坐标、法向量、纹理坐标、纹理）就会通过数据总线传给图形硬件，作为我们进一步处理的源数据。 2，几何阶段。 主要负责顶点坐标变换、光照、裁剪、投影以及屏幕映射，改阶段基于GPU进行运算，在该阶段的末端得到了经过变换和投影之后的顶点坐标、颜色、以及纹理坐标。简而言之，几何阶段的主要工作就是“变换三维顶点坐标”和“光照计算”。 问题随之而来，为什么要变换顶点坐标？我是这么理解的，比如你有一个三维游戏场景，场景中的每个模型都可以用一个向量来确定它的位置，但如何让计算机根据这些坐标把模型正确的、有层次的画在屏幕上？这就是我们需要变换三维顶点坐标的原因，最终目的就是让GPU可以将这些三维数据绘制到二维屏幕上。 根据顶点坐标变换的先后顺序，主要有如下几个坐标空间：Object space，模型坐标空间；World space，世界坐标空间；Eye space，观察坐标空间；Clip and Project space，屏幕坐标空间。下图就是GPU的整个处理流程，深色区域就是顶点坐标空间的变换流程，大家了解一下即可，我们需要关注的是每个坐标空间的具体含义和坐标空间之间转换的方法。 ，从object space到world space object space有两层核心含义，第一，object space中的坐标值就是模型文件中的顶点值，这些值是在建立模型时得到的，例如一个.max文件，里面包含的数据就是object space的坐标。第二，object space的坐标与其他物体没有任何参照关系，这是object space和world space区分的关键。world space坐标的实际意义就有有一个坐标原点，物体跟坐标原点相比较才能知道自己的确切位置。例如在unity中，我们将一个模型导入到场景中以后，它的transform就是世界坐标。 ，从world space到eye space 所谓eye space，就是以摄像机为原点，由视线方向、视角和远近平面，共同组成的一个梯形体，如下图，称之为视锥(viewing frustum)。近平面，是梯形体较小的矩形面，也是靠近摄像机的平面，远平面就是梯形体较大的矩形，作为投影平面。在这个梯形体的内的数据是可见的，超出的部分会被视点去除，也叫视锥剪裁。 例如在游戏中的漫游功能，屏幕的内容随摄像机的移动而变化，这是因为GPU将物体的顶点坐标从world space转换到了eye space。 ，从eye space到project and clip space eye space坐标转换到project and clip space坐标的过程其实就是一个投影、剪裁、映射的过程。因为在不规则的视锥体内剪裁是一件非常困难的事，所以前人们将剪裁安排到一个单位立方体中进行，这个立方体被称为规范立方体（CCV），CVV的近平面（对应视锥体的近平面）的x、y坐标对应屏幕像素坐标（左下角0、0），z代表画面像素深度。所以这个转换过程事实上由三步组成： （1），用透视变换矩阵把顶点从视锥体变换到CVV中； （2），在CVV内进行剪裁； （3），屏幕映射：将经过前两步得到的坐标映射到屏幕坐标系上。 ，primitive assembly（图元装配）和triangle setup（三角形处理） 到目前为止我们得到了一堆顶点的数据，这一步就是根据这些顶点的原始连接关系还原出网格结构。网格由顶点和索引组成，这个阶段就是根据索引将顶点链接到一起，组成线、面单元，然后进行剪裁，如果一个三角形超出屏幕以外，例如两个顶点在屏幕内，一个顶点在屏幕外，这时我们在屏幕上看到的就是一个四边形，然后把这个四边形切成两个小的三角形。 现在我们得到了一堆在屏幕坐标上的三角形面片，这些面片是用于光栅化的。 3，光栅化阶段。 经过上面的步骤之后，我们得到了每个点的屏幕坐标值，和我们需要绘制的图元，但此时还有两个问题： （1）屏幕坐标是浮点数，但像素是用整数来表示的，如何确定屏幕坐标值所对应的像素？ （2）如何根据已确定位置的点，在屏幕上画出线段或者三角形？ 对于问题1，绘制的位置只能接近两指定端点间的实际线段位置，例如，一条线段的位置是（， ），转换为像素位置就是（10，21）。 问题2，涉及到具体的画线和填充算法，有兴趣的话可以研究。 这个过程结束后，顶点和图元已经对应到像素，之后的流程就是如何处理像素，即给像素赋予颜色值。 给像素赋予颜色的阶段称为Pixel Operation，是在更新帧缓存之前，执行最后一系列针对每个片段的操作，其目的是计算出每个像素的颜色值。在这个阶段，被遮挡的面通过一个被称为深度测试的过程消除。 pixel operation包含下面这些流程： （1）消除遮挡面； （2）Texture operation，纹理操作，根据像素的纹理坐标，查询对应的纹理值； （3）Blending，通常称为alpha blending，根据目前已经画好的颜色，与正在计算的颜色的alpha值混合，形成新的颜色。 （4）Filtering，将正在计算的颜色经过某种滤镜后输出。 该阶段之后，像素的颜色值被写入帧缓存中。