Unity和UE4開發(fā)VR的優(yōu)劣

1、輕量級，安裝、調(diào)試和打包方便配置VR項目十分簡單學習成本低，文檔完善開發(fā)成本低UI 系統(tǒng)在PS4上調(diào)試方便，有批處理文件可以一鍵運行Asset Store提供了一些VR下的Demd乍為參考Unity 的劣勢：內(nèi)建工具不夠完善渲染差，光照系統(tǒng)糟糕，陰影 bake有bug,只能勉強達到2A游戲入門水平 對于控制器支持較差，一些如手柄震動、VR控制器空間定位的功能引擎未集成, 需要第三方插件或額外代碼沒有材質(zhì)編輯器，需要第三方插件Prefab 不支持繼承沒有內(nèi)建的 Level Stream 支持Unreal 的優(yōu)勢：畫面效果完全達到 3A 游戲水準光照和物理渲染即便在縮水的狀況下也足以秒殺 Unit

2、y藍圖系統(tǒng)，從此策劃不用再寫代碼強大的材質(zhì)編輯器各種官方插件齊全對于手柄、VR控制器支持良好提供各種游戲模版，用來做原型配合Blueprint 甚至比 Unity 更快Unreal 的劣勢：C+如果要開發(fā)PS4游戲需要重新編譯引擎，12核服務(wù)器，24線程編譯大概需要20-30 分鐘如果需要重新編譯引擎，光拉代碼就需要至少一個小時創(chuàng)建新項目大概又要編譯十多分鐘如果切換平臺，要編譯幾千到上萬個 shaderPS4部署不方便，打包編譯同樣非常久學習成本高，各子模塊功能強大但操作復(fù)雜部分功能沒有任何文檔，已有功能的文檔同樣不夠完善，不如 Unity開發(fā)成本高，某國內(nèi)3A團隊做了個10分鐘的VRDemo

3、據(jù)說已經(jīng)燒了一千多萬UI 設(shè)計器非常之難用9 / 8VR下的一些best practice同樣缺乏文檔和例子，目前都在摸石頭過河Buuuuuuuuuuuuuuuuuuuuug我覺得寫了這么多結(jié)論已經(jīng)很明顯了：小團隊沒錢追求快速出效果，對畫面要求不高的項目用Unity o中大團隊不差錢，買得起Unreal技術(shù)支持，分工明確有專人填坑，對畫面要求 高的項目用Unreal。這里還有一篇老外寫的關(guān)于Unity和Unreal的文章，建議閱讀：ExtroForgeThe Switch from Unity 3D to Unreal EngineA High Level DecisionLet me sta

4、rt off by saying that I (and other team members) are still HUGE fans of Unity. Several of us on the team have been using Unity since v3.X days (including Pro licenses) and CONTINUE to use it for various projects. If I was starting a mobile project today, I would still reach for Unity.We made a LOT o

5、f progress on prototyping ExtroForge with the Unity engine. Huge swaths of gameplay elements were engineered and integrated. We thrived with the rich variety of Asset Store packages available to us as well as the YEARS of online posts, blogs and tutorials. With at least two 15-year software engineer

6、ing professionals on the team, we were efficient and proficient under Unity.All that being said, we got to a point where a single aspect of the Unity Engine became a critical blocker multiplayer networking. Several people on the team had experience with building multiplayer projects with Unity one u

7、sing the third party SmartfoxServer and the other with thebuilt-in RakNet functionality. Extroforge, however, brought some specific needs to the table.一 including Authoritative server logic, server-side physics and collision logic and high-performance (Extroforge is part FPS and part RTS in many way

8、s). We prototyped multiplayer using the built-in networking and in the meantime, looked at some third party options. We were eagerly awaiting the Unity 5+ replacements for the networking - UNet.image08The first iteration was less than impressive. Extremely limited (missing?) documentation and oddbal

9、l (buggy? flaky?) performance. Simple replication of an animated model (location/rotation) was either non-functional or super-laggy. We experimented. We read forum posts. We waited.There were no official Unity tutorials. Some of the people that WERE making tutorial videos thatwe followed actually ga

