http://www.phoronix.com/scan.php?page=news_item&px=UE4-SteamVR-Vulkan-GNUX

Is Unity already that advanced?

What I like in Unreal is to combine blueprints with c++.

@[member='Gian-Reto'], what components do you think need to be upgraded to reach the 'Unreal' standard? I know ScoutingNinja mentioned that Unreal just does a better job of pushing more polygons on screen at least.

Terrain system is severly dated... no much has done since I started using Unity 8 years ago. Out of the box, no normal map support by the terrain shaders, god forbid height blending or parallax shading.

There are third party assets that pimp the Terrain System and bring it up to modern standards. RTP is a good example.... Parallax shaders, tesselation that gets rid of LOD popping, heightmap tessalation for the material layers, heightblending, up to 12 materials support... even features like procedural snow and wetness. In this case, you would have to spend A LOT of time in the UE4 material editor and do a TERRIFIC job with it to get anywhere near all of that in UE4.

Of course, on the flipside this is a 60-90$ Thirdparty asset. And a tacked on, that while not really costing that much performance, would run faster if it was integrated into the engine instead of being bolted on top of a 8+ years old terrain system.

Postprocessing... Unity has made some strides now to provide better out-of-the-box postprocessing options, and even created a postprocessing stack. But the best examples are still the ones you have to get from the asset store, costing money, and most of the time giving you standalone postprocessing effects, which can be chained one after the other just fine (as Unity has implemented its postprocessing options since the beginning), but of course again costing performance over the fully integrated stack used by UE4.

You get WAY more options in Unity given you can spend something on the effects, and if you can, also better effects in some instances. But you loose out on the tight integrated stack, as Unity's own postprocessing effects traditionally have been no the best thus their own stack most probably will loose out against both thirdparty individual effects for Unity, and the UE4 stack (though to be honest haven't tried their stack yet, and their Temporal AA effect did a fine job compared to Epics Temporal AA, which didn't work well for me).

Stock classes like character controllers and such... I wasn't too happy with what UE4 gave me in stock classes to speed up development of common code (mostly because it was tightly integrated into the whole Blueprint Fubar, with little documentation on how to use it with clean C++), but Unity's own also do not really make me too happy. This stuff is most of the time ages old, and severly limited in usability. Just recently started working on my navigation and looked into Unity's navmesh components. Well, after a short while I gave up because while the system might be relatively easy to set up, is also extremly limited. How hard can it be to make a hook-in point where I could query if the mouse is currently in the navmesh to implement a better UI that shows you if your characters can actually move where your mouse is currently pointing at?

Now, there IS something in the roadmap about a revamp of the whole navmesh component. Still, I would bet you could work better with Unreals stock classes as they had to be updated ANYWAY for UE4 as Blueprint is a rather new thing and tightly integrated to all of them.

Visual Scripting is not really my friend... in fact I hated Blueprint enough to make it one of the main reasons (besides the crappy temporal AA never really working for me, and no other options for AA being available) for me leaving Unreal again for Unity.

But still, Unreal has a built in visual scripting tool. Unity has a ton of good thirdparty ones, but again only if you can pay something for them.

Light baking is currently partially broken in Unity. Yes, it KINDA works for scenes without terrains or other large meshes (its just unreasonably slow)... as soon as you have a large mesh or terrain in your scene, the whole things crashes and burns as it cannot bake to multiple textures for a large mesh, and the max texture size is 2048x2048... good luck trying to get a good, smooth lightmap for a 1x1km terrain out of that!

And that is only if the process ever finishes... the current lightmapper has a tendency to be glacially slow, and it will trip over and hang for any reason.

The really sad thing is Light baking was working fine in Unity 4! The Beast light mapper was a joy to use and not too slow. Not the multithreaded and networked monster that is UE4's light mapper, but working completly fine for all projects. Shit did hit the fan when Unity believed geomerics that their enlighten tool could do more than just GI... I can already hear the management BS talk, and Unity engineers moan as they had to take out Beast and replace it with something that was never meant to be a light mapper!

