诺倾城丶

了解Unity的目录结构 官方参考文档https://docs.unity3d.com/Manual/ExternalVersionControlSystemSupport.html Assets：存储所有游戏资源的文件夹，包括脚本、纹理、声音、编辑器定制等等。是项目中最重要的文件夹。 Library：被导入资源的本地缓存，使用Git做版本控制时不需要管这个文件夹。如果Unity的项目文件太大，可以试试删除Library文件夹 Logs：日志文件夹，由Unity自动生成管理，记录报错崩溃信息，随时可以删除清理 Packages：包配置信息，由Unity自动生成管理，用于放置一些官方组件和第三方插件 ProjectSettings：工程设置信息，由Unity自动生成管理 UserSettings：编辑器的用户构建设置，记录用户的使用偏好，如Unity编辑器的布局方式等等。 Temp：临时文件夹，Unity运行过程中生成的历史文件。 这里是github官方提供的不同工程中gitignore中的内容，但是参考价值不大，我们自己项目工程文件的方式很多样（当然Unity工程文件夹下的基本结 ...

背景 这篇博客本来想聊一聊反射的内容，但是反射的前置知识点优点太多了，所以真正要聊到反射可能要到下一篇博客了。 特性 特性（Attribute）是用于在运行时传递程序中各种元素（比如类、方法、结构、枚举、组件等等）的行为信息的声明性标签。我们可以使用特性向程序添加声明性信息。一个声明性标签是通过放置在它所应用的元素前面的方括号[]来描述的。 特性用于添加元数据，如编译器指令和注释 反射 反射指程序可以访问、检测和修改它本身状态和行为的一种能力。程序集包含模块，而模块包含类型，类型又包含成员。反射提供了封装程序集、模块和类型的对象。我们可以使用反射动态地创建类型的实例，将类型绑定到现有对象上，或者从现有对象中获取类型。然后可以调用类型的方法或者访问其字段和属性。 优缺点 优点： 反射提高了程序的灵活性和扩展性 降低耦合性，提高自适应能力 它允许程序创建和控制任何类的对象，无需提前硬编码目标类 缺点： 性能问题：反射基本上是一种解释操作，用于字段和方法接入时要远慢于直接代码，因此反射机制主要应用在对灵活性和拓展性要求很高的系统框架上，普通程序不建议使用。 使用反射会模糊程序内部的逻辑 ...

安装Butterfly主题 去到Butterfly GitHub主页,在博客根目录运行以下命令: 1git clone -b master https://github.com/jerryc127/hexo-theme-butterfly.git themes/butterfly 完成后,在_config.yml中更改theme为Butterfly(当前的版本为4.5.1),到此还不能够成功启动hexo,硬要启动会报以下错误: 1extends includes/layout.pug block content include ./includes/mixins/post-ui.pug #recent-posts.recent-posts +postUI include includes/pagination.pug 需要先安装以下依赖: 1npm install hexo-renderer-pug hexo-renderer-stylus --save 运行hexo三件套,hexo成功启动. Note:在Mac或者Linux中如果想要更改某个文件夹下所有文件的权限,运行 1chmo ...

Git实践 本章节编写于我在工作中使用过一段时间的git和SourceTree之后，如果正在阅读本文的你已经对git有一个初步的了解了，那么你可以从这里继续看下去，我会在这一小节分享两方面内容：1.Git在开发中的使用流程，2.git与SourceTree使用心得；如果你还不了解git，那么你可以往后翻一翻，先阅读本文后面的Git基础小结。 因此这一次博客更新我将会结合具体的工作场景和Source Tree的图形化界面来说明我们在使用git管理项目时的一套流程规范，流程中的每一个环节我尽量详细阐述，我会演示每个环节如何使用命令行完成，对应地，我也会演示如何使用Source Tree的图形化界面来达到同样的效果。我还有另外一篇文章介绍了我使用Git和Source Tree管理Unity项目中的时候遇到的问题、解决办法，以及一些shell编程相关的知识。 当然，在你看这一部分内容之前，希望你能够对git现有一个基本的了解，比如常用的git add、git commit、git push命令，这部分基础的内容可以点击此处去到本篇博客内对应的部分 注意，我们在实际开发中我们是希望通过使用一个工 ...

博客编写规范 博客头部信息解读 title：博客的标题名称 date：博客的编写日期 tags：文章的标签，可以有多个标签 abbrlink：文章永久化链接，不用管，hexo会帮助我们自动生成 categories： 文章的归档，一般我只会归类一个 cover： 博客文章的封面 description： 文章的描述，如果是将文章放在了swiper中描述才会展示 swiper_index： 博客顶部人潮汹涌那里展示的文章，数字代表展示次序 sticky：顶置文章，数字代表顶置的顺序 多设备同步更新博客 我目前的方案是将我整个博客文件夹，文件夹中的node_modules除外，上传到GitHub上去，下面描述一个具体的场景： 我在A电脑上新建了一篇文章，并且完成了文章的编写，我要做两件事： 第一件事是使用hexo d部署博客到网站上去； 第二件事是使用git push将文件夹上传到GitHub仓库中去。 外挂标签的使用 在文章中实现页内跳转 我有的博客写的很长，有一种情况是：我在博客最开头介绍了一个知识点，然后中间写了很多其他的内容，博客最底部又出现来开头的知识点，导致我上下翻阅很不 ...

