Unreal Engine 4.17 Released(unrealengine.com)
unrealengine.com
Unreal Engine 4.17 Released
https://www.unrealengine.com/en-US/blog/unreal-engine-4-17-released
56 comments
Not into Gaming Development, but could anyone tell me why All Unreal Rendered Games Graphics look alike? You could literally tell it is Unreal engine if it has those Shiny Rendering Graphics on Metal or Rocks. And they dont look great. There is something about its Light Reflection rendering that i think is "Trademark" of Unreal. And they dont seems to have improved over the many iteration of releases.
Biggest telltale sign of an unreal game for me is when it streams in new objects/effects a frame too late. If you turn too fast you often see the end a corridor drawn in a frame late and see the skybox in some worst cases. You can even see it in this video [0] which looks gorgeous in stills but as soon as the camera changes there is a single frame where the reflections are not drawn in yet.
Still amazing tech, just something I've noticed.
[0] https://www.youtube.com/watch?v=_nLGoqqDc0w
Still amazing tech, just something I've noticed.
[0] https://www.youtube.com/watch?v=_nLGoqqDc0w
To try and give a slightly better answer then others, without complicating too much.
My thought it is because they use the default shaders (and/or the artists do glossy too much). That said..
Most, if not all, modern big engines use "deferred shading" and support normal/bump maps, gloss/reflection maps in addition to "normal" textures (lately every rendering engine that focuses on being realistic is switching to "Physically based rendering", that is very similar to "normal" rendering except that it obeys the "amount of (light) energy out can not be greater then the amount of energy in"(this also means linear light space, instead of logarithmic like we humans perceive)).
All the big rendering engines can, with the same equations in shaders, produce exactly the same result. The same results in regards to the direct "shading".
The other part of how a thing looks is lighting (aka "global illumination"), where the actual engine code is a lot more involved. Since you can't make, like raytracing does, light bounce off of things, you have to cheat (it uses too much processing power). Rendering engines cheat by, for example, plunking "light probes" around (unity had a good post about them, i can't find it now). The slight differences in lighting may not seem like much in a side by side comparison, but our brains use those little lighting clues meaning they(we) are sensitive to them.
There is also how many lights a rendering engine supports (and the distance they can cast light), how it does particles and can they emit light, how it does volumetric.. things (like smoke, maybe water and such), how good it is at reflections (are they precise, do they include dynamic things; note that they probably don't bounce twice), subsurface scattering (notable on skin), and probably more that i forgot.
Note that i simplified plenty. For example lighting and shading are closely related.
PS Reality is not like basic theory. Physically based rendering does give real world results but in reality everything has dust on it, or an oxide layer (aluminium especially), or a sulfide layer (copper likes sulphor). The other imperfection is the minor imperfections in smoothness, what the collective "they" do take into equation (see https://www.cs.cornell.edu/~srm/publications/EGSR07-btdf.pdf).
PPS "Physically based rendering".. as if Phong shading is based on something else. (PBR is still no where near reality, for reasons above)
My thought it is because they use the default shaders (and/or the artists do glossy too much). That said..
Most, if not all, modern big engines use "deferred shading" and support normal/bump maps, gloss/reflection maps in addition to "normal" textures (lately every rendering engine that focuses on being realistic is switching to "Physically based rendering", that is very similar to "normal" rendering except that it obeys the "amount of (light) energy out can not be greater then the amount of energy in"(this also means linear light space, instead of logarithmic like we humans perceive)).
All the big rendering engines can, with the same equations in shaders, produce exactly the same result. The same results in regards to the direct "shading".
The other part of how a thing looks is lighting (aka "global illumination"), where the actual engine code is a lot more involved. Since you can't make, like raytracing does, light bounce off of things, you have to cheat (it uses too much processing power). Rendering engines cheat by, for example, plunking "light probes" around (unity had a good post about them, i can't find it now). The slight differences in lighting may not seem like much in a side by side comparison, but our brains use those little lighting clues meaning they(we) are sensitive to them.
There is also how many lights a rendering engine supports (and the distance they can cast light), how it does particles and can they emit light, how it does volumetric.. things (like smoke, maybe water and such), how good it is at reflections (are they precise, do they include dynamic things; note that they probably don't bounce twice), subsurface scattering (notable on skin), and probably more that i forgot.
Note that i simplified plenty. For example lighting and shading are closely related.
PS Reality is not like basic theory. Physically based rendering does give real world results but in reality everything has dust on it, or an oxide layer (aluminium especially), or a sulfide layer (copper likes sulphor). The other imperfection is the minor imperfections in smoothness, what the collective "they" do take into equation (see https://www.cs.cornell.edu/~srm/publications/EGSR07-btdf.pdf).
PPS "Physically based rendering".. as if Phong shading is based on something else. (PBR is still no where near reality, for reasons above)
Agree with you. (not sure about most recent version)
The same with ID Tech, Unity, RAGE and CryTech/Dunia games. One can spot them "from 50 feets away", or at least when trying out the controls, the character physic gets rarely changed at all. (I cannot say the same thing for Frostbite 3 and AnvilNext, the are more modern.) And many Unreal and Unity games use the standard shaders included with the dev kit.
(e.g. Titanfall 2 based on Source 2 still feels very like the controls from Quake 1, well it's based on the same engine after all).
The same with ID Tech, Unity, RAGE and CryTech/Dunia games. One can spot them "from 50 feets away", or at least when trying out the controls, the character physic gets rarely changed at all. (I cannot say the same thing for Frostbite 3 and AnvilNext, the are more modern.) And many Unreal and Unity games use the standard shaders included with the dev kit.
(e.g. Titanfall 2 based on Source 2 still feels very like the controls from Quake 1, well it's based on the same engine after all).
I don't know that all look alike (there's a bunch), but Unreal, Unity, etc tend to ship with a lot of premade shaders and materials.
A lot of them are similar but then you have games like Fortnite which looks totally different.
They don't, you are imagining this.
Unreal and Unity ship with their own default PBR shaders and settings. So if the developer doesn't modify them, the lighting can make games look similar. Unreal's lighting reflections is generally considered very good though.
Yes, just to comment on this Unreal Engines lighting is considered really good (and it is imo). The reflections you see in game are actually the responsibility of the creators of the games not the engines.
A newer game that has pretty decent lighting is PlayerUnknown Battlegrounds. Check it out, you might see less of those aggressive reflections.
A newer game that has pretty decent lighting is PlayerUnknown Battlegrounds. Check it out, you might see less of those aggressive reflections.
I go back and forth on the looks PUBG, sometimes its gorgeous, sometimes the buildings don't load.
There will be moments where the landscapes and vistas are almost as impressive as Witcher 3 and then I get shot.
There will be moments where the landscapes and vistas are almost as impressive as Witcher 3 and then I get shot.
could anyone tell me why All Unreal Rendered Games Graphics look alike
They don't. It can feel like they do because the same libraries, models and shaders are reused a lot between games, but there's a lot of variety if you look hard enough. Comparing the look of RiME to Crackdown 3 to EVE Valkyrie shows there can be a lot of difference.
Have a browser through Unreal Engine's trailer showcase - https://www.youtube.com/playlist?list=PLZlv_N0_O1gYaMTM__mGE...
They don't. It can feel like they do because the same libraries, models and shaders are reused a lot between games, but there's a lot of variety if you look hard enough. Comparing the look of RiME to Crackdown 3 to EVE Valkyrie shows there can be a lot of difference.
Have a browser through Unreal Engine's trailer showcase - https://www.youtube.com/playlist?list=PLZlv_N0_O1gYaMTM__mGE...
Unreal didn't invent its own shading model. Instead Unreal and a bunch of other game engines now use what is called PBR (work on this started in Pixar before game engines)
I think the possible explanation on why they may look different to you than other PBR engines (say renderman or unity) is that IIRC UE4 has slighly different curves for roughness and other properties. but still I would credit it to what the other comment said about shared assets and people using defaults.
you can see information from disney here: https://disney-animation.s3.amazonaws.com/library/s2012_pbs_...
and here are the ue4 docs, with some other references at the bottom: https://docs.unrealengine.com/latest/INT/Engine/Rendering/Ma...
I think the possible explanation on why they may look different to you than other PBR engines (say renderman or unity) is that IIRC UE4 has slighly different curves for roughness and other properties. but still I would credit it to what the other comment said about shared assets and people using defaults.
you can see information from disney here: https://disney-animation.s3.amazonaws.com/library/s2012_pbs_...
and here are the ue4 docs, with some other references at the bottom: https://docs.unrealengine.com/latest/INT/Engine/Rendering/Ma...
Probably the biggest tells of a UE4 game are in screen space reflections for reflective surfaces, and the use of temporal antialiasing (which can cause minor ghosting artifacts, particularly in reflections). These can be found in other game engines too, but the artifacts of UE4's particular implementation are pretty distinctive (to me).
Unreal games look alike because maybe most people think the default lighting model is really good? I have seen screenshots of some Unreal powered games that look like grease has been smeared everywhere, but others look pretty good.
But then there's the Borderlands games. Those are based on Unreal, but they don't look like any other game out there.
But then there's the Borderlands games. Those are based on Unreal, but they don't look like any other game out there.
If you've played a game or two on an engine, it's usually pretty easy to spot other games that use the same one. Not just an Unreal thing.
While Unreal 3 games are usually pretty easy to spot, Unreal 4 games that make full use of the engine's customizability are not. The lighting and texturing capabilities received a massive overhaul between the two versions.
If they aren't straying far from the defaults then it should be obvious why they would look the same.
While an experienced Unreal developer knows what to look for, the average gamer most likely couldn't tell if a AAA game was using Unreal Engine 4.
If they aren't straying far from the defaults then it should be obvious why they would look the same.
While an experienced Unreal developer knows what to look for, the average gamer most likely couldn't tell if a AAA game was using Unreal Engine 4.
Feature packed as always. I love Unreal Engine's patch notes. 4.16 was released at the end of May and was equally impressive so it's pretty insane.
I asked everytime but never get an answer.
How did Unreal manage to evolve so quickly? If it was just one patch notes then may be just a coincidence, but they have manage to do it every time for the past months or years. I cant think of a single software / middleware that has this pace of development. And Games Development were suppose to be hard?
How did Unreal manage to evolve so quickly? If it was just one patch notes then may be just a coincidence, but they have manage to do it every time for the past months or years. I cant think of a single software / middleware that has this pace of development. And Games Development were suppose to be hard?
They also a have ton of licensees which are AAA game studios with qualified profesionals often backporting fixes and features into the main branch. Appart from that the engine is completely open sourced.
I also get the impression Tim Sweeney, the one man developer behind the first engine, is rather good at assembling and managing tech teams.
I also get the impression Tim Sweeney, the one man developer behind the first engine, is rather good at assembling and managing tech teams.
[deleted]
Tim Sweeny has been doing the game engine thing a long time:
https://en.wikipedia.org/wiki/ZZT
It probably helps that they are among the most if not the most popular third-party gaming engine on PC, as well as the de-facto cross-platform (PC and consoles) gaming engine.
I guess its a really clean architecture- developed together with performance-senstive personal. The good architecture allows for fast movement, the performance sentive check ups, keep it from beeing slowed down from bad architecture decisions.
Its very rare indeed.
Its very rare indeed.
Thanks for this. I used to express similar sentiment with every changelog, but started sounding like a broken record in short order.
Epic definitely has one of the most productive and effective teams in software development. I just marvel at it every time.
Epic definitely has one of the most productive and effective teams in software development. I just marvel at it every time.
I struggle to learn the new features as fast as they release them. Feel I am always a lagging behind.
welcome to the world of computing/computers :)
Then again, i swear often i should have become a farmer, though i somehow doubt same principles don't apply there too.
Then again, i swear often i should have become a farmer, though i somehow doubt same principles don't apply there too.
Does anyone know what the Linux support is like these days?
I see lots of linux improvements in the release but last time I tried it was impossible to get my hands on the really obscure linux alpha build.
I see lots of linux improvements in the release but last time I tried it was impossible to get my hands on the really obscure linux alpha build.
There's a package on AUR that works pretty well (https://aur.archlinux.org/packages/unreal-engine). I can't speak to other distros, but this package worked reasonably well on my system.
i have had success with running engine and creating content on linux since 4.12 or so. Seems to work ok, not a lot of dependency issues like i get with unity which relies a lot on distribution specific things like gnome service stuff.
https://wiki.unrealengine.com/Building_On_Linux
Following that guide i managed to get it running on debian and gentoo systems. I'm not a pro developer, so i might have not touched all features to test them, but to me it seemed to work fine. Didnt do any programming for it on linux yet, so dont know how to or if its possible to build the code on linux, but the engine itself works fine. blueprints etc. and standard features worked fine too.
Following that guide i managed to get it running on debian and gentoo systems. I'm not a pro developer, so i might have not touched all features to test them, but to me it seemed to work fine. Didnt do any programming for it on linux yet, so dont know how to or if its possible to build the code on linux, but the engine itself works fine. blueprints etc. and standard features worked fine too.
Are there any major usability differences for Unreal compared to Unity for less experienced developers? I am a big fan of Unity's ease of use when prototyping and Unreal has always seemed more daunting
Game development is hard and making anything substantial will require spending thousands of hours in either engine, so it's more about the purpose of the engine rather than ease of use, since you will eventually have to learn all the ins and outs of either one.
Unreal is a "AAA" engine originally meant for large teams. It has much better level design tools and collaboration features, but all programming must be done in C++ which is fragile and can break the whole engine. Lighter scripting can be done with Blueprints which is good for designers making levels interactive. Unreal is a good choice if you are aiming to make a serious production with a team making large detailed levels.
The Unity Asset Store has many more plugins and it's easier to put together a sandbox type game with lots of features, since its managed code design makes it easier to drop in scripts other people have made. There are level design tool plugins available that mimic what Unreal does, but they aren't as polished and collaboration is harder.
Unreal is a "AAA" engine originally meant for large teams. It has much better level design tools and collaboration features, but all programming must be done in C++ which is fragile and can break the whole engine. Lighter scripting can be done with Blueprints which is good for designers making levels interactive. Unreal is a good choice if you are aiming to make a serious production with a team making large detailed levels.
The Unity Asset Store has many more plugins and it's easier to put together a sandbox type game with lots of features, since its managed code design makes it easier to drop in scripts other people have made. There are level design tool plugins available that mimic what Unreal does, but they aren't as polished and collaboration is harder.
Just to expand on this a bit, the Blueprints capabilities have grown to the point were you can create entire games without learning a single line of code.
The major downside I see to blueprints is a lack of source control. This is a pretty massive downside, and not something a professional team can forgo. But if you are looking to learn and understand the engine as a solo person Blueprints are a great place to start.
The major downside I see to blueprints is a lack of source control. This is a pretty massive downside, and not something a professional team can forgo. But if you are looking to learn and understand the engine as a solo person Blueprints are a great place to start.
Blueprints can be used with source control, so your comment is highly misleading. Merging and diffing blueprints is possible as well, as they are serialized in text format and there are tools to assist with that, but merging is unrelible. In practice Unity scenes and prefabs have the same issue. Professional teams, including Epic of course, use Blueprints heavily and always use source control...
I used Unity a bit and have the feeling they are more into the mass marked than Unreal.
It shows in the fact that Unity uses C# instead of C++, which has less historical baggage and is a bit safer, especially for junior devs I think.
Unreal seems to be for projects that need the raw power of C++, but don't want to go into doing their own thing.
I for one never met a Unreal dev, only a mass of Unity devs and the ones that do their own engine.
It shows in the fact that Unity uses C# instead of C++, which has less historical baggage and is a bit safer, especially for junior devs I think.
Unreal seems to be for projects that need the raw power of C++, but don't want to go into doing their own thing.
I for one never met a Unreal dev, only a mass of Unity devs and the ones that do their own engine.
I've used both a little bit and as a complete novice to graphics/game development I would say the biggest difference was the lack of good tutorials which Unity has and Unreal not really.
While I've been a developer for many years, I've only started with UE4 about a month ago, and I've got to say that the experience has really been great.
Not only are there really, really good official video tutorials to get you up-and-running, but also while UE4 is definitely a complex piece of software, you can get started pretty easily just by knowing a few things. I think that having Blueprints is a huge win, since they allow you to very easily program without having to learn new language syntax, are easy to read, and the visual debugging/real-time flow chart capabilities are very cool.
After only a month or so (of inconsistent, hour-or-two-in-evenings hobby time), I feel pretty comfortable with the engine and need a lot less handholding than I expected to need at this point.
Not only are there really, really good official video tutorials to get you up-and-running, but also while UE4 is definitely a complex piece of software, you can get started pretty easily just by knowing a few things. I think that having Blueprints is a huge win, since they allow you to very easily program without having to learn new language syntax, are easy to read, and the visual debugging/real-time flow chart capabilities are very cool.
After only a month or so (of inconsistent, hour-or-two-in-evenings hobby time), I feel pretty comfortable with the engine and need a lot less handholding than I expected to need at this point.
Unity makes it easier than get started. Unreal makes it easier to ship. Caveat: my understanding of Unreal is limited.
The sources of differences are:
Unity's primary audience has been hobbyists. Unreal's has been AAA devs. Unity doesn't ship games themselves, so they tend to focus on flashy, marketing-friendly features. Epic used to ship FPSs at least (they've slowed down in that area). Unity's huge audience pushes them into a large commitment to a ton of legacy architecture dating back to the web plugin. UE is on Ver4 (whereas Ver1 & 2 might predate Unity).
A big one is that Unity uses C# vs UE's C++. Garbage collection is great in the beginning. But, when you go to ship it becomes the enemy. You end up needing to structure everything to have no allocations at run time to avoid GC hitches. So, you start out coding like a modern app dev and end up coding like a classic embedded C dev. Except you aren't using C. You are using a language that tries to sneak allocations past you all over the place.
If you are a hobbyist, Unity is really great. It's great for experimenting, prototyping, and for remaking your own take on that game from 10+ years ago. If you want to make a modern game, be prepared to fight and rewrite a lot of the core of Unity. The editor is great though!
Unreal, however, is a lot more complex and challenging to get started. And, it's not all roses when it comes to shipping either. UE tends to favor a heavyweight setup cost in order to make using high-end features a bit cheaper. That's not great if you don't actually want to pay for those features. UE is technically on mobile, but only because high-end mobile hardware is catching up to what UE requires. Getting UE to run 60fps has been a challenge forever. The Mortal Kombat team has at least one GDC talk about the extensive surgery they had to perform because their management dictated that they use UE.
The sources of differences are:
Unity's primary audience has been hobbyists. Unreal's has been AAA devs. Unity doesn't ship games themselves, so they tend to focus on flashy, marketing-friendly features. Epic used to ship FPSs at least (they've slowed down in that area). Unity's huge audience pushes them into a large commitment to a ton of legacy architecture dating back to the web plugin. UE is on Ver4 (whereas Ver1 & 2 might predate Unity).
A big one is that Unity uses C# vs UE's C++. Garbage collection is great in the beginning. But, when you go to ship it becomes the enemy. You end up needing to structure everything to have no allocations at run time to avoid GC hitches. So, you start out coding like a modern app dev and end up coding like a classic embedded C dev. Except you aren't using C. You are using a language that tries to sneak allocations past you all over the place.
If you are a hobbyist, Unity is really great. It's great for experimenting, prototyping, and for remaking your own take on that game from 10+ years ago. If you want to make a modern game, be prepared to fight and rewrite a lot of the core of Unity. The editor is great though!
Unreal, however, is a lot more complex and challenging to get started. And, it's not all roses when it comes to shipping either. UE tends to favor a heavyweight setup cost in order to make using high-end features a bit cheaper. That's not great if you don't actually want to pay for those features. UE is technically on mobile, but only because high-end mobile hardware is catching up to what UE requires. Getting UE to run 60fps has been a challenge forever. The Mortal Kombat team has at least one GDC talk about the extensive surgery they had to perform because their management dictated that they use UE.
I think UE4 brings a lot to the table for certain genres and game designs. If you need really nice animation, nice character locomotion, vehicles etc... UE4 seems like it is easier in the long run despite it being daunting when you boot it up. I like unity for more experimental work and grid based games. Kind of like programming languages, learning UE4 has taught me interesting things that I would not have learned just by playing around in unity.
I guess there is also the issue of licensing costs which are substantial, but that requires actually shipping for that to matter :)
I guess there is also the issue of licensing costs which are substantial, but that requires actually shipping for that to matter :)
A few people have mentioned that Unreal uses C++ and Unity uses C#, but note: https://mono-ue.github.io/
Unity will tend to be easier, unless you need performance then Unity can get harder!
There are more tutorials out there for Unity but a lot of them are written by people who don't have much more of an idea of what they doing then you do.
Less experienced developers might benefit from using neither of these things at first, start with maybe basic 2d stuff using just SDL2, or maybe a framework like monogame.
This way you can learn a bit about game programming, fundamentally, without having to learn how to use the engines and its editors and so on.
There are more tutorials out there for Unity but a lot of them are written by people who don't have much more of an idea of what they doing then you do.
Less experienced developers might benefit from using neither of these things at first, start with maybe basic 2d stuff using just SDL2, or maybe a framework like monogame.
This way you can learn a bit about game programming, fundamentally, without having to learn how to use the engines and its editors and so on.
If you want to write something with old-school blocky 3d models (think X-Wing, early Mechwarrior games, Starfox) is it easier to just learn how to do that in a modern engine like Unreal/Unity, even though it's way overkill for the purpose, or work from a smaller and simpler base?
From my experience I would say yes: Go with Unity.
I'm a big fan of making everything by "scratch" (using libraries like SDL2 or SFML for 2D), but when it comes to 3D games I wouldn't think twice and dive straight into Unity; even if I'm not a huge fan of the environment I know it's the easiest/best tool available.
You can maybe use something like Irrlicht (http://irrlicht.sourceforge.net/) but I don't think that's still going to be easier in any way than Unity.
I'm a big fan of making everything by "scratch" (using libraries like SDL2 or SFML for 2D), but when it comes to 3D games I wouldn't think twice and dive straight into Unity; even if I'm not a huge fan of the environment I know it's the easiest/best tool available.
You can maybe use something like Irrlicht (http://irrlicht.sourceforge.net/) but I don't think that's still going to be easier in any way than Unity.
Unity has put a lot more effort into optimizing for lower-end iOS and Android devices. You can build a big shiny awesome game in Unreal, but it's unlikely to run on older devices due to memory requirements.
50 pages of fixes and features! Unreal is an amazing beacon of technology that continues to push the limits and makes me proud to work with computers. Thank you Epic!
Ctrl+F for the word 'fix' highlights 540 locations. Great they take the time to fix reported errors, but I wonder what their testing strategy is in the first place that led to this many problems being in the official release.
These include all the commit logs. How many times did your first commit for a brand new feature need zero fixing.
Can anyone recommend a good book on how to break into the Unreal Engine 4 SDK?
This month's Humble Bundle might be relevant (https://www.humblebundle.com/books/unreal-unity5-book-bundle)?
Helpful, bought it. Although the first book I picked to read was dreadful.
https://www.udemy.com/unrealcourse/
Not a book, but this course has been the best resource I've found. Just wait for one of Udemy's constant discounts so you don't have to pay more than $10-15 for it.
Not a book, but this course has been the best resource I've found. Just wait for one of Udemy's constant discounts so you don't have to pay more than $10-15 for it.
Usually don't even have to wait, you can just lookup coupons most of the time.
Thanks for the link! I was specifically looking for a book to read on my commute in NYC, but the course was ten bucks so I bought it anyway, why not.
As you can see, the engine is evolving quite rapidly, so a book might not be a great format. Thankfully the course has active forums at gamedev.tv and the instructors go back to annotate videos if something is completely different.
re:Humble Book Bundle: no offense intended to Packt writers, but the books they publish are somewhat hit and mostly miss :/
re:Humble Book Bundle: no offense intended to Packt writers, but the books they publish are somewhat hit and mostly miss :/
[deleted]