Speedtree support is also only partially there. Yes, you can import speed trees. Yes, you can place them individually and they work. Yes, I THINK you can use them as trees in the very dated terrain system.

But the speed tree shaders are CRAP!... clearly made as an afterthought. There are community built PBR Speedtree shaders, but they also only work partially. I had to go into the shaders and hack them to get Specular and Smoothness support. To be fair, there are many reasons why the full set of shader goodies only could work in Forward, and not in deferred, and I think this has nothing to do with Unity, more with how deferred works. That might be ONE reason why nobody spent more than an hour at Unity to get speedtree shaders to work.

More worringly, until Unity 5.4 there has been NO instancing support, meaning your speed trees would severly eat into your performance budget whereas AFAIK Speedtrees are instanced in Unreal Engine. Now, you get basic instancing support in Unity... if you can change the shaders yourself to support instancing because AFAIK to this date Unity hasn't updated the speedtree shaders (which are still not even supporting PBR!)

And if you do that, you break many of the speedtree goodies like LOD Fading, as instancing in Unity currently does not support that.

So yes, you can get speedtrees to work in Unity. Sort of. If you work around the rough edges yourself by having less trees in the scene to not need instancing, or hide the LOD popping because fading does no longer work.

The really sad thing as to why nobody at Unity invests more into Speedtree support is this: A rework to their dated terrain system has been on the roadmap for years (see point one)... as part of it, Unity's own dated tree generator should be reworked. I guess Unity said to themselves "why invest ANYTHING into speedtree now when we can better them with our own tree generator and system when we get around to rework it"... of course the truth is at the current velocity the terrain system will most probably not be reworked until 2020... while speedtrees are still the unwanted step children inside Unity :(

Terrain Streaming AFAIK is handled out of the box by the UE4 Terrain system... in Unity there are thirdparty assets that can do that. Again, if you can pay the price.

http://www.phoronix.com/scan.php?page=news_item&px=UE4-SteamVR-Vulkan-GNUX

Is Unity already that advanced?

Unity's 'developer preview' started six months ago back in September. You can get the beta version and set the graphics API to "Vulkan (Experimental)".

Unity's roadmap has full Vulkan support as 'on target' in 5.6, to be released later this month.

So I'm going with a big YES to your question.

I'm so glad this thread wasn't locked. There's a lot of really good reading here for me.

As an amateur coder, I tried Unreal because I only know C/C++ and it looked like it would be easier to make a 2.5D platformer with it but the lack of documentation soured the experience. This motivates me to give Unity a more sincere shot and see how it works out. I'm using Leadwerks currently and it's a wonderful engine but it would be nice to have access to more features/possibilities.

I'm not going to turn an Engine vs Engine thread into a Language vs Language thread, but it should be clear to most programmers that C++ is horrendously complex, and that other languages (including C#) are not. IDEs don't help there; only a simplified language would do so.

For anyone needing to write highly performance sensitive code in Unity:

There's nothing stopping you from writing all of your game systems in native C++ code.

Write the minimal interface that your gameplay code needs to commicate with the engine.
Write your game against this interface.
Compile it into a dll, which is initialized by an external loader, which passes in an opaque implementation of that interface.
(take note whipper-snappers, the above used to be common practice).
Write a unity C# dll that implements your interface and communiates with the actual unity APIs.
Load your DLLs and plug everything together.
Wow now you're coding like a 90's pro.

Sure can do that... question is if that is the most efficient way to do it. Personally I would try about everything else to speed up my code before going into that. It also makes more sense to me in certain use cases (numbercrunching tasks that can be run in a different thread, before returning a result to the main thread), while it falls on its face in others (constant need to access engine API which might all run in the main thread (at least AFAIK Unity still has a ton of stuff that is not yet multithreaded)).