背景 最近服务器被挖矿程序攻击了，阿里云疯狂给我发消息，说再不处理要把我的服务器封了，比起找出挖矿程序然后清理掉，我宁愿选择把服务器重制这样更简单粗暴的方法，于是有了这篇文章：从零开始搭建hexo博客部署到阿里云服务器上。 原理 首先在本地hexo生成博客的静态文件 将生成的静态文件部署到云服务器 云服务器通过git-hook同步到网站根目录 搭建流程 本地环境搭建 hexo git nodejs 服务器环境搭建 nginx git 服务器环境搭建步骤 安装git 12yum install git git --version #查看git是否安装成功 创建git用户 12345adduser git#修改权限chmod 740 /etc/sudoers#编辑vim /etc/sudoers 找到如下内容： 12## Allow root to run any commands anywhereroot ALL=(ALL) ALL 在下面添加代码： 1git ALL=(ALL) ALL 保存退 ...

背景 笔者正筹划搭建自己的游戏框架，并希望基于Github和Gitee这类代码托管平台维护和迭代，实现在开发新游戏时快速移植。本文记录笔者将代码发布到Gitee上的过程。 制定规范 一个标准UnityPackage的内部结构大致如下： 123456.├── CHANGELOG.md├── README.md├── LICENSE.md├── Code└── package.json README用来介绍Package的功能和用法；CHANGELOG用来记录Package所有历史版本功能修改、新增和维护日志；README和CHANGELOG不是必须的，但它们可以作为辅助文档帮助使用者更好的理解和使用该Package；而且维护README和CHANGELOG更新可以督促我们养成良好的开发习惯。 LICENSE是开源许可，如果你对你的代码版权不是很重视的话，这也是非必需的；你也可以使用最宽松的MIT开源许可。 Code是Package中实现功能的代码部分了，这一部分的细节会在实践章节中阐述。 package.json是Package中最重要的文件，它记录了Package的版本、url等各种 ...

我们如何看到这个世界 当我们说一个物体的颜色是红色时，是因为这个物体更多地反射了红光波长，而吸收了其他波长。要在计算机上模拟真实的光照环境来生成一张图像，需要考虑三个过程： 首先， 光线从光源中被发射出来 然后，光线和场景中的一些物体相交；一些光线被物体吸收了，而另一些光线被散射到其他方向了 最后，摄像机吸收了一些光，产生了一张图像 光源 在光学中，使用辐照度(irradiance)来量化光。我们用l来表示光线的从光源射出的方向，对于平行光来说，它的辐照度可以用过计算在垂直于l的单位面积上单位时间内穿过的能量来得到。注意这个值表示的是垂直于光线方向上的辐照度，而我们在计算光照模型中，需要知道的是物体表面的辐照度，物体的表面往往是不垂直于l的，所以为了得到物体表面的辐照度，我们需要用光线方向l和物体表面发现n之间夹角的余弦值来得到。 吸收和散射 光线由光源发射出来之后，就会和一些物体相交。通常相交的结果有两个：散射(scattering)和吸收(absorption)。 散射只改变光线的方向，但是不改变光线的密度和颜色。而吸收只改变光线的密度和颜色，不改变光的方向。 我们 ...

背景 最近在配合动效同事使用后处理技术实现Bloom辉光的效果。首先如果要实现Bloom效果是必须开启HDR的，开启HDR之后内存里会增加两个RenderTexture，并且随着屏幕分辨率的增加这两个Render Texture会越来越大，这是无法避免的一部分开销。一开始我们使用的是Unity官方提供的兼容Build-in渲染管线的Post Processing stack V2后处理插件，这个插件十分强大，除了Bloom效果还能实现很多其他的后处理效果。但同时这个插件的开销实在是太大了，在使用了这个插件之后我们只是为了实现一个Bloom效果而造成这么大的内存效是得不偿失的。比起我们要实现的Bloom效果，使用这个插件造成的开销是无法接受的。 为了做优化打出包来做了性能对比分析，发现整个插件造成的主要开销在内存占用上。 在网上找到了一个Bloom插件，但是插件已经比较老了，还是基于Graphics.Blit的方式实现的后处理效果，因此笔者在此插件的基础上实现了基于CommandBuffer的Bloom效果。 前置知识 大概方案 Post Processing后处理 后处理值得是在渲染完 ...

Unity中一个场景下的所有物体，不论是UI、2D物体还是3D物体，都是在一个三维空间中进行渲染的，然后我们透过场景中的一个或多个摄像机观察场景中物体渲染后的遮挡关系。当我们看到物体之间存在某种遮挡关系时，我们一般会直观地认为这是由于不同物体与摄像机之间的距离不同导致的。Unity确实会根据物体距离摄像机的距离来决定渲染结果，除此之外Unity中还提供了其他方式来影响渲染结果，进而改变物体之间的遮挡关系，比如对于两个Canvas物体，我们可以设置离摄像机远的Cavas的SortingOrder大于离摄像机近的Canvas的SortingOrder，然后我们就会看到离摄像机远的Canvas反而渲染在了离摄像机近的Canvas上面。本文记录笔者个人对Unity中渲染顺序的分析理解。 Canvas组件 Canvas组件具有一个名为RenderMode属性 ScreenSpace-Overlay模式下最简单 但是局限性也比较高 不能处理粒子和UI的层级关系 ScreenSpace-Camera 模式可以处理粒子和UI的层级关系 WorldSpace 渲染顺序 所有需要显示的物体都会有Rende ...