unreal 和vs版本

2017-04-15 22:11:42 or7rccl 阅读数 375
  • 搭建UE4开发环境

    通过本课程的学习,你讲可以掌握Unreal引擎开发的基础知识,包括Unreal编辑器的基本使用,Gameplay Framework,以及C++&Blueprint;两种开发模式。

    60124人学习 房燕良
    免费试看

Visual Studio的UnrealVS扩展提供了在使用虚幻引擎进行开发时对常见操作的轻松访问。

unrealvs_toolbar_cmd.png

功能包括:

  • 设置启动项目。

  • 编译启动项目的可绑定命令。

  • 设置命令行参数。

  • 批量编译项目。

  • 快速编译项目菜单。

UnrealVS扩展 无法 与 Visual Studio Express 版本 共同运作。它仅与Visual Studio专业版兼容。

安装及设置

如需安装UnrealVS扩展:

  1. 在以下位置搜寻您的Visual Studio版本的扩展:

    [UE4RootLocation]/Engine/Extras/UnrealVS/<VS-Version>/UnrealVS.vsix
  2. 双击 UnrealVS.vsix文件来开始安装。

  3. UnrealVS扩展可用于特定的Visual Studio版本。请注意安装程序正在查找您的版本并且框体已经更新,然后点击Install按钮以继续。

    install_dialog.png

  4. 在安装完成后,点击Close按钮。

    Install Complete

  5. 运行Visual Studio并且在 工具->扩展和更新... 中,您应该可以看到该扩展。

    Extension Manager

    如果Visual Studio已经在运行,您需要在载入和显示扩展前重新启动。

  6. 扩展同时在 帮助->关于微软Visual Studio 对话框的已安装产品列表中显示。

  7. 转到 视图->工具栏 或对Visual Studio工具栏区域 右键点击 ,然后选择 UnrealVS 以显示扩展的工具栏。

    UnrealVS Toolbar

  8. 默认情况下,工具栏出现在上方,但其内容可通过选择 命令 选项卡的 UnrealVS 工具栏的 工具->自定义... 来进行自定义。

    UnrealVS Customize Toolbar

  9. 在自定义对话框中,选择 Categories(分类)列表的 添加命令... 并选择 UnrealVS 来查看可添加到工具栏的UnrealVS命令列表。

    UnrealVS Customize Commands

设置启动项目

启动项目 下拉框是在 启动项目 间快速设置或切换的方法。它会自动在解决方案中列出编译可执行程序的所有可用项目。从列表中选择项目并将其设置为当前的 启动项目 。

startup_project_menu.png

您可以变更位于UnrealVS选项的项目。如需只显示游戏项目,请转到 工具->选项... 并选择 UnrealVS 。

options_screen.png

编译启动项目

扩展还包含了编译当前 启动项目 的命令,它可被绑定到热键或其他正在运行的自定义命令上。

如需绑定命令到热键:

  1. 请转到 工具->选项... 并选择 选项 对话框的 键盘 。

  2. 在命令列表中选择 UnrealVS.BuildStartupProject 命令。

    在搜索框中输入'UnrealVS来筛选列表。

    Filtered Command List

  3. 选中命令后,点击 按下快捷键 框体并随后按下您想要用于执行命令的按键组合。(例如, Ctrl + Alt + Shift + B 显示在下方的示例中)

    Shortcut Keys

    您应该选择当前未被指派给另一个命令的按键组合。Shortcut currently used by (快捷方式当前正被使用)框体将告知您选定的组合当前已被使用的事实。

  4. 按下Assign按钮来绑定按键到命令。这些按键被显示在 Shortcuts for selected command (选定命令的快捷方式)框体中。

    Assigned Keys

  5. 点击 OK 按钮来保存修改。现在,当您使用快捷方式时,设置为 启动项目 的项目会自动进行编译。

命令行参数

命令行 控制用于在运行调试会话时对当前项目设置 命令参数。这是通过项目 属性 来对其进行设置的快捷方式。实际上,此处的变更会在 属性 中被自动反映出来,反之亦然。

在文本框中输入参数或使用下拉列表从最近的参数列表中选择。在调试会话启动时,它们将被传递到可执行程序中。

Command Arguments