10、ve up and decided to wait until future releases. Then the Unity roadmap was published. With the implementation of the standalone simulation server pushed out to March of 2016 (plus some other elements undefined), we decided to look at other options. What a pleasant shock it was to fire up Unreal for

11、 the first time with a starter project and see that little side menu next to the“ Play ” button that allowed you t-ostaaurtonot just a dedicated server,but also as many additional player clients as you wanted to. It was multiplayer nirvana.Note that this was not SOLELY a decision based on multiplaye

12、r functionality built into the engine.We have struggled for some time to get the world/terrain/foliage/water to look the way we wanted. Our Team/Studio lead who was responsible for the look and feel decided to look at some other game engines to see how quickly he could achieve the desired results (o

13、ur Unity results either looked too cartoonish or too“ claylike ” ).image09CryEngine was so beautiful“ right out of the box ” that he almost cried. But convincing the teaminto such a low-documentation, small community, high learning curve environment was a non-starter. With Unreal, the desired look a

14、nd feel was quickly created and we were all MUCH more comfortable with the user community, documentation level and toolsets (including Blueprints).Once we were convinced (via a few sample projects and prototyping sessions) that we could get the look-n-feel that we wanted and with the multiplayer sta

15、bility and scalability that Epic bringsto the table (after YEARS in the multiplayer FPS space), we made the official decision to jump. It was a HARD decision. We had a lot of code and content that was Unity specific (including our procedural mesh based voxel implementation). We were so familiar with

16、 the Unity way of doing things -including the C# language. Blueprints and C+ gave us more than a moment' s pausewe had committed.C# versus C+ versus Blueprintsoh my.The ExtroForge team had some technical depth. Both senior engineers had worked in C and C+ years ago - although had moved on to man

17、aged languages since - heavy in Java and C#. The rest of the team had mixed experiences in different high level languages. We were well experienced in both OOP and Component based design. C# was an easy language to work with in Unity and theadditions that GameObject and its related brethren brought

18、to the table had become second nature to us. I aldl mit that the Blueprints concept in Unreal frightened me a bit. Interestingly enough, none of us had done any visual scripting before, so we had nothing to compare to. I had some bad experiences with wired prefabs in Unity - where we could easily lo

19、se a bunch of important settings. I got very used to establishing important values and settings in code. That fear, along with many many years of software development experience behind us, made me confident that we could/would blow the dust off our C+ skills and start that way. I was encouraged by t

20、he fact that most of the starter sample projects that were available to download/install through theengine/editor had a Blueprint AND a C+ version. That encouragement was short lived, however.Not to sound demeaning - but because of the l arge number of ' hobbyists ' that flocked to Unreal be

21、cause of it s price, there were a HUGE number of tutorials, forum posts, videos, etc related to accomplishing Unreal tasks in Blueprint land. There were SIGNIFICANTLY less in C+ land. At first I wasn toto worried. Give me a good API doc (and the engine source) and I should be fine.image00Yeah - not

22、so much.It was hard enough to remember or research the rightwa y to do things in an unfamiliar language -learning the “ Unreal " way to d(sOnosehings sometimes was too much for my tiny brain. Even when I had a modicum of success on the C+ side (some custom structure/classes to embody our voxel

23、world), I was unable to get Unreal to allow the use of these custom structs/classes in certain areas (like RPC calls). image04Oh, I could get past compile errors by adding the appropriate macros or proper 'naming。f my structs/classes -but even after that, RPC calls that used one of these custom

