leon

http://www.maiziedu.com/course/u3d/586-8498/

给51cto录制的UNITY3d插件的课程，包含android平台完整的开发demo和真机测试过程http://edu.51cto.com/course/course_id-5436.html

有时我们需要修改Unity为我们生成的在ios上的代码，通常可能要修改主要的是UnityAppController这个类，他是ios的UIApplicationDelegate。我们能想到的方法就是能够继承这个类，这在unity里是支持的，做法是这样的：        编写你自己的类型CustomAppController，继承自UnityAppController，然后把你的CustomAp

有时候我们需要动态加载场景（比如场景比较大，或者一些无限重复的自动生成的场景），这时如果对场景又使用了烘培，那么在unity5里面就会有一些小问题。  1.在这种需求下我们一般会把场景物体存成一个预置，需要的时候加载进来，但是在unity5里面，物体的lightmap信息（index和偏移）并不会记录在预置上，这导致你直接把预置加载进来看不到烘培效果，这里要这样，在加载之后手动的赋值这个lig

1.正常情况下，用最简单的光照或无光照的shader渲染一个mesh， 一个dc2.unity5对烘焙做了修改，烘焙的物体仍然可以接受实时光，这样如果烘焙的物体再受一个实时光，那就是2个dc，unity4不是3.多一盏实时光，就会多一个drawcall，如果使用了deferred shading，则不一样，一些光源会被合并到后面计算，dc会合并减少4.开了实时阴影，会根据情况增加2-4

UGUI使用了新的event机制，我们之前在NGUI中，为了处理ui的交互，通常是在ui组件挂载的mono上写onclick（），onpress（）这些函数，换到ugui后，unity使用了新的event 机制。但是unity的文档解释的很乱，这里整理一下。

项目开始逐渐迁移到unity5上，原有用4的打包流程在5上依然是work的，基本是不用改代码的，但是5对打包做了一些改进，今天在考虑要不要改一下项目的打包代码，使用5的所谓的“”新的方式“，但是仔细研究了一下，法线其实是没必要的，5的打包没解决什么根本问题，下面我对4 和5 的打包策略进行一下对比分析，并说一下我们目前大题的打包方法。

Crash Report，这在大型软件开发领域是很常见的功能，就是能够当程序崩溃退出后，能够将崩溃时的信息，最好是携带dmp文件发送给服务器，这样开发人员既可以获得分发出去的客户端的崩溃率统计，也可以针对出现的错误进行及时的纠正，之前在PC的端游时代，这是很常见的做法，最近进行了在手游上的关于crash report的相关研究，并且为项目编写了一个相对完善的CrashReport模块。

虽然RenderTexture这个技术是个普遍使用的技术，但是用好它还是要理解他的底层原理和避免一些使用的问题。这里就UNITY3d中的RenderTexure介绍Rendertexture的底层原理和使用时可能遇到的坑和效率问题。

在3D渲染中，尤其是现代3D游戏中，我希望能够绘制越来越多的场景物体，这对于设备（尤其是移动端）的性能是个极大的考验，对于新一代的渲染api，都逐渐支持了Gpu Instancing技术，这对于大量相同物体的绘制提供了一个新的方案，在最新的unity5中也提供了对gpu instance 的支持，我尝试在unity5中利用gpu instance 技术来表现大量的植被，并对其性能进行了分析，以探索在3D手游中gpu instance的应用的可行性。

很多游戏类型需要在场景中表现大量的角色，而这些角色大多使用骨骼动画的方式来表现，传统的基于CPU蒙皮的方式在手机上对角色数量的限制非常大，本文实现了一种基于GPU Skin的方式，并且结合GPU Instance技术，将大量同类角色的蒙皮到绘制全交给GPU并行进行，并合并了同类角色的批次，本文对着种做法的性能做了测试和分析。

本人录制的Unity3D系列课程上线了，这是第一套 《unity 常用组件分析》http://www.maiziedu.com/course/others/540-7381/