对编译虚幻引擎的游戏项目的项目配置自动添加项目名称到命令行,以告知编辑器可执行文件您正在使用的项目。 举例来说,如果您使用编译配置'Debug Editor'(调试编辑器)来编译QAGame,命令行将添加QAGame.uproject到命令参数而无需在框体中输入它。 如需启动QAGame的编辑器,您可以把 命令行 控制留空,编辑器将仍然会知道您正在运行的项目。

请参阅命令行参数以获得所有可用参数的列表。

刷新项目

项目文件可使用自动生成项目文件在Visual Studio中生成。这使得同步和更新所有项目文件变得更快,因为您不必查看.bat文件并手动运行它。

如您想要刷新项目文件:

  1. 按下 UnrealVS 工具栏的刷新项目Refresh Projects按钮。

  2. 项目生成过程将会随着 输出 窗口的出现而显示。

    Project Generator Output

  3. 当提示您时,重新载入任意需要它的项目。

批量编译程序

UnrealVS批量编译程序 提供了一种方式让我们可以创建和运行自定义的编译任务的设置。它比Visual Studio中的 编译->批量编译... 选项更好用。

如需打开批量编译程序窗口:

  1. 按下 UnrealVS 工具栏的批量编译程序Batch Builder按钮或使用您指派给命令 UnrealVS.BatchBuilder 的键盘快捷方式(请参阅以上的 编译启动项目 来获得对使用 UnrealVS 命令的键盘快捷方式进行设置的指南)。

  2. UnrealVS批量编译程序 窗口如图。

    Batch Builder Window

    • 通过设置项目,配置,平台和任务类型来创建 编译任务 。

    • 使用箭头按钮来添加/移除任务。

    • 使用箭头按钮把选择的任务在列表中上/下移动。

    • 控制将会对当前在组合中显示的 任务设置 进行编辑。

    • 如需创建新建 任务设置 ,在组合中输入新建名称。

    • 您可以使用下拉列表选择已存的 任务设置 。

    • 删除 按钮会把选择的 任务设置 从列表中删除。

    • 使用 开始 按钮来开始/停止当前 任务设置 上的批量编译任务。

    • 任务设置 被存储在.suo文件中以供载入的解决方案的下次使用。

  3. 当您点击 开始 时,出现的 输出 选项卡会显示编译版本的进度。

    Batch Builder Window running

    • 运行设置中的 编译任务 被显示在输出列表中。

      • Queued Build Job - 排队任务

      • Succeeded Build Job - 完成,后续任务

      • Failed Build Job - 失败任务

      • Cancelled Build Job - 取消任务

      • 当前的 正在执行的编译任务以粗体显示

    • 当批量编译在运行时,会显示繁忙的动画处理和停止的按钮。

  4. 您可以通过对 输出选项卡 的项目 双击 来查看来自于单个 编译任务 的输出,或者 双击 并从关联菜单中选择 显示输出 。

    BatchBuild Output Pane

    单个项目的 批量编译程序 输出被显示在名称为 UnrealVS - BatchBuild 的面板的Visual Studio 输出 窗口中。 不要将其与显示当前/最近编译任务的输出的 编译 面板弄混了。

快速编译菜单

快速编译 菜单提供了使用任意配置和平台组合而无需变更主要解决方案的编译配置来编译项目的简单方法。

Quick Build Menu

  1. 在 解决方案浏览器 中 右键点击 项目节点。

  2. UnrealVS快速编译 菜单包含来自虚幻引擎解决方案中的可用平台的子菜单和编译配置。

  3. 选择项目来编译选择的项目,平台和设置。比起在IDE中变更解决方案配置和解决方案平台,这要快得多,开始编译然后再次切换回配置和平台。

比起在IDE中变更解决方案配置和平台要快得多!

使用UnrealVS源代码来运行

UnrealVS源代码位于[UE4RootLocation]/Engine/Source/Programs/UnrealVS/ folder。

为能载入具有Visual Studio的UnrealVS项目文件,您需要安装兼容于UnrealVS的合适版本的Visual Studio的Visual Studio SDK。举例来说,当需要对版本直到Visual Studio 2013的支持时,您需要安装Visual Studio 2013 SDK,然后载入UnrealVS项目文件到Visual Studio 2013中。

2020-05-17 12:47:53 sinat_25923849 阅读数 214
  • 搭建UE4开发环境

    通过本课程的学习,你讲可以掌握Unreal引擎开发的基础知识,包括Unreal编辑器的基本使用,Gameplay Framework,以及C++&Blueprint;两种开发模式。

    60124人学习 房燕良
    免费试看