24、structs simply produced empty results on the other side (a problem I STILL haven ' t figuresbdip ass things around in Unreal specific structures and convert/de-convert on the other side). That issue aside, we made progress living in C+ land. I was able to dynamically reference mesh or materials

25、(by name ) at runtime so that I wouldn t fallprey to any brittle wiring losses like that I experienced with Unity. Yay. Until we tried standalone non-editor builds. Then the dynamic techniques to grab those assets at runtime fell over with ugly errors. I ' ve tteadirticles and tried all the tech

26、niques and still found myself unable (at runtime) to dynamically grab a material or mesh or blueprint by name at runtime in C+. So I started looking more closely at Blueprints to see how they could help.image02One senior team member had already started wiring up some blueprint functionality - adding

27、 to the skeleton first person character BP that was tied to the C+ classes I had been working on. Creating little boxesdragging little wires.alashencoedrsMdswos fit was input/controls related as well as GUI/UI stuff elements I figured were probably the bestuse for Blueprints. I started my foray into

28、 blueprints myself was for Material logic. I was AMAZED at the stuff we could easily do in secon ds in a material blueprint that would have taken.DAYSwriting shader code in Unity. It was easy, it was fast, and it was (dare I say it) satisfyingly FUN.While my code remained firmly in C+ land, we slowl

29、y learned to expose variables from the C+ side so they could be accessed from these input/UI blueprints as needed (still haven t deterif you can access a BP variable/function from C+ side but it looks like it is painful). I learned that I could create my critical settings and initialize arrays of im

30、portant game elements in C+ (where it was safe in a non-binary-corruptible file) and expose it in to be used as necessary in Blueprints.Sort of.So interestingly enough .enums are now the bane of my existence. I love enums. Been a huge fan since before the dawn of time and have used them in every hig

31、h level language since I was a wee engineer.Many of the low level elements of our game uses enums at the base to represent all sorts of things - Building types, Voxel types, Resource types, etc, etc, etc. And I spent a bit of time Unreal-ifying these enums so that they could be read properly and use

32、d properly image06in Blueprint land (Unreal made some changes to make it easier back in v4.7? you used to have to use some oddball techniques to deal with them). At the heart and soul of things, Blueprint-land doesn ' t know about enums but it -knows about 8 bit bytes and it treats them as such

33、(but you can still reference them as the Enum type you carefully crafted in blueprints). All that aside, the issue we have been having (v4.9) is that SOMETIMES blueprints want us to cast the Enum type to a byte and sometimes NOT. Sometimes a section of blueprints that previously worked WITHOUT a cas

34、t to a byte -now errors out and requires it. AHHHGGGG. It' lstanolakeuaibajnch ofC+ code changes (UNRELATED TO EXISTING ENUMS) and have the Blueprint editor FREAK OUT after a compile and show a trillion errors (all related to Enum references). At first I spent HOURS recreating seemingly perfect

35、nodes with the exact same inputs and outputs to clear the errors.Then I learned I can simply close the editor and re- open and all is well. WTF? That doesn t makefor a good workflow but we are managing. It ' s possible that this (or part of this) is fixed in 4.91 (several Enum/UEnum related fixe

36、s in the release notes) so we will have to see. (UPDATE - nope - neither 4.9.1 or 4.9.2 seem to have fixed thisso we remain mindful).We are drawing more and more of the C+ side and Blueprint side together exposing C+ functions to blueprints and even creating custom blueprint nodes. I have learned th

37、at I really DO love blueprints - and their place in the development process. They represent a perfect mechanism for certain elements of game development and we appreciate them more and more every day. Most of what we are doing with them is tied to the player character actions- and wesee no compellin

38、g reason to move that code to C+ land. Unreal - you made a convert out of me!Asset ManagementUnity asset management is a very mature beast. Drag a file in to the editor, copy a file to the Assets folder - it just worked. Move assets around to different directories-just drag and drop.The package impo

39、rt/export functionality (some flaky determination of dependencies aside) was top notch. There were even engine functions exposed (through editor scripts) that allowed you to code all sorts of neato-whizbang custom logic to manage your image05resources. Our experiences with Unreal, however were somew

40、hat painful. Some of this was due to ignorance/inexperience on our part but some is still a mystery. Trying to migrate content from one project to another with different directory structures provided many wasted hours. Tryingto migrate (using the tools Unreal provided) Blueprints based on C+ classes

41、 was an unmitigateddisaster. C+ classes cant be myiogurahteadve tocopy on your ownbut should you need tochange class names (we migrated from a project where the we wanted to rename theautogenerated character controller classes) the migrated blueprints are permanently crippled do to un-changeable ref

42、erences to the original class. Moving content (in-editor) between folders was also a severe pain point -Unreal would explicitly leave copies of files behind or empty sub folders and all sorts of references would get broken (some un-fixable). We got burned so much by thats critical COULDagsestectodra

