[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vr / w / wg] [i / ic] [r9k / s4s / vip / qa] [cm / hm / lgbt / y] [3 / aco / adv / an / asp / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / qst / sci / soc / sp / tg / toy / trv / tv / vp / wsg / wsr / x] [Settings] [Home]
Board
Settings Home
/3/ - 3DCG



Thread archived.
You cannot reply anymore.



File: 1446605734897.jpg (69 KB, 1280x400)
69 KB
69 KB JPG
can we have an honest discussion about the upsides and downsides of these engines without rabid fanboying?

For me the main differences are as follows

Unity:
less issues when importing assets
base shading model is better at hard surface rendering
easier for coders to write their own shaders and game code.
every material edit updates in real time (no having to apply the changes each time)
Much better tools for 2D games.

UE4:
Blueprints is easily the most robust visual scripting system in any game engine
Blueprints combined with the large community makes it so there are tons of different game systems and behaviors for sale in the asset store.
Comes with great material editor when in Unity you'd have to pay money for a similar thing
comes with built-in game mode templates, making it faster to get started.
comes with way better landscape tools than unity even has on its asset store
default shading model is better at rendering soft and translucent objects. Comes with multiple shading models which have built-in properties that Unity's standard shaders aren't capable of.
Great collision tools
way better at rendering large detailed game worlds.
volumetric lightmaps
better-looking dynamic lighting and shadows.
lots of convenient small quality of life options, like the ability to flip normals in-editor and in-editor texture modification in general.


at least, that's the main things I can think of off the top of my head.
>>
Long story short, don't use Unity. It supports 3rd world immigration to your country and C# is a proprietary Microsoft language.
>>
File: 1361501793510.png (252 KB, 511x428)
252 KB
252 KB PNG
>>592001
This

>easier for coders to write their own shaders and game code.
Blueprint does materials too Meaning anyone can make shaders

Just use Unreal like the rest of us
>>
>>591992
UE4 for artists. Unity for coders or people who like spending money for stuff UE4 comes with.
>>
>>592011
Unity for coders who like to program in a language that is covered by a thousand of submarine patents owned by Microsoft.
>>
>Unity
+ Component system is nice
- Enlighten is useless if you need things to move, which makes me wonder why they thought it was a good idea to use it in a game engine
- Point and spot light occlusion not supported by Enlighten so lights bleed through everything
- Light probes tied to Enlighten data so you can't import baked lightmaps from other software and have probes work with that
- Have to use that shitty slider to adjust shadow cascades instead of inputting values directly
- Giving money to John Riccitiello

>UE4
+ Distance field AO and shadows are nice, could do with a quality boost however
+ Particle system is great, especially the lod support
- Endless fucking baking/compiling
- Giving money to Tencent
>>
>>592015
>- Enlighten is useless if you need things to move, which makes me wonder why they thought it was a good idea to use it in a game engine
>Point and spot light occlusion not supported by Enlighten so lights bleed through everything
>Light probes tied to Enlighten data so you can't import baked lightmaps from other software and have probes work with that

Nobody even uses enlighten in Unity because it's so cumbersome. The progressive lightmapper is great though. I honestly find the results i get with it are better than the results I get with lightmass in UE4.
>>
>>592021
Also how is enlighten useless if you need things to move? The entire point of enlighten is that it's real-time.
>>
>>592022
got bad news mate
>>
>>592022
It's not really real-time. It's precomputed GI and only works on purely static objects, so something as simple as a door will not occlude or contribute to the GI.
>>
>>592011
>UE4 for artists. Unity for coders

As an artist I hate dealing with UE4, and find coding easier in Unity.
>Unity for... spending money for stuff UE4 comes with.

Before Unreal got its own asset store, I might have said that at least Unity gives you some options to buy things neither engine has by default, but at the moment it's pretty much all minus for Unity.

Unity still has favorable licensing terms though.
>>
>>592026
Not a personal fan of Unity's price hike with the version change but it's better than being under the thumb of Tencent for the rest of your life.

Another minus for Unity; gimbal lock in the editor.
>>
>>592026
>As an artist I hate dealing with UE4

The only downsides i've experienced as an artist from UE4 compared to unity is that the base shading model looks weirdly off with hard surfaces and that you have to apply changes to materials rather than having it be fully real-time.

>>592025