Unreal Engine 4.25 + VS 2019 小记

接触UE4也有一段时间了,前几日Epic官方公布了UE5的预览demo,其中提到两项即将发布的新技术LumenNanite,为了在UE5发布之前对引擎使用尽可能的熟悉,从今天开始自己也计划一下,系统地学习引擎使用的知识。

UE 4.25 + VS2019

官方说到可以先在4.25中进行开发,4.25版本会开始注意将来与5的过渡 ,我也赶紧打开我的Epic game lanucher下载新发布的引擎,大家热情应该很高涨,我连续登陆了两天,终于在今天成功登陆上去,并下载安装好了4.25先新建一个c++工程看看有什么需要配置的。

  1. 打开引擎,新建工程,不得不说,引擎的启动还是一如既往的慢。
    在这里插入图片描述
  2. 目前电脑上有VS2015,VS2017之前也在VS2015中基于UE 4.23UE 4.24学习过一些小demo,现在新建工程。
    在这里插入图片描述
  3. 随便选择一个第一人称游戏模板,选择C++工程并Create
    在这里插入图片描述
  4. 这里报错,提示我没有VS2019,该项目需要VS2019才能编译,挺好,与时俱进,赶紧再去下载安装VS2019,装完后回来再次创建项目成功,这里生成代码需要一点时间,我笔记本配置还行,仍然感觉好慢。
  5. 通过Editor打开VS工程,选一个Debug模式看看编译有没有问题。
    在这里插入图片描述
  6. 报错,无法启动,原因是未把项目设为启动项
    在这里插入图片描述
  7. 设为启动项后再次运行成功打开debug的editor。
    在这里插入图片描述
    在这里插入图片描述
  8. 测试加断点调试,断点进入成功。
    在这里插入图片描述
  9. 就先到这里,基本流程走通了,下面就是具体的学习了,加油吧。
2016-11-30 08:46:12 qq_27481603 阅读数 4649
  • 搭建UE4开发环境

    通过本课程的学习,你讲可以掌握Unreal引擎开发的基础知识,包括Unreal编辑器的基本使用,Gameplay Framework,以及C++&Blueprint;两种开发模式。

    60124人学习 房燕良
    免费试看

unreal官网 右上角获取虚幻引擎


安装全程不需要翻墙, 安装完这个样子:


点击unreal engine页  下载引擎的最新版本,全程也不需要翻墙. 安装完就可以启动啦!



unreal开发  分蓝图和c++代码两种形式.蓝图就是可以不用写代码直接用工具的形式构建项目,不过显然代码功能更强 编辑器右上角有个帽子是教程.


新建c++项目时需要安装visual studio 2015  否则可能会报各种错误, 我一开始装完Unity3D自带了vs2015但是可能因为走了默认安装配置所以报错: 缺少windows8.1 sdk 或者缺少32位的vs文件  安装的默认配置中是不勾选c++环境的   要自定义安装  把c++开发环境勾上


安装ue4时有个勾选选项: 用于编辑器的符号显示  很大,有13个g  是编写c++代码时的提示,在崩溃时也会有用,有什么用群里大神没说..

2017-08-23 17:43:36 l346242498 阅读数 3930
  • 搭建UE4开发环境

    通过本课程的学习,你讲可以掌握Unreal引擎开发的基础知识,包括Unreal编辑器的基本使用,Gameplay Framework,以及C++&Blueprint;两种开发模式。

    60124人学习 房燕良
    免费试看

          对于程序员来讲,在使用UE4时候避免不了调试C++代码,那么就必然有调试代码的时候,假如你为了一个问题,反复的编译C++,反复重新打开UE4 Editor,或者你用Editor里面的Compile来编译,但是错误提示一些的都在UE4 Editor里面,没有我们平时在VS编译和调试工程时候直接查看编译信息的方便。但是我们如果只用VS默认编译的话,又做不到热更新,因为UE4必须要经过它自带的工具UBT的编译才能直接更新到项目中。但是UE4给我们提供了一个VS的插件,让我们方便的在VS里面调用UBT编译来替代VS默认编译。而且UnrealVS插件不仅有直接热更的好处,还能提高UE4项目的编译速度,一般来讲要提高2-3倍左右。

         其实不管你用的源码还是直接下载的编译好的应用,在Engine\Extras\UnrealVS\目录下边都有VS三个版本的目录,