43、rutapbteadselast issue, we simply try NOT to move content around- being extremely careful where we place items from the very beginning. To be fair, Unity and when it did, you were in for a loooong period of re-importing all the assets. But Unity did this all automatically (detecting its own corrupti

44、on and fixing itself) -whereas any detection of issues or fixing is done manually in Unreal.As far as the Unity Asset Store versus the Unreal Marketplace is concerned it ' s simply a matter of maturity. Unity has had years to build up a large and thriving store filled with both free/inexpensive

45、and pricy assets (of varying quality). As an author of several Unity store assets, I was happy with the content creation and selling process (and most importantly payout). Finding and importing new content in Unity was fairly painless. The Unreal marketplace is most assuredly smaller Much smaller. T

46、iny even. And the average price for content is higher. No doubt about it. We ve had no experience yet with selling (or even buying) assets on the store, using internally created assets or starter content as necessary.Procedural mesh manipulationUnity provided the ability to manipulate mesh data (cre

47、ating from scratch or manipulating after the fact) out of the box. Vertices, vertex colors, Uvs - it was all accessible and well documented. Over the years, I used it for countless reasons - terrain deformation, mesh destruction/fracturing, and in ExtroForge, our voxel construction engine required i

48、t. It worked well, it was fast and it was ubiquitous.image03I was surprised to learn that that functionality was officially missing from Unrealstarted using it (4.7ish). Terrain deformation is not supported (at least with the built-in Landscape classes) and interestingly enough even terrain height d

49、ata is only available through the editor - requiring trace/raycast to the terrain at runtime if you want to know the height at a point! There was a lengthy forum post where wicked-smart people had created (and posted) their own codebase to do some basic procedural mesh construction/manipulation, but

50、 it was far from complete. In v4.8, Unreal released an ExperimentalProceduralMeshComponent which closed the gap a bit. We were able to reproduce our voxel procedural mesh techniques in Unreal with little fuss (although I read about some others having issues where moving a procedural mesh component c

51、an leave its physics collider behind!). 4.9.X added some enhancements and it looks like they will continue to improve it. There are still some gaps between what Unreal provides and Unity (like manipulating meshes of already existing models) but at least they are heading in the right direction.Lighti

52、ngUnreal adds an incredible number of open world lighting tools to our arsenal. Yes, Unity rolledout with realtime global illumination via the Enlighten engine, but it stsill limited for an open world where structures are being added and removed all the time. What we really benefited from was the di

53、stance field ambient occlusion, and the realtime indirect lighting via light propagation volumes. Looking into the distance, things in Unity tended to look flat. A distant mountain should cast a shadow on the valley below, but with Unity we just couldn t achieve that without an insaneshadow distance

54、.HighresScreenshot00218Unreal Engine had a solution for that that. Distance field shadows and ambient occlusion are designed to shade faraway things in an approximated kind of way that looks perfect from far away. We really were able to get the lush and well-lit / well shaded world that we wanted to

55、 with Unreal Engine.With light propagation volumes, we were able to create items with emissive materials that would cast light onto nearby geometry. The resulting look is fantastic. Again - this is listed as experimental (we had to make a setting in the engine property files to enable it), but so fa

56、rso good!Open World ToolsIn Unity, we used our own custom terrain height generation logic as well as custom texturing and foliage/feature additions. It was all done dynamically at run-time -and worked fairly well. We were a bit dismayed to find that we couldn t modify terrariunnh-teimigehtinatUnreal

57、 (as longas we were using the built-in landscape elements). However- there were some compensations.We are able to make great use of the new procedural open world tools in Unreal. The ability to assign random grasses and plants to certain terrain textures really helps to make the world look lush and

58、full of life up close.HighresScreenshot00280When it comes to populating the terrain with trees, the new procedural foliage placement tools make it easy to grow entire ecosystems based on rules not unlike our dynamic Unity based system. We still have work to do in being able to generate these maps/wo

59、rlds completely dynamically in Unreal - but we look forward to the technical challenge.Miscellaneous Features And FunctionsPrior to v4.6, Unity UsI system was a bit of a mess. The inefficient built -in system had been superseded by a handful of excellent (but relatively expensive) 3rd party assets.