But sure, this is MOSTLY nitpicking if my sarcasm-o-meter is giving me the right signals with your quoted post :)

My point was more about why I don't think Blueprint is the best thing since sliced bread, and that point came around to Unitys C# sharing SOME of the same limitations at the end of the day (at least when talking about performance).

I am in no way suggesting that hardcore assembler coding is the only way to get a game to perform enough. Or that every part of code needs to run at max speed when you have more than enough CPU time left.

All I am saying is that given the choice, I would pick C++ over C# as long I don't have to jump through hoops to make it work (hence not having dabbled with writing external DLLs in Unity) even though I prefer C# to C++ as a language, and I certainly would pick C++ over Blueprint every time... I think I gave more than enough reasons why.

Having said that, anyone reading the Thread that can give me links to good resources on pure C++ development for Unreal Engine 4? I was serious about being interested in that. My research have not turned up good references that go out of their way to not do 50% of the stuff in Blueprint because its the new "Unreal way of doing things"... but maybe my google-fu was weak, IDK.

Having said that, anyone reading the Thread that can give me links to good resources on pure C++ development for Unreal Engine 4? I was serious about being interested in that. My research have not turned up good references that go out of their way to not do 50% of the stuff in Blueprint because its the new "Unreal way of doing things"... but maybe my google-fu was weak, IDK.

There's a unreal-tournament source-code/developement sample, which pretty much features everything you need to developing C++ in Unreal Engine 4. Unfortunately I cannot find a link right now, sorry, just thought I'd mention it anyway, maybe somebody else has a link or doesn't suck at googling :>

There's no such thing as 'pure' C++ coding in UE4 (at least not practically), but I don't think C++ coding in UE4 is particularly complex, especially if you have Unity experience. Instead of just creating deriving components from Monobehavior, you derive components from UActorComponent. And instead of aggregating components on GameObjects via the Inspector, you derive a new Actor subclass and add the UActorComponent to it. There's a bunch of extra reflection markup macros you need to get used to but the systems are surprisingly similar once you're past that.

It's also worth keeping in mind that 'Blueprint' doesn't just mean 'visual scripting language', it also covers the functionality of Unity prefabs. Using Unreal while trying to avoid Blueprints entirely would be like using Unity without any prefabs, and neither approach is recommended if you want to make the most of the engine.

There's no such thing as 'pure' C++ coding in UE4 (at least not practically), but I don't think C++ coding in UE4 is particularly complex, especially if you have Unity experience. Instead of just creating deriving components from Monobehavior, you derive components from UActorComponent. And instead of aggregating components on GameObjects via the Inspector, you derive a new Actor subclass and add the UActorComponent to it. There's a bunch of extra reflection markup macros you need to get used to but the systems are surprisingly similar once you're past that.

It's also worth keeping in mind that 'Blueprint' doesn't just mean 'visual scripting language', it also covers the functionality of Unity prefabs. Using Unreal while trying to avoid Blueprints entirely would be like using Unity without any prefabs, and neither approach is recommended if you want to make the most of the engine.

See, that was mostly my problem. What I wanted was "create a game object, write C++ scripts, attach them to the game object, create a prefab out of the game object"... yet the official UE4 documentation keeped on harping about creating blueprints, to me mixing the idea of a game object / prefab and a gameplay script into one vague thing I wasn't sure how to interact with.

Lets say I wanted to create my own character controller, that would be different to the stock character controller, and I wanted to keep it as much in C++ as possible. Is there a good resource that describes such a project in general terms (does not need to be a character controller, as long as interfaces a lot with engine API (another thing I struggled with a lot with the official C++ docs), and needs to be attached to a Blueprint "thingie" (the non-Visualscript Blueprint thingie))?

Getting offtopic here, so I'll stop at that.

I use and Like Unity for its ease of use but, Unity is very silly. It has some fundamental drawbacks that would create a jam in long haul projects.

For example there are no abstract objects. Even GUI elements need a 3d transform This is fundamentally weird.