打开对应的VS版本目录,有一个UnrealVS.vsix的文件,双击运行,安装。

         然后打开你的VS,在视图-->工具栏 中勾选上UnrealVS。

         然后为了方便使用,我们再调一下UnrealVS插件上边的按钮,点击插件最右边的设置按钮,在添加或者移除按钮中选择自定义

        然后选择命令标签,工具栏选中UnrealVS,点击下边的添加命令,在弹出窗口中选择Build Startup Project命令,点击确定,然后你就会发现前边多了一个Build Startup Project的按钮。

         之后再编译工程时候,就可以在UnrealVS插件中选择好工程后,点击Build Startup Project按钮来编译了,编好的工程直接会热更新到你打开的工程中,如果出现问题时候,也可以方便查询编译信息,基本可以取代VS自带的编译。

     

2018-01-16 14:47:08 fanbird2008 阅读数 1581
  • 搭建UE4开发环境

    通过本课程的学习,你讲可以掌握Unreal引擎开发的基础知识,包括Unreal编辑器的基本使用,Gameplay Framework,以及C++&Blueprint;两种开发模式。

    60124人学习 房燕良
    免费试看


这是一个很难的问题,而且不容易回答,很容易引起争论,老实说我并不想在公开场合评论到底哪个更好或者更坏,这并不明智,其实每个人心底都有自己的答案。

我只想聊一些我的看法。

一、关于Unreal4和Unity

很不幸,我并没有看过Unity代码,我们没有购买,而我也并不是特别想看。或许有人说:装!嗯,其实写了很多年代码了,什么没见过?看过并不一定能写出那样的产品,没看过也不代表你不能写出超越它的代码。很多人对待引擎代码的态度其实和追女孩差不多,没追到的时候,天天时时刻刻想着,到手了,就呆在硬盘里,其实真正每个文件都读过的人,凤毛麟角,读懂的人可能更少。

在刚开始学习游戏引擎的时候,需要读一定数量的代码,但积累了一定的代码量和经验之后,需要的更多是观察、思考、总结。所以比较资深的程序员,会花更大量的时间思考,而不是学(chao)习(xi)别人的代码。

回到这两者的对比上,我没看过,所以就不知道怎么对比了,只能说各有各的好,咸鱼青菜各有所爱,而且游戏界的金科玉律就是,谁能出产品,谁能大卖,谁就是赢家。

至今Unreal3已经被证明了是一个伟大的引擎,有足够的title说明问题了。Unity有不少作品,但还缺乏一锤定音的作品,和AAA不沾边有关系吧。但用户足够多,增长率高也可以说明问题。Unreal4还欠缺证明自己的作品,等战争机器吧,Epic还需要向别人演示怎么使用这个引擎。

二、关于题主提出的几个对比

很直接说一句,那都不是什么问题,或者可以说,根本不是比较的重点。Unity那种写法,上世纪就已经有人在用,不见得是什么高明的写法,这种c/c++的奇技淫巧,只有初学者或者刚刚学会一点儿的人会感兴趣。我顺手可以拈来好多类似的,比如gcc的tree node结构,初读感觉那个精妙,后来发现也就那样儿。这种union我大概10年前在写高速raytrace引擎的时候已经用过,而且用在xmm上面,即现在DirectXMath的写法。至于你说不明白为什么Unreal这么写,看不懂if。为什么?很简单啊,因为这是“历史问题”。那个年代过来的代码都是这么写的,就一直这么写了。

很多人搞错了一点,以为数学库要效率高,这也是我刚开始写引擎和图形程序时候的错觉。后来发现,不是的,游戏引擎的数学库,不是全都要求效率高的,数学库最重要的是“稳定”。因为真正在跑的,AAA游戏,或者重度的MMORPG,最重要的,不是数学运算,而是“架构”。反而数学运算,需要稳。稳到什么程度?havok曾经推销他们的物理引擎,最引以为傲的的,并不是它有多快,而是它的所有物理运算在所有平台上的计算结果都完全一致(评论有朋友修正了这个说法,应该是同样的计算在同一平台上每次计算都一样)。这简直吊炸天啊有木有!!!如果你不明白这句话背后的意义,那么我想你没必要讨论数学库了。

回到问题本身,一个字,编译器优化,可以回答一切问题。

