原文地址 // input texture Texture2D<float3> _sourceTexture; // a compute buffer that we can append to for output AppendStructuredBuffer<int2> _brightPoints; 在上面的代码段中，_sourceTexture是从外部传给GPU的纹理。和在fragment shader中访问纹理不一样的是，在片元着色器中通过采样器(sampler)获取纹理，纹理坐标是浮点数，而在compute shader中，“纹理”可以视为一个二维数组，可以通过整数索引值，直接访问这“二维数组”中的元素——纹素。 AppendStructedBuffer AppendStructuredBuffer 可视为是原始缓冲区的“升级版”，即结构化缓冲区。原始缓冲区（raw buffer）只是一个字节数组，而结构化缓冲区意味着可以为缓冲区中的每个元素定义一个结构。可以用来AppendStructuredBuffer.Append()方法将元素从缓冲区的末尾加入。重AppendStructuredBuffer.Append()是一个线程安全的操作。即使有数千个线程同时尝试向缓冲区添加某些内容，也不会产生冲突。 // tell Unity that the function "FindBrights" is a compute kernel #pragma kernel FindBrights // define thread groups for the FindBrights kernel [numthreads(32, 32, 1)] pragma kernel 指令 #pragma kernel FindBrights是Unity专用的代码。用来通知Unity函数FindBrights是计算内核(compute kernel)，这意味着它可以用作计算着色器，而不仅仅是一个普通函数。 numthreads指令 numthreads指令的三个输入参数分别表示该着色器在工作组（Work Group）内的线程布局。具体来说，numthreads(x, y, z)指令中xyz三个参数分别定义了在X、Y和Z三个维度上每个工作组中线程的数量。这三个参数决定了工作组内线程的总数量，例如numthreads(8, 8, 1) 就定义了一个工作组包含 8 x 8 x 1 = 64 个线程。工作组的总线程数直接影响计算的并行性，在实际调用时，通过Dispatch()函数定义工作组的分布。如下代码：

