2013-06-19 11:31:01 ljh081231 阅读数 8002
  • 从这里开始虚幻4-Editor介绍 v4.18

    本课程系列取名英译系列,是录制人员参考国外英文原版经典教程,结合中国人的习惯录制而成。希望能够给大家以帮助。从这里开始虚幻4系列教程,是Unreal的官方发布的入门教学,非常经典,是学习Unreal的佳入口。

    2392 人正在学习 去看看 杨石兴

Unreal 和 Unity 3D 各有什么特点?如何选择?

用官方的话说就是这啦,仅供参考
Unity3D:
Unity Technologies开发的一个让玩家轻松创建诸如三维视频游戏、建筑可视化、实时三维动画等类型互动内容的多平台的综合型游戏开发工具,是一个全面整合的专业游戏引擎。Unity类似于Director,Blender game engine, Virtools 或 Torque Game Builder等利用交互的图型化开发环境为首要方式的软件其编辑器运行在Windows 和Mac OS X下,可发布游戏至Windows、Mac、Wii、iPhoneAndroid平台。也可以利用Unity web player插件发布网页游戏,支持Mac 和Windows的网页浏览。它的网页播放器也被Mac widgets所支持

Unreal:
UNREAL ENGINE 的简写)中文:虚幻引擎  (UNREAL ENGINE)是目前世界最知名授权最广的顶尖游戏引擎,占有全球商用游戏引擎80%的市场份额。中国首家虚幻技术研究中心在上海成立,该中心由GA国际游戏教育与虚幻引擎开发商EPIC的中国子公司EPIC GAMES CHINA联合设立。
基于它开发的大作无数,除《虚幻竞技场3》外,还包括《战争机器》、《彩虹六号维加斯》、《镜之边缘》、《荣誉勋章:空降兵》、《质量效应》、《生化奇兵》等等。在美国和欧洲,虚幻引擎主要用于主机游戏的开发,在亚洲,中韩众多知名游戏开发商购买该引擎主要用于次世代网游的开发,如《剑灵》、《TERA》、《战地之王》、《流星蝴蝶剑Online》、《一舞成名》等。 iPhone上的游戏有《无尽之剑》(1、2)、《蝙蝠侠》等。
unity3d挺好的,做游戏也是比较给力的
unity3d免费教程网站:Unity3D教程手册
按票数排序

3 个回答

刘春阳酱油策划、独立游戏爱好者

1 票,来自千鬼神
总说,u3d相对比较轻便一些,适合开发一些轻量级游戏,UE则是重量级。u3d易上手,有编程基础的就能做点名堂出来,但是UE比较复杂,从底层到界面等等,给人感觉比较难摸。u3d现在可以开发基本上所有平台的游戏,PC、ios、安卓、xbox、ps还有它最为擅长的web,UE其实也差不多,PC、主机平台是它的强项(战争机器等)、ios(无尽之剑)、加上前段时间和adobe搞基,所以现在国内也有越来越多的公司开始用UE开发游戏。
u3d用过一段时间,整体感觉比较友好吧。后来研究了几天的UE3,发现我这点代码基础,比较困难,于是放弃了。

知乎用户,一个PC游戏玩家! Facebook @JianlongLiu,…

作为一个单机玩家我能给出的建议是
Unity 3D适合做网络游戏,Unreal 3 都适合,Unreal 3 做大型的独立游戏是非常棒的,无论在硬件配置需求还是画面上做得都很好!我发现虚幻3引擎的网络游戏做得比较卡,单机不会!

国产Unreal 3游戏做得都很烂,最起码画面很烂,如果美工很差的话还是用Unity 3D吧!

如果你真有心思去做游戏,建议用CryEngine 3,还有光荣使命的做得还算不错!

rui zhangGame Engineer

接触过这两款引擎,和同事们讨论的得出的结论是:unreal 虽然最终的画面效果要好于unity3D。但是其开发效率上,Unity占有很大的优势。我自己的体会是,unreal必须要拿到授权才能进行真正的开发,其开发或多或少都要涉及到引擎的定制,也就是c++级别的修改。而unity由于使用mono运行时,所以给独立开发者提供了更多的接口,当然其价格策略也灵活很多。
2018-01-16 14:47:08 fanbird2008 阅读数 1514
  • 从这里开始虚幻4-Editor介绍 v4.18

    本课程系列取名英译系列,是录制人员参考国外英文原版经典教程,结合中国人的习惯录制而成。希望能够给大家以帮助。从这里开始虚幻4系列教程,是Unreal的官方发布的入门教学,非常经典,是学习Unreal的佳入口。

    2392 人正在学习 去看看 杨石兴


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

我只想聊一些我的看法。

一、关于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这种屌炸天的算法都能想到,不可能想不到你看出来的小问题。

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