现代游戏引擎的瓶颈,有两处,一处是runtime的执行效率,一处是content creation的pipeline生产效率。后者太庞大太宽泛,没实战过的人,不理解,这里不展开细说,只讨论第一点,runtime。

runtime部分,现代引擎面对的问题,主要是越来越复杂的场景,越来越多的drawcall,越来越重的资源。这里面最麻烦的就是提交。所以新一代的API,都注重提高提交效率,即更薄的driver层。这就是DX12标榜的十万drawcall的意义。

这里我必须提一点,这两个引擎,Unreal4和Unity,都有一个架构上的严重欠缺,就是没有从原生上支持多线程。即使Unity5,也只是用了一种thread pool的分发的策略,把一部分集中的繁重的事务分发到其它线程计算,但它并不是真正的“原生多线程”,即任意的不相关的任务都可以随意分发到不同的线程上。考虑每个entity自己更新自己的逻辑,可以并行,有100核心就可以几乎真的并行更新100个entity,这才是真正的原生多线程。

这种引擎,目前公开的只有Frostbite 3是这么做的。(当然我不会告诉你,我们……)。

至于Component架构,这方面我有另一种看法。游戏引擎是一个很重度的工程项目,而非科研项目,干净与否并不能成为评判标准,实用性才是金科玉律。我认为unreal这么做(把业务相关的东西放到底层),是基于一种发展的眼光看。很简单,我也会这么做,如果我开发了一套非常超前的架构,但我又对它没有足够的底,不知道接下来应该怎么写,我认为总体方向是对的,但我不清楚业务和他如何结合,那么我就采取折中的方式来处理,即把一部分业务嵌到架构中,先把业务应用起来,验证架构的正确性,然后通过重构和迭代,逐步把业务细节划分出去。

显然UObject是继承Unreal3而来的,Unreal4非常大胆,blueprint是一种非常超前的想法,而且非常有前途,也非常好,但这个改变太庞大了,太重了,要一下子割裂和Unreal3的关系是不切实际的,稳妥的方式是逐步修改过来,并且验证之后再完全迁移过去。所以迁入一部分实际业务的想法很现实。而且要考虑,引擎开发本身应该依附具体项目。我认为Unreal4应该依附在战争机器游戏本身的开发身上,才可以保证它不会走弯路。所以在底层重度嵌入一部分FPS相关代码,无可厚非也没有任何问题。

老实说,我有代码洁癖,但我也会这么做,因为引擎不是独立产品,是依附游戏的附带产物,一切应该以游戏业务为优先。这也是为什么我一直对Unity有一些负面看法的原因,它的开发商本身并没有任何游戏,一切反馈是来自于用户,二手数据。所以Unity看起来似乎很“干净”,但就是太干净,干净得出奇,变得不接地气,这才是为什么它缺乏AAA。

三、渲染质量之谈

题主似乎不断在强调不要被Unreal4的渲染质量吓唬住了,我觉得这句话是很有问题的,直接地说,这句话是不专业的,一点都不professional的。显然题主是有倾向性的,因为Unity本身就是一直被Unreal4的渲染所吓唬住了,所以每个版本的升级都在重点强调自己的渲染特性得到了提升。

老实说,这并不明智。因为Unity的提交效率。。。

上面提到了一点,现代引擎的瓶颈一个很重要的点就在于渲染批次的提交上面。这里请看我一直所赞誉的Frostbite 3,的数据——BF4一些场景的DP数量达到了5000~10000。吊炸天啊!这需要非常高的提交效率,非常优异的渲染组织。这就是引擎真正的架构技术核心所在。另一个碉堡了的是CryEngine,提交效率很高。

所谓“渲染质量”是什么鬼东西?搞了差不多二十年图形,我很少听到专业人士提到这个词。我听过渲染效率,听过画面质量,听过各种shading model。同一张显卡,同样的shading model如果还用同样的模型,同样的算法,有什么质量不质量的?难道Unreal4算的 1 + 1 = 2 比 Unity 算的 1 + 1 = 2 质量要高?那个 2 要更好看?

不是的,这是业余的看法。专业的看法是,你要对画面有取舍,有调控。引擎是一个大的系统,系统设计最重要的一环是控制和分配。图形学没什么算法是不公开的,Unreal4用到的所有算法都是公开的,所有的siggraph paper你都能access到,没什么秘方,没什么magic code。关键是,你的取舍,你花多少资源在哪个部分,省了哪个地方的东西。