请尊重原作者的工作，转载时请务必注明转载自：www.xionggf.com 原文地址 本文主要介绍在U3D中调试shader代码的主要技术：false-color images:通过设置片元颜色中的某个分量，使得该值可视。然后根据resulting image中的颜色分量的亮度（intensity of that color component），你可以得到shader代码中的值的结论，这种技术的确是一种很原始的调试技术，但不幸的是，这在U3D中并不是不常见的。 1 顶点数据来自何方 在RGB cube一节中，你可以看到片元着色器如何通过顶点着色器输出的结构体中，获取到对应的数据。那么问现在的问题是：顶点着色器从何方拿到这些数据？在U3D环境下，答案是从绑定到game object中的Mesh Renderer组件中获取。Mesh Renderer组件将在每一帧中所有的发送网格顶点数据给OpenGL。这一步发送操作通常被称为“draw call”。必须注意的是，每一个的draw call都有一些性能耗费（performance overhead）。因而，一次性地给OpenGL发送一个大的网格数据，比分多次发送，每次发送一些较小的网格数据，要来得更高效些。这些网格数据通常由一系列的三角形组成，而每一个三角形则是以”三个顶点数据和一些其他属性数据“的方式被定义。这些属性数据将会通过”顶点输入参数（vertex input parameter）“的方式在顶点着色器中被启用。每一个顶点输入参数将会指定一系列的语义，如POSITION, NORMAL, TEXCOORD0, TEXCOORD1, TANGENT, COLOR等等。在U3D环境下的Cg语言的特定编程实现中。这些内建的顶点输入参数将会由一个特定的名字。 2 内建的顶点输入参数，以及如何使得它们可视 在U3D中的，内建的顶点输入参数不仅仅有特定的语义表示符号，还有特定的变量名字和类型，此外，他们还被包含在一个单独的结构体中，如下： struct vertexInput { float4 vertex:POSITION; // position (in object coordinates, i.e. local or model coordinates) float4 tangent:TANGENT; // vector orthogonal to the surface normal float3 normal:NORMAL; //surface normal vector (in object coordinates; usually normalized to unit //length float4 texcoord:TEXCOORD0; //0th set of texture coordinates (a.

请尊重原作者的工作，转载时请务必注明转载自：www.xionggf.com 平台 存储位置 macOS 存储在 【~/Library/Preferences】 目录下名字为 【unity.[company name].[product name].plist】 文件中,其中的 【company name】 和 【product names】 在 【Project Settings】 面板中设置。而且这个plist文件是为编辑器版本和单独可执行版本的程序共同使用。 Windows 存在注册表中的注册项中，该注册项的路径是 【HKEY_CURRENT_USER\Software[company name][product name]】。其中的 【company name】 和 【product names】 在 【Project Settings】 面板中设置。注意编辑器版本和单独可执行版本的注册表路径是不同的，例如 【company name】 是 “TomCompany” ,例如 【product name】 是 “TomGame” 的话，在编辑器中执行程序，其注册项路径为 【计算机\HKEY_CURRENT_USER\Software\Unity\UnityEditor\TomCompany\TomGame】 Linux PlayerPrefs存储在 【~/.config/unity3d/[CompanyName]/[ProductName]】 。其中的 【company name】 和 【product names】 在 【Project Settings】 面板中设置.。 Windows Store Apps PlayerPrefs存储在 【%userprofile%\AppData\Local\Packages[ProductPackageId]\LocalState\playerprefs.dat】 文件中 Windows Phone 8 PlayerPrefs存储在应用的 “local folder” 中，可查阅Directory.

请尊重原作者的工作，转载时请务必注明转载自：www.xionggf.com 1 对碰撞做出响应所必须的条件 要想两个物体A，B发生碰撞检测，即触发OnCollision相关事件，或者触发OnTrigger相关事件。必须： 物体A,B都挂接上了一个碰撞器组件，即Collider类（2D环境下是Collider2D类）的子类 运动着的物体，要携带一个刚体组件，即RigidBody类（2D环境下是RigidBody2D类），另一方的物体如果是静止的话，可以不用携带刚体组件。 2 碰撞时触发OnCollision相关事件的条件 在满足第1节中所提出的条件下，当两者的刚体组件（如果有的话）的Is Kinematic属性都未勾选，且两者的碰撞器组件的Is Trigger属性，都没勾选时，便会触发OnCollision相关事件。 3 碰撞时触发OnCollision相关事件的条件 在满足第1节中所提出的条件下，当两者的碰撞器组件的Is Trigger属性，其中有一个勾选时，就会触发OnTrigger相关事件。 4 响应事件的分类 响应事件分为Enter、Stay、Exit。以OnTrigger为例，就是OnTriggerEnter、OnTriggerStay、OnTriggerExit（2D环境下就是OnTriggerEnter2D，OnTriggerStay2D，OnTriggerExit2D，OnCollision事件以此类推）。 Enter事件便是两个物体碰撞的那一瞬间，此事件在碰撞过程会执行一次 Stay事件表示两个物体在持续接触时，此事件在碰撞过程会多次执行。 Exit事件便是两个物体在分开的那一瞬间，此事件在碰撞过程会执行一次

请尊重原作者的工作，转载时请务必注明转载自：www.xionggf.com 项目组使用Unity3D4.6进行渠道商SDK接入，在编译Android版本时，发现部分渠道商提供的SDK包在编译时会出现如下图的问题： 经查证，新版本的Unity3D采用了较高版本的libpng库作为png格式图片的处理模块，产生此问题的原因是新版本的libpng对png的ICCP采用了更严格的约束条件，因此，我们必须使用软件对渠道商提供的这些资源png图片进行处理，以解决这个问题。开源软件 ImageMagick 提供了处理这个问题的方案。 从ImageMagick网站下载了ImageMagick Display软件包，安装后如下图： 我们使用软件包中的convert.exe程序对这些图片进行处理。convert程序是一个命令行程序，该程序有很多开关参数。我们使用-strip参数处理。命令行格式为： convert 待处理的图片的文件名 -strip 处理后输出的图片文件名 如果需要一口气处理同一文件夹下的许多png，我们可以将处理命令写成一个批处理文件，代码如下： set fn=E:\software\ImageMagick-6.9.0-Q16\convert.exe for /f "tokens=*" %%i in ('dir/s/b *.png') do "%fn%" "%%i" -strip "%%i"

请尊重原作者的工作，转载时请务必注明转载自：www.xionggf.com 项目主美反映了一个问题，即在U3D中，给模型使用了镜面高光的材质，结果模型的边缘有很多白色的杂点，如果换用了普通漫反射材质的话，杂点的明显稍微没那么强烈，如下图，左边是使用了镜面高光材质，右边是使用了漫反射材质。 一开始，我以为是因为模型的Z-fighting问题，即两个带纹理的模型因为太靠近了，导致因渲染时的精度问题而造成模型的穿插。但后来检查了模型，并不存在“靴子里面还套着小腿”的这种情况。所以不是Z-fighting的问题。 后来google了一下，发现老外们也曾经发现过类似的问题。最终有人提出这是一个因为抗锯齿做得不好的问题，解决方案就是给摄像机加一个基于image post process机制的脚本AntialiasingAsPostEffect，然后选用FXAA反走样的着色器。加入之后，效果不错，杂点问题得到了较为明显的改善。 KlayGE引擎开发者，大神龚敏敏认为基于post process处理的技术目前已经是逐渐成为主流。nVidia等公司有很多大牛也提出了不少的算法。比如FXAA算法就是由nVidia的研究员Timothy Lottes提出的算法。所以可以预见不远的将来这项技术会逐渐普及。但目前因为硬件能力的问题，在手机移动平台上，依然要注意使用这种算法的性能问题。

请尊重原作者的工作，转载时请务必注明转载自：www.xionggf.com Unity烘焙的LightMap是32bit的HDR图，而移动设备通常不支持 HDR图(32bit per channel) ，会按照 LDR图(8bit per channel) 的形式进行处理，因此会出现色偏问题。即颜色变淡，在例子中地面为绿色，因此相比于PC平台，切到移动平台如Android或者iOS上之后，黄色变淡，使得地面的绿色更加显眼。对此Unity3D技术支持人员的的建议是： 可尝试自行修改LightMap的DecodeLightmap函数，该函数可在 Unity\Editor\Data\CGIncludes\UnityCG.cginc 文件中找到。需要说明的是，这种方法也不能达到与PC端完全一致的效果。 为了避免类似问题，请不要使用过于强烈的Light进行烘焙，因为Light的强度(Intensity)越高，色偏问题会越严重。

请尊重原作者的工作，转载时请务必注明转载自：www.xionggf.com 1 功能列表 功能 Vertex Lit Rendering Path Forward Rendering Path Deferred Rendering Path 逐像素光照效果（Normal map等） N Y Y 多render pass支持 仅在一个render pass中完成光照计算 允许多render pass 允许多render pass 逐像素实时阴影 N 仅支持一盏Directional Light Y 双光照贴图(Dual Lightmaps) N N Y 深度缓冲区和法线缓冲区 N Additional Render Pass Y 软粒子（soft particle） N N Y 半透明的物体（Semitransparent objects） N Y Y 反走样（抗锯齿 anti aliasing） N Y Y 灯光剔除蒙版(Lighting Culling masks) 受限制 Y Y 光照保真度（Lighting Fidelity） 所有光照计算在顶点着色器中执行 部分光照计算在片元着色器中执行 所有光照计算在片元着色器中执行 每像素光照的性能耗费 像素数 像素数*被实时光照亮的像素数 PC上的所需的最低shader model版本 任意版本 最低2.

请尊重原作者的工作，转载时请务必注明转载自：www.xionggf.com 目录名 作用 仅能放置于工程根目录吗 会打包进最终发布包吗 仅在编辑阶段使用吗 读取方式 打包时会原样保留原始文件格式吗 Editor 放置一些第三方或者自定义的编辑辅助工具的代码 N N Y - Editor Default Resources 编辑器用到的一些资源，比如图片、文本文件、等等。放在这里 Y N Y 调用EditorGUIUtility.Load读取 - Gizmos 用来在编辑阶段绘制一些辅助图标辅助线条 Y N Y 在MonoBehavior类的OnDrawGizmos方法中使用 - Plugins Andoird 或者 iOS平台下，要给工程接一些SDK时可以把SDK依赖的库文件如 .so .jar .a文件放置从此处 N Y N - N Resources Resources文件夹下的资源不管你用还是不用都会被打包进.apk或者.ipa N Y N Resource.Load函数： 编辑时和运行时都可以通过Resource.Load来直接读取。Resources.LoadAssetAtPath它可以读取Assets目录下的任意文件夹下的资源，它可以在编辑时或者编辑器运行时用，它但是它不能在真机上用，它的路径是 ”Assets/xx/xx.xxx” 必须是这种路径，并且要带文件的后缀名。 N StreamingAssets 并且它是一个只读的文件夹，就是程序运行时只能读 不能写。它在各个平台下的路径是不同的 N Y N Application.streamingAssetsPath 是访问这些目录下的资源路径的方法。它会根据当前的平台选择对应的路径。 Y Application类中定义的若干路径在不同平台下的具体值如下表： 变量Application.dataPath Windows: – Android: /data/app/xxx.xxx.xxx.apk iOS: Application/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/xxx.app/Data 变量Application.streamingAssetsPath

请尊重原作者的工作，转载时请务必注明转载自：www.xionggf.com 1 什么是全局光照（Global Illumination） 在阐述什么是全局光照之前，我们先简与之对应的局部光照。粗略地说，所谓局部光照，就是我们在渲染一个场景时，仅仅考虑光源和物体之间的交互，而不考虑物体与物体之间的光线交互——即每一个物体表面的颜色，仅仅由光源发出的光线贡献，而不考虑由其他物体所反射过来的光线的贡献。 全局光照则是在局部光照的基础上，增加考虑物体与物体之间光线交互。所以说如果局部光照系统就是由光源+待渲染物体+视点组成的话，那么全局光照系统就是由光源+各待渲染物体之间的反射光+待渲染物体+视点组成。 从是否是即时性来分，GI可分为实时（又可称为在线）光照和 非实时（又可称为离线） 光照。如果是离线光照的话，待渲染物体之间的反射光就是通过辐射度算法或者是光线追踪算法逐点计算出来的。这些算法是相当耗时的，无法应用在实时GI上（当然随着硬件的发展，不排除原本只适用于离线光照的算法在未来能应用在实时上）。 2 光照的各种方式 如上所述，GI是在局部光照的基础上，增加了对待渲染物体之间的光线交互的计算。从而使得渲染效果更逼真。对Unity3D而言。照明模式（lighting mode）分为实时照明和烘焙照明两大类，其中烘焙照明又可以分为预计算光照和烘焙光照贴图这两种。首先看实时照明的方式。 2.1 实时照明 在不做任何修改设置的情况下，Unity的光源(包括directional light,、spot light、point light)都是实时的，代表这些光源会把光线照射到场景并以每一帧的频率更新，由于光源是可以在场景内移动的对象，场景灯光的更新是实时的，你可以在游戏窗口和场景窗口看到改变。如下图 注意上图：因为没有反射光源的关系阴影是全黑的，只有投射光锥体范围内的对象表面才有光源影响。实时照明是场景里照亮物体最基本的方法，用来照亮角色和会动的对象，但默认设置里Unity实时照明里的光线不会反射，（也就是说，从A物体反射出来的光线，就算是在物理学上应该会入射到B物体。但在渲染中，计算B物体的最终颜色时，并不考虑这个从A物体反射过来的光线的贡献）。因此，我们才导入了全局光照系统，启用了预先计算的技术，都是为了表现一个更逼真的场景。 2.2 烘焙照明 2.2.1 烘焙全局光照贴图（Baked GI Lighting） 当烘焙一张光照贴图(Lightmap)时，场景内的静态对象会根据当前场景内的光照，算出一张渲染结果贴图，并覆盖在场景对象之上建立照明效果，如下图： 这些”光照贴图”可以包含场景内投射到物体表面的直接光源，以及在不同物体间反射的”间接光源”，这样的光照贴图可以通过使用着色器(Shader)描述物体的表面信息(Albedo)和凹凸(Normals)信息。 使用这种烘焙方式所产生出来的光照贴图，是无法在运行期发生变化的，因此被定义为静态(Static)，虽然仍可在这层贴图上继续迭加光源计算，但两者已无法交互运算，通常我们采用这光照法来让低阶的手机能顺利执行，解决光在游戏中运行的性能问题。 2.2.2预计算全局光照(Precomputed Realtime GI Lighting) 虽然这种静态光照贴图无法在游戏执行时改变场景光照效果，但预先计算的实时全局光照系统，则能实时地去计算算复杂的场景光源的变化，通过这种方法，就能建立一个丰富的全局光照反射场景，并实时反映光源的改变。好比做个日晷，阴影的位置和颜色会随着光源移动改变，这在原本的烘焙光照系统是无法达成的。 为了能够实时地实现这些效果，需要在实时运算之前先将场景中的相关光照数据做一次”预计算”，所谓的预计算负责计算游戏过程中光的复杂行为，它可以在时间空档时进行计算，因此称作一个”脱机”运算，或者可称为“离线”运算。 3 Unity3D 5中的全局烘焙照明 在上节我们提到Unity3D 5的GI系统有两种烘焙模式，因此，Unity3D 5在Lighting Windows窗口中提供了这两种的模式的操作。 Unity3D 5的Lighting Window可以在通过菜单【Windows|Lighting】打开。 在Unity3D 5的灯光组件中，有一个Baking属性，这个Baking属性有三种选项，分别是Realtime、Baked、Mixed这三种属性。而这三种属性，则又分别对应于Lighting Window中的Scene Tab界面中的【Precomputed Realtime GI】和【Baked GI】这两个选项的组合，如下图 3.1只勾选【Precomputed Realtime GI】选项 关闭当在scene tab面板中，关闭了【Baked GI】选项。或者将场景中的全部光源类型设置为【Realtime】的时候这意味着没有任何的光会被预先烘焙出光照贴图。引擎在“烘焙”时，仅仅是存储场景内静态物体间的关系，当烘焙完成后你可以自由的调整光源或物体材质，并实时地看到效果。 此时在Scene中观察Baked结果可以看到没有任何静态颜色被烘焙出来。 如果在scene tab中，仅启用了【Precomputed Realtime GI】选项时，则场景中的光源应该选择Realtime类型。烘焙选项【Realtime Resolutio】对应前文所说的间接光照图，值越高间接光的效果就越明显（其实应该是越准确，当分辨率太低时间接光会因像素过滤而变弱） 。如下图，注意红色盒子投递在白色盒子上的影子。如下图当Realtime Resolution的值为10时 如下图当Realtime Resolution的值为1时 3.2 只勾选【Baked GI】选项 当在scene tab中，取消【Precomputed Realtime GI】选项，而启用【Baked GI】的话。这时候光源则依赖于他的Baking属性去分别参与静态光照贴图的烘焙：属性为Realtime的灯光，不参与静态光照烘焙，但同时作用于动态与静态物体上；属性为Mixed的光源，参与静态光照贴图的烘焙，而在运行时，则仅作用于非静态物体；属性为Baked光源，仅作用于静态光照贴图的烘焙，在运行时不参与实时光照计算。如下图可再次观察SceneView可以看到烘焙出来的颜色。