2017-09-22 10:40:27 QQ18334373taikongyi 阅读数 326
  • 从这里开始虚幻4-Editor介绍 v4.18

    本课程系列取名英译系列,是录制人员参考国外英文原版经典教程,结合中国人的习惯录制而成。希望能够给大家以帮助。从这里开始虚幻4系列教程,是Unreal的官方发布的入门教学,非常经典,是学习Unreal的佳入口。

    2392 人正在学习 去看看 杨石兴

Ogre 

Unreal 

Unity 

Gamebryo 

Bigworld

2017-02-25 22:26:12 BoWeiPub 阅读数 306
  • 从这里开始虚幻4-Editor介绍 v4.18

    本课程系列取名英译系列,是录制人员参考国外英文原版经典教程,结合中国人的习惯录制而成。希望能够给大家以帮助。从这里开始虚幻4系列教程,是Unreal的官方发布的入门教学,非常经典,是学习Unreal的佳入口。

    2392 人正在学习 去看看 杨石兴

这里写图片描述
非常感谢我们的天才设计师“李一奇”同学为我的这篇文章设计的图标!

前几天发了一条朋友圈,跟大家分享了一下近来一段时间一直在做的一项比较“大胆”的技术尝试。之所以用“大胆”来形容,是因为我们目前是一个创业团队,技术上的任何决策风险都可能导致整个公司陷入灾难。。。
朋友圈发布之后很多朋友来找我聊具体的实现细节。于是我决定写这篇文章来跟大家仔细分享一下我的整个实现过程。

先介绍一下背景:
去年(16年)8月的某一天子雄来找我研究我们下一款产品的技术实现方案。在这之前我已经开始使用Unreal进行新产品Demo的开发。之所以选用Unreal是因为我们之前给老罗演示的产品Demo一直使用的是Unreal。但是子雄提出想更换Unity引擎做后续开发。由于具体理由会涉及我们的产品定位的一些细节,这个目前还在保密,不允许我说。。。 你们猜猜就好。。。
在一番理由阐述及数据展示之后我被他说服了。本来使用Unity开发或者Unreal开发对我个人来说是无所谓的,但是他最后说了一句“我们未来的某一天可能会切回Unreal开发。。。”
此时我的内心是崩溃的。。。

为了保证我们某一天突然改变主意又不能影响研发进度,于是我做了第一步尝试:
我把我之前开发的Unreal插件做了代码重构,然后在插件代码的上层做了一个对外暴露的C接口层。这样一来插件的功能就可以使用两种方式来调用:
1.Unreal自身的执行环境。
2.通过非Unreal的执行环境,直接利用C接口调用。

以BlankPlugin为基础我写了一个小Demo。我绘制了一张类图,方便大家大概了解一下代码的结构:
这里写图片描述
如上图所示,每一个插件专门写一套导出接口(***PluginForUnity),然后所有的插件连接到GameModule。GameModule再统一对外暴露一套接口。修改UnrealBuildTool(以下简称UBT),使GameModule在任何情况下都生成动态库(IOS除外),并且所有的插件都静态链接进入GameModule输出的动态库。
最终输出的动态库导出的C接口在Unity的C#代码中可以直接调用:
这里写图片描述
在开发过程中针对Unreal和Unity两种环境下使用的两套接口,在一些代码逻辑实现上会有一些差异。我们可以在一些实现有差异的地方加上宏将代码隔开:
这里写图片描述
然后我们在Unreal的Build文件中加上宏开关:
这里写图片描述
这样一来只需要修改Build文件中的一个bool变量的值,然后重新编译代码即可发布相应引擎的功能模块。通过这种实现方式,在Demo实现阶段我就可以随时切换产品依赖的引擎了。

我们的产品需要一些三方库的支持,所以我需要为Unity插件添加一些三方库,在UBT的环境中添加三方库变得极为简单。UBT实在是太方便了,以至于我现在不管做什么编译都想移植到这个编译环境中来。
14年的时候我服务于国内原端游时代某巨头公司。我跟我的同事们曾经做过一个事情,我们把CryEngine3移植到移动端(Android,IOS),让CryEngine3变成了全平台次世代游戏引擎。其中在编译及跨平台这方面参考了很多UBT的做法。但是很遗憾由于种种原因这个项目在初期版本完成之后被弃用了。

在这里给Unity开发者介绍一下我们在UBT下添加第三方库的具体做法。
在UBT的环境中Unreal的ThirdParty和新的子模块的添加变得极为方便,我们可以通过定义一个Build文件就添加了新模块的各个平台的版本到我们的工程中。为Unity开发C++插件需要引入Unity提供的接口定义文件。我们可以在“Unity\Editor\Data\PluginAPI”目录下找到这些文件:
这里写图片描述
因为有的时候我们的多个模块都需要引入这些头文件,于是我将这些文件以ThirdParty的形式添加进入我们的工程:
1.在ThirdParty文件夹下建立子目录UnityPluginAPI。
2.将PluginAPI文件夹拷贝至UnityPluginAPI目录,然后创建UnityPluginAPI.build.cs文件。
3.在UnityPluginAPI.build.cs文件中我们添加如下代码:
这里写图片描述
现在我们就可以在我们的插件工程中引入新加入的UnityPluginAPI了:
这里写图片描述