这部分的功力,是源自于游戏开发本身,源自于积累,源自于TA。这也是Unity欠缺的地方,因为Epic自己开发游戏。所以Epic在资源的调配上,有取舍,有经验,在开发战争机器的时候,在开发游戏的时候,有各种纠结,填了不少坑。写好代码只是开始,教会TA和美术使用引擎、正确使用你写的技术、配合并创造出美丽的画面,才是真正有绝对价值和意义的工作,这占了99%。

图形学是工程的图形学,是trick和cheat的集合。正如你堆钱买奢侈品是不能除掉身上浓浓的杀马特山寨风的,必须读书、读书、读书、思考、思考、思考、沉淀、沉淀、沉淀。光靠堆一些feature,不是正确的姿势。这就是为什么Unity 5堆了那么多feature,看起来还是远不如Elemental Demo。

四、双生

对比Unreal、Unity,同样的例子,请看CGFX领域的MetalImage和Pixar。MentalRay非常屌,有很多先进设计,一直坚持用raytrace,早就开发出电影质量的全局光渲染,但它一直被死对头Pixar的RenderMan所压制。Pixar的RenderMan,采用“落后的”渲染算法REYES,直到13.0版本之前一直不支持raytrace,且价格昂贵,更新缓慢,但广受电影制作喜爱,上世纪好莱坞特效渲染标配渲染器。为什么?很简单,Pixar自己是做电影的,RenderMan本身一直为Pixar的电影服务,获得各种第一手电影制作需求。而反观MentalImage一直只是一家软件公司,没有电影业务,只卖软件,只卖技术,所以无论改进得多好,一直不懂电影制作者的心。

我对Unreal和Unity的看法,也基本基于此案例。当然,现在disney有更强的渲染器,可以完全干死RenderMan,不过这货是不卖的,正如Frostbite,也是不卖的。世界上最好的引擎技术,不会出现在商业引擎里面,只会在In house engine中。

五、寄望

我聊了许多,然而这并没有什么卵用,工作中该用哪款的,还是要用哪款,这不是技术人员能够决定的。不过我一直以来的信念,都是我们始终是要做自己的引擎的,并不是为国争光什么的狗屁高大上理由。很简单,技术人员存在的意义,就在于用技术碾压对手。你的技术,到底是用在给别人打补丁上,还是给自己充实力量上?

所以我对所有这些第三方引擎的态度,都是批判地学习。好的,我兹词,不好的,我谨记并绕开。其它不参合任何个人感情,也不需要卖任何情怀,只需要记住,所有的这些——Unreal、Unity、CryEngine、Frostbite、SnowDrop、Fox等等等等,都是他人的嫁衣裳,我们真正需要的,是自己的遮羞布。

题主的批判态度,已经带有点私人感情了,这并不理智,希望你可以成长,客观看待这些东西。

————————————————————

补充一点,题主说Unreal4不如ogre,我觉得这真有点太过了。ogre实在是渣渣渣渣渣。不多说,自己领悟吧。

————————————————————

再最后补充一点,评判这些引擎的时候,如果你不是对自己的实力有足够的把握,如果你不是很清楚到底自己是否真的彻底了解这些设计背后的原本意义,那么千万千万千万别开上帝视角

要很清楚这些引擎是世界最顶尖的脑袋架构出来的,一些显而易见的问题,比如用if是否很2b,难道你以为可以架构出blueprint、能够做到c++hot load这种吊炸天的人,他们想不到?

不可能的事情!去看看Unreal4的Multicast delegate怎么设计,怎么构建,C++用的多好,多纯熟,对语言的压榨多极致,能够有这种把握深度的人,会不知道用书本上写的条条框框“千万别用if啊”什么的?不可能的事情!

Tim Sweeney这些人的脑袋太好用了,太厉害了。比如Component的结构,坑超级多,你想到的,别人不会没想到。我遇到这种情况,不会第一时间想别人是否2b了,而会先考虑、是否自己没想到更深刻的问题?或许还有其他坑?就连Voxel Cone Tracing这种屌炸天的算法都能想到,不可能想不到你看出来的小问题。

所以,每当要开启上帝视角,请换一下角度,如果是你,你怎么设计,你怎么处理,真的就没有问题?如果你真的设计的比他们好,请别犹豫,站出来,战胜他们。

升级UE4项目VS版本

阅读数 1374