新的项目中大量使用了将sprite镜像拼接的方式来做底板，结果同事发现有的时候拼的时候中间会出现一个莫名的黑缝，如图：看了下贴图没啥问题，也不是因为贴图压缩的问题，但是这条黑缝总是存在，然后想到这条黑缝很可能是采用uv的时候将uv采到了sprite和其他图的接缝处，然后在跟着看了下NGUI计算uisprite的uv的代码，发现ngui的计算确实存在着严重的问题，NGUI是这样计

最近转U3D开发，个人认为，精通一种新的技术，最快最好的方法就是看它的document，而且个人习惯不喜欢看中文的资料，原汁原味的东西是最正确的，一翻译过来很多东西就都不那么准确了。于是通读了unity的官方manuel，最后面几章都是精华，里面给了非常非常多的官方的优化建议，尤其是做移动平台的开发，这些建议就是非常重要的。我将官方manuel advanced后面的那几个章节的东西提炼了一下出来

1.SerializableThe Serializable attribute lets you embed a class with sub properties in the inspector.让你能够把它嵌入到另外一个class时在属性编辑器里能将其展开 [System.Serializable]class Test{public int p = 5;publ

初学Unity的过程中，会发现打包发布程序后，unity会自动将场景需要引用到的资源打包到安装包里，没有到的不会跟进去。我们在编辑器里看到的Asset中的文件结构只是工作于编辑器环境下的，在游戏中unity会重新组织数据库。这是我们一定会遇到一个需求，即动态的加载我们自己的文件，而且想维护这个文件存储和加载的位置，并且是各种自定义的文件。比如说你换装，需要动态从磁盘load一个模型，正常情况下

Hidden FoldersFolders that start with a dot (e.g. ".UnitTests/", ".svn/") are ignored by Unity. Any assets in there are not imported, and any scripts in there are not compiled. They will not show

发现U3D的模型打包可能存在一个bug，会导致发布到手机上的模型法线丢失（某些材质下变成全黑或全白，编辑器里正常），经查明和测试，解决这个问题的方法：1.对于在MAX中着了顶点色的模型（或者使用了需要顶点色参与的shader），导入模型时不要同时导入材质，要制作成预置后再指定材质，即这里不要勾选2.对于那些没有着顶点色的模型，如果这里选了导入材质，请保证将对应生成的材质

最近做U3D的热更新，研究了各种方式无果后，找到了cslight这个东西，可以在一定范围内动态

项目进入了中期之后，就需要对程序在移动设备上的表现做分析评估和针对性的优化了，首先前期做优化，很多瓶颈没表现出来，能做的东西不多，而且很多指标会凭预想，如果太后期做优化又会太晚，到时发现一些问题改起来返工量就有太大。前一阵子花了大量时间从 cpu gpu 内存 启动时间 到发热量对项目做了一翻大规模的体检和优化，效果还是显著的，在这里做个笔记，以后开发项目时可以作为经验和提前关注

今天下午遇到了

批渲染（Batch）batch render 是大部分引擎提高渲染效率的方法，基本原理就是通过将一些渲染状态一致的物体合成一个大物体，一次提交给gpu进行绘制，如果不batch的话，就要提交给很多次，这可以显著的节省drawcall，实际上这主要节省了cpu的时间，cpu从提交多次到提交一次，对gpu来说也不用多次切换渲染状态。当然能batch的前提一定是渲染状态一致的一组物体。Unity

Unity5带来的最大的改变就是全新的GI，在烘焙引擎上抛弃了4的beast，使用了虚幻采用的Enlighten，引入了实时的全局光。这里对UNITY5的新的光照系统做一总结.

在Unity中的light都有一个属性RenderMode，可以设置light的渲染模式为impotant还是非important，以前只是肤浅的认为important对应的就是像素光，非important就是顶点光，而auto就按照graphic quality里面的设置。后来看了一下unity的文档，其实不是这样，它完全的规则非常复杂：最亮的几个光源会被实现为完全的逐像素光

物理渲染是UNITY5最大的亮点之一，物理渲染的采用绝对是下一个世代游戏的热点，UNITY5的大范围使用是一个可喜可贺的事情，关于什么是物理渲染，本人曾经写过一篇博客专门讨论，详见http://blog.youkuaiyun.com/leonwei/article/details/44539217。       物理渲染和当今的主流光照计算最大的区别就是，当今的lambert blinn phone基本上