9月份的时候我们开始加入新的研发人员和我一起开发新产品。于是我开始考虑作为上线产品对于技术实现的一些要求。目前面临的最大问题是对于Unreal的大量模块的过度依赖导致插件编译出来之后体积较大,急需代码瘦身。代码瘦身的第一步是删除大量对于作为外部插件无用的Unreal模块,同时需要修改UBT,定制自己的编译需求。这部分也是整个过程中最重要,也是工作量最大的地方。
我首先删除了大量的Unreal Runtime下代码模块。目前能用到的代码模块也只有这些:
这里写图片描述
以上这些模块中,Core做了大量的修改,其他模块有的做了一点点修改,有的甚至一点没动。在这个过程中还要修改UBT解决编译依赖的一些错误。最终修改编译工具,使我们的改造引擎在Android及Windows平台的Debug、Development及Shipping环境下编译出动态库,而IOS平台始终编译出静态库。这部分比较繁琐,而且也相对产品研发比较特异,所以就不详细介绍了。

最后强调一句,以上所有看似使用Unreal辅助Unity开发,但是其实我们一直没有脱离Unreal的开发环境,并且我保持了Unreal插件开发要掌握的所有细节,只要换个Unreal引擎编译你写的所有代码,一下子就变成了为Unreal开发的代码。也就是说我们可以在给使用Unity的产品开发功能的同时顺便也为使用Unreal的产品开发了功能。

通过这种实现方案目前在我们的产品研发中我们收获了大量的好处:
1.如果公司有多款产品同时使用Unreal和Unity开发,那我们在一些比较独立的功能模块研发上可以做到一份代码多个产品同时使用,再也不用为不同引擎开发相应的版本。
2.Unreal提供了大量的C++库,极为方便和稳定,这为我们开发Unity 的Native插件带来了极大的帮助。
3.写C++代码的时候注意跨平台,这方面Unreal也做了很多适应跨平台的封装。借助UBT的可以多平台编译的特性直接编译目标平台的代码。
4.在我们产品中有一些比较重要的核心算法,我全部使用C++编写。这样就不用费劲去做C#的加密和混淆了,彻底地防止了反编译的发生。
5.产品中的一些底层对效率要求极高的模块也用C++编写,保证了执行的效率。
6.我们借助于UBT可以快速生成多平台的工程文件。这比针对各个平台手动创建工程要方便的多。而且代码文件的层次结构和本地存储目录保持一直,浏览及添加或删除新的代码文件变得极为方便。降低了手动维护出错的概率。UBT的编译配置也非常直观,可灵活配置并定义自己的编译环境。
7.开发一个Unity产品有的时候我们需要接入一些三方库,这些库大部分是C/C++编写的。我们使用了跟Unreal一样的三方库接入方式。然后把一些三方库的接口根据我们的项目要求做封装,再把少量的接口暴露给C#。这样就简化了C++与C#的通信接口:
这里写图片描述

Unity的C#开发非常快速,门槛不高,代码维护及招人都非常容易。Unreal的C++开发能够保证执行效率,容易接入三方库,跨平台方面也不是问题,同时还能够保障代码安全性。我们使用Unity的C#开发应用上层逻辑,使用Unreal C++开发底层算法及其他基础功能模块。通过这种方式我们很好地发挥了两款引擎的各自优势。
目前这套解决方案还不涉及大量Unreal渲染的东西,不处理那些Unreal特异的东西(例如UObject相关)。
这套解决方案最大的难点在于我要大量改造Unreal代码,甚至编写自己的编译环境。这些东西又跟具体的项目关系特别紧密,没有办法给大家具体地展示。后续我会总结一些研发过程中可以提炼的细节(不涉密的)继续分享给大家。

如果您对我的博客感兴趣可以扫下方的二维码关注我的微信订阅号。在那里我会不定期发布更多的技术文章。
这里写图片描述

2017-04-10 11:47:52 mayaworks 阅读数 996
  • 从这里开始虚幻4-Editor介绍 v4.18

    本课程系列取名英译系列,是录制人员参考国外英文原版经典教程,结合中国人的习惯录制而成。希望能够给大家以帮助。从这里开始虚幻4系列教程,是Unreal的官方发布的入门教学,非常经典,是学习Unreal的佳入口。

    2392 人正在学习 去看看 杨石兴

1、Unreal 4: 下载UE4RenderDocPlugin,复制到$Project/Plugins目录。运行Unreal 4 Editor时提示选择renderdocui.exe所在目录。进入Unreal 4 Editor后会在主窗口中显示RenderDoc图标。

2、Unity: RenderDoc安装完成后(非复制方式),进入Unity在Scene窗口的工具条点击右键Load RnderDoc:
UnityRenderDoc

渲染模式(Forward、Deferred)的选择:在Main Camera的Inspector窗口的Render Path中设置。

C++实现反射

阅读数 7

没有更多推荐了,返回首页