Yeah I'm dumb. I was thinking enlighten worked on non-static objects for some reason. But that doesn't mean it's totally bad. It still allows for dynamic lights, just not dynamic objects.
>>
>>592030
>It still allows for dynamic lights
Which is where the problem with point and spots bleeding comes into play. Directional lights work perfectly, emissive materials also work but only on static objects, everything else is just a pain.
>>
How easy are those UE4 "blueprints"? I hear its relatively easy to make something with them. I'd like to make a game with my modeling skills despite my lack of programming experience
>>
>>592070
It's relatively easy, but the logic is always the same, so if you know some programming, you'll learn faster. But it can still be challenging compared to some other engines (construct 2 for example is stupidly easy, but that's just 2D shit) as it doesn't have many premade game logics, you still have to create everything from scratch. I honestly did have somewhat of a hard time in the beginning, and I can program. But yeah, you can learn it and make your game with it, it's a great choice.
>>
>>591992
For me, the reason I chose unity earlier this year for my game was the whole having to rebuild lighting constantly in UE4, I did a test run and tried it for about a month or so and I felt like I was just spending too much time waiting to do shit, which was bothering me.

IT was in part due to my computer not being as powerful back then, but it was still a reason I chose unity.
>>
>>592111
jesus, just disable rebuild lightning
>>
>>592112
the problem is when you are working and bringing in multiple assets you want to make sure they are okay
>>
>>592113
You can bring in everything you need, do one lighting test, then do changes in batches and only rebuild lighting every once in a while.

Though I'm not sure what you mean by "okay". Object placement? Because that's the only thing I can think of that would require you to rebuild lighting frequently.
>>
>>592122
When you guys are talking about this, I need to ask something about UE4.

How tf can I tell how the lighting will look like after the build? It's impossible to wait every time for 20+ minutes and then having to change something and baking all over again. It's so much easier to tweak it in real time with dynamic lighting, but it sucks that if I bake it like it is, it will look completely different. It especially sucks while you're relatively new at it and don't know what you're exactly doing, so you need to experiment a lot.
>>
>>592070
For me BPs are the only reason why I use UE4, Unity has something similar via plugin but this solution is better integrated. I’m pretty much exclusively an artist and froth up at the sight of code, so it’s the only way I can make anything interactive. Because flow charts are such a large part of 3D these days, whether it’s setting up particle systems or generating materials, the core concept is familiar enough that you don’t have to battle with unnecessary abstraction.

BPs make it easy enough by visualizing things and allow you to solve problems in a wide manner of ways that at worst you might get punished with poor optimization, rather than shit that flat out doesn’t work. UE4 does some pretty hard hand-holding with regards to what you can and can’t hook up, so it’s easy to avoid imploding the software.
Either way I’d suggest watching some tutorials and also dissecting the tons of content provided by Epic and drilling down into it, if you can get over the initial learning curve it’s not that hard in the end.

Currently I’m watching this course https://www.udemy.com/unreale4/ and it’s pretty good, the tutor doesn’t waste time throwing you under the bus and goes right in to how to make stuff without wasting time explaining every detail. I guess some people learn better when they are told the details, but for that you have documentation. I previously watched another tutorial where the guy makes a 2.5 scrolling shooter, but even though he explained more things, I actually learned less overall.
>>
>>592127
1. You don’t have to build production-grade lighting each time, just dial back the setting, it’ll be slightly darker, but still 95% similar.
2. Your lightmap resolution settings might be too high.
3. You might have some settings turned up too high, like number of light bounces.
4. Maybe set up a separate small level for testing out how objects will bake.
5. What CPU do you have? UE4 uses Embree for light rendering and it generally runs better on Intel CPUs,
Sometimes by a lot.

There’s a good chance that your problem is one more of optimization rather than that UE is too slow, although it is generally a good idea to have a fast system for it.
>>
>>592134
1. I bake in preview (or medium for smaller scenes)
2. Maybe, although I let UE4 create lightmaps often, and I'd expect it doing it well.
3. 10 light bounces, don't know if that's a lot, but yeah, I do crank my settings up high. But what's the point of lowering that down when previewing when I'll get a completely different result, those are important and I need to test them every time.
4. Currently I'm working on a small-ish exterior scene, and still have to wait for at least 10 minutes for a bake.
5. i5 6500

I mean, even it if was 1 minute long, I'd still be salty because it's so much faster in real-time.
>>
>>592138
>I mean, even it if was 1 minute long, I'd still be salty because it's so much faster in real-time.
lol I guess expectations/perspective have a part to play as well, I come from a CPU renderer background so even if the bake is 20 minutes for a reusable scene, it’s better than hours for one frame.
And no, 10 bounces isn’t a lot, I meant more like 100.
>>
>>592143
Me too and I hated that shit. But even if it is faster in UE4, I hate it here too, because I never know what will happen after the bake and I could spend days getting the lighting right, compared to maybe a few hours with dynamic lights. Like, I tend to constantly increase and decrease some parameters by a few decimals, and that still takes time with real-time results. Baking it every time is fucking painful for me.
>>
JUST A NOTE HERE:
No, the fact that Unreal has an integrated material editor doesn't mean you can do every shader imaginable.

You can't, you are still limited by what the material domains/presets outputs are. For example, you can't make a decal and control roughness, color, and normal opacity, individually, with extra maps, as you only have one opacity output. In unity, as you can code pretty much everything from scratch, you can do so, just take a look at DecalMachin3 shaders.

In my opinion, Unity is the old reliable toolbox: you can do pretty much everything with it, but you will end up having to buy extra tools some time. Unreal is like a fully professional equipped workbench, but with the limitation of not being able to add new extra tools for it if you need to.

I still prefer unreal, I think that you can, by default, do better stuff with it than with unity, but whenever you want to change something (like I said, material domains), it is a pain in the ass because you have to basically dwelve into the source code and recompile the whole motherfucking engine
>>
>>592122
i do architecture, sometiems the bigger meshes (most of the time) have light map issues even after unwrapping so its something that needs to be checked along the way
>>
>>591992
Godot is better than both, to be honest.
>>
>>592010
But blueprints are utter trash and you don't know what you're talking about.
>>
>>592202

Blueprints are amazing you fucking hipster.
>>
I've wanted to get away from Unity a few times due to stuff like the code being extremely unprotected but it's way too easy to work in. They're taking some pretty great steps in the coming versions though, the engine is becoming properly multi threaded and taking the ECS route.

https://www.youtube.com/watch?v=tGmnZdY5Y-E

It seems pretty solid, they basically force you to write multi threaded code efficiently.
>>
File: 1504207689614.jpg (46 KB, 566x562)
46 KB
46 KB JPG
>unreal
>>
File: confused..jpg (3 KB, 134x114)
3 KB
3 KB JPG
>>592201
What?
>>
>>592202
>blueprints are trash

Wut. You can use them if you're not a coder and if you are a coder you can literally convert the blueprints to C++.

>>592176

>No, the fact that Unreal has an integrated material editor doesn't mean you can do every shader imaginable.

Honestly, this wouldn't be as much of an issue if UE4 expanded the material editor to be houdini-tier. But yeah, that shit sucks and I don't understand why they don't seem to care about that limitation. They seem more focused about VR shit and audio stuff.
>>
>>592203
Blueprints aren't context-aware, they aren't optimized.
>>
>>592011
It's even funnier that Unity tried to stole the lighting and postprocessing effects ideas from UE4 and they completely screwed it up.
>>
>>592245
It's even more funny that the guy they hired to make the new post-pro effects for Unity took down his old color grading addon because he said he didn't want a conflict of interest with his new developments but still keeps his higher quality image effects and SSAO on the store while putting garbage versions in the stack.
>>
>>592201
I know it isn't /3/ but is Godot better for 2D than Unity? And how does it hold up with 3D? Just looking to learn an engine that could do both...
>>
>>592201
Name 1 (one) good game made in Godot.

(Hint: nobody can name any)
>>
>>592264
Console version of Deponia 4.
>>
I've used both quite a lot, and I can't be arsed writing a long explanation (I will say that I loathe Unity's component system), but here's what I will say:

Look at what results are produced with UE4 vs what is produced with Unity. That's all you need to know.

>b-but it's the developer's fault not the engine's!
Pure ego, if 99.99999% fail to produce quality work comparable to UE4 in Unity why the fuck do you think you'll do any better? Hope you got a lot of proof backing the statement that you're better than the vast majority.

>b-but it's just that more experienced people pick UE4 while Unity is mostly used by beginners!
Exactly, why do you think people with experience pick UE4 over Unity? They know damn well it's a superior package.

>>592011
>Unity for coders
Why the fuck would a coder want to use Unity when UE4 offers C++ and source access?
>>
>>592251
Godot is absolutely better for 2D than Unity. Godot has an actual proper 2D renderer. Unity "2D" is just 3D with a forced orthographic camera. In the upcoming Godot 3.0 the 3D renderer has been completely rewritten and now uses PBR. It still has a few missing things like in-game IK support. But overall it's good for 3D, but I wouldn't say better than Unreal. It's still better than Unity in my opinion cause, but I think Unity is trash
>>
>>592284
Godot is the Blender of game engines.
>>
>>592285
Which explains why it's so good.
>>
>>592284
You can use Unity in true 2D mode with Futile, but it comes with its own quirks, since you’re basically stripping Unity itself down to just input handling and rendering.
>>
>>592286
If by good you mean bad.
>>
>>592284
okay thx
>>
>>592241
>Blueprints aren't context-aware
what? yes they are
>>
>>592241
They are, and you can cook them down to C++ and the performance is about 95% of C++ code.
>>
>Unity
Much larger asset store

>UE4
Everything else
>>
>>592678
>Buying things from asset store anyway
Yeah, UE4 is the only right way. Don't know about CryEngine, though. Is that even free or not? Why is it not more popular?
>>
>>591992
We're not /g/, we're not /v/, we're not /agdg/.
We shouldn't concern ourselves with anything that isn't art related. So this isn't even a question.
UE4 is the only choice.
>>
>>592680
This. We're fucking artists. We should be making our own assets.
If you're buying them either you're shit or don't have enough time in the first place to be making a game.
>B-But non-art assets
Get a programmer and a real engine.
>>
>>592680
It is free, but it is supposedly a hell of a job to learn, work with, and most imporant of all, importing assets to. Don't knwo in what sense, but just what I've heard.
>>
>>592680
>Yeah, UE4 is the only right way. Don't know about CryEngine, though. Is that even free or not? Why is it not more popular?
Apparently CE5 is free and doesn't even have royalties attached, making it even more free than UE4, however the success someone can have using any given engine is linked to how well it's supported in terms of community and documentation.
Unity is very popular, there are a ton of sources for learning it inside and out, and even entire templates for making a game where you basically just add your own assets. Even though it's the only engine without an integrated visual scripting system, assuming you have some programming skill or know someone who does, it's by far the easiest option to utilize.
UE4 fits in the middle of the pack and even though it's a fairly complete system and is more artist-friendly than Unity, it is generally less-explored territory as well. Most of your learning will have to come from digging through projects and the few tutorial series available and various youtube videos.
CE5 must have gone free very recently, because there's almost no support for it outside of the official community. It does have fully integrated visual scripting similar to BPs called FlowGraph, but it seems less advanced than UE's.
>>
>>592699

Cryengine V (starting from 5.3) has Schematyc which is the equivalent of UE4's blueprints, it's way more advanced and easy to use than Flowgraph.

I don't think CEV is that hard to use when it comes to art and level design, but it's definitely less user friendly. You have to use fucking wwise to get your music and sound effects inside the engine (in UE4 you just import them inside the engine, you can waste your time using shitty wwise if you want to but it's not an obligation). The mannequin editor for blendspaces is a fucking pain in the ass. You have to create your collisions yourself for every single object (it's not that bad, but there should be an option to generate them).

However creating levels is a breeze in cryengine, the fbx importer works well, the tools are very good, and it's very fast to work with. And it looks WAY better than Unreal. But graphics aren't everything, if you want to make a game on your own as an artist then Ue4 is the only good choice. If you're some russian hacker living in a creepy appartment in chernobyl or a small team, then CEV might be good.
>>
>>592700
Yeah, just checking out their website, I see that there are some pretty awesome features, as well as some glaring omissions that I hope get patched in sooner or later.

One big issue is that it only runs on Windows, which it seems is one of the reasons support isn't as hot for it as the other options, lots of developers use OS X and develop for mobile, so Crytek may want to consider broadening their hardware support.
>>
>>591992
UE4 runs like shit on full potato pcs. That's the reason why I still use unity. And I find c# simple to use, unlike blueprints or c++
>>
>>592700
> You have to create your collisions yourself for every single object
yeah, and UE4 is actually getting their auto-collision tool improved in the next update.
>>
>>592680
>Why is it not more popular?
Can't make porn with it.
>>
>>592747
C# is the new Java. Just worse and just as proprietary.
>>
>>592680
>Why is it not more popular?

Buggy as fuck, broken, trash documentation, little to no support, and as user friendly as a Turkish dwarf with anger issues.

Like >>592700 said it has some good shit but it's not worth it unless you're a team (in my opinion even then it is not worth it, even large teams prefer UE4 and CE5 while better looking isn't that much better looking than a properly set up UE4).




Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.