UE5

When I look at Godot, I think about Blender.

But what I don't like is how it's funded via Patreon. It means the longer development continues the more money developers get, regardless of engine capabilities and achievements. Potentially they can keep the development for decades with no result to speak of, as long as the support doesn't drop. And it's a real possibility because countless patreon games do this already: infinite milking and almost no real results.

 

Right. I think THIS can sorta illustrate it.

Spoiler

And this:

Spoiler

This sort of look was around during that time, usually in unreal games.

* Details in the shadow are completely killed off and are pitch black.
* There's this red-ish yellow arcs/flames everywhere, which are bright but don't light anything.
* Pitch black surfaces glisten and often have emissive details.
* Things that do not glisten are sorta washed out.

During gears of war times it was even worse, because boosting contrast could produce "banding" in nearly black areas, which tended to be reddish.

Now, compare this, for example, with Kite demo.

Spoiler

Before the high contrast darkness phase we had largely ton of bright visuals with baked shadows, like this:

Spoiler

Those also had their own distinct look. Those were Unreal 2 titles.

 

That doesn't really make sense, though. There's always new stuff to implement, so that won't run out. And just imagine how many more people might back it with loads of progress to show.

"Milking it" by going slow doesn't make sense.

 

That's what logic says. But somehow it's not applied to many patreon games, which barely release any updates yet maintain stable, high income.

If I have to guess, it's because patreon support has nothing to do with achieving goals, but instead relies on a fanbase. And Godot has a very dedicated and passionate fanbase.

Of course bringing more features may (or may not) bring more people. But there is also human laziness: when you get 15K/month regardless of your achievements and it pays all your bills and then some, why overworking yourself.

I don't claim that Godot devs are lazy and slow down progress on purpose. But too many patreon creators do it, so I'm not holding my breath. I trust Unity and UE more because they get money when someone uses their engines here and now, rather than hopes to in a distant future which may never come.

 

Oh not imagination land at all. There are some nice documentaries where Cliff Bleszinski and so on discusses it. It was planned to include MMO features they started some work on the engine but it was cut. Pretty logical imho - we want the best looking game to be able to make outside terrain and moving sky, so our engine needs to have it ,so lets code it. I don't think these guys threw stuff at the wall and see what sticked. It's clear tat they wanted the game t o be something specific and they coded in features in the engine made it happen.

The "Unreal look" was there yeah but description of everything was brown was specifically criticisms of Gears of War iirc. I think it could have been that games made overuse of blooming.



As can be seen from the bottom ones it was capable of quite nice colors other than having a brown look.

 

It does, though.

Like ExtraCat said, this is a frequent occurence with certain patreon games.

The author starts doing a thing. The thing is rare enough to secure sufficient funding, say, it reaches 10k per month.
If we put aside morality and obligations...

Let's say you have 6 months of work to complete the "thing" and call it done. You could do that. OR. You can start postponing it and take it slow. Well, you can't really do nothing and expect money, but you can begin getting sidetracked on purpose. For example, you can start producing cosmetic items, artworks for patrons, start some polls, or invent a feature out of the blue that would require six years worth of artworks to get it finished.

If you do it right, you can stretch six months till completion into 10 years of funding.

 

I quoted and was speaking specifically to an engine, not a game. Games get finished (hopefully!), engines generally are ongoing.

 

Almost like all those apps with subscriptions.

 

The point is that in case of subscription model the developer doesn't have any incentive to actually get things done. Only to maintain enough interest to keep funding flowing in.

 

Assuming they're not interested in increasing the funding flowing in, sure.

 

Well increasing the funding flowing in doesn't necessarily mean progress on the engine. It can mean services or subscription fee increases, or simply not adding features if there is a store where said feature can be obtained in some form.

 

Very interesting discussion, each engine has his pros and cons I think.

After using Unity for more than 8 years and a little frustrated by unconsisted and unrealeased features (Garry's mod blog says it better than I can ever do it....) I gave Unreal Engine a try for a project and spent about 8 months developing in it using Blueprint and C++.

Unreal is way more stable and updates are consistent and meaningful, on the other hand iteration in C++ is really slow, and blueprint is fast but messy especially when your project reaches a level of complexity.

My team and myself ended up porting the project in Unigine Community last year, I wonder why no one ever mentions it....

Pricing is similar to Unity (unless you want 64 bit precision, which Unity does not have..), you can code in C# or C++ (much cleaner than Unreal C++) , excellent developers support and graphics comparable to Unreal...

I am not here to start an engine war (we had enough of those...) but just seeking an honest comparison from fellow developers and reason why people never consider it ...

thanks
Fred

 

Depends on platform targets - Unigine simply doesn't support what I want. In any case Garry seems to be saying the same stuff as me only less polite haha!

In any case, people here should not really be commenting unless they've proven their competence with the following quiz: https://garry.tv/unity-quiz

 

Last time I checked it supported only Windows and Linux. If it suits your goals, it's fine. But even Ren'Py supports more platforms.

 

For people getting their funding via Patreon?

I've considered it, multiple times. The only thing that's kept me from using it for projects is a lack of support for specific target platforms.

 

I agree on limited platform support (we are targeting windows), Unigine clearly stated they are not targeting mobile but hight end devices....they mentioned support for consoles (Xbox, PS5) next year...

 

Interesting to hear about Unigine and your experience Frednaar.
There is also NeoAxis and Flax Engine now that the engine can was opened
Flax Engine is interesting since it has Auto LOD, Visual Scripting and exports to consoles and Android.

 

It's obvious that for unity the real pro tier deal is buying the F***ing source code, all these top tier made with unity game have insane tweak under the hood. It's misleading to the same scale than unity demo who use the engine as a glorified viewer of data made outside the engine, or need source code tweak anyway.

Nanite seems to be a fantastic occlusion engine if you don't need the bazillion micropolygon and just stay low polyish.

Also i retract my comment on foliage, why the hell you need alpha card when you can instance fully modeled leaf with bazillion polygons to have actual thickness? It's a paradigm shift we don't need alpha cut out hacks anymore.

 

I dont think nanite is supporting common techniques used to make wind animations, and other shader tricks necessary for realistic foliage.
Not yet anyway.

 

This is the sole reason I just can't stick with unreal. Get an idea and have a blast rushing it together in blueprints. Realize that it's getting complex and you have no choice but to move to c++. 20 open browser tabs later figuring out how to do whatever in unreal c++, back to Unity I go.

 

The answer to that is called Rider.

 

You'll end up in the same situation if you try to do something very non-trivial in unity.

 

I have visual assist I'm refering more to the wonkiness of the entire unreal api.

Take string you have FString, FText, FName and depending on what you are doing you have to convert back and forth depending on what api you happen to be using like blueprint function or umg function. Love all the magic methods like getreplifetime. Have you ever missed adding a variable to one of those magic methods? No error no warnings just odd behavior that shows up down the road.

 

It's not just a visual assist. It actively guides you through UE API and makes up for the bad documentation. It actively warns you against bad practises and tells you what you should be doing, which is far from visual assist.

It also patches up all the problems you'll get with headers and blueprint integration, specifically. Basically it solves all the problems you are mentioning.

 

Just started checking out Unigine the other day and I'm genuinely impressed with it. Coming from Unity I instantly felt at home in it and could start creating scenes with ease. I feel Unigine is what Unity should have been by now - things just work out of the box, no hassle, great looking graphics and simple to understand.

Can't comment too much about coding in it as I've only touched on it briefly, but of what I saw I liked it.

 

I created a some tutorials for Unity users back in october...maybe you can find them useful... search Unigine for Unity developers on youtube...

 

That's awesome! I added to watch later. I'll have a look at them later today.

 

That's just the platforms the editor runs off of. For builds Unigine supports Windows, macOS, Linux, Android, iOS.

 

It's not wonkiness at all

FString is a standard character-based type, very well written.
FText is a type supporting localization out of the box. You don't have to think that much about localization if you're using FText for all data which needs to be translated later on. It's useful to get some extra localization plugins/services, but that's for convenience. The engine itself provides an entire basic workflow for localization. It's all thanks to FText type!
FName is the most optimized character type which should be everywhere you don't localization (FText) or operation on strings (joining a few strings together, etc.). FName is basically a pointer to string, so comparing to FNames is super fast, unlikely to slow string comparisons. This what should be commonly used by systems, especially if used as identifier.

Having these 3 types is a godsend!
Usage of these types don't depend on API, but on use case

I'd recommend reading/refreshing a bit of documentation to understand string handling better
https://docs.unrealengine.com/4.26/...ingWithCPP/UnrealArchitecture/StringHandling/

 

I've used UE4 quite a bit, followed a bit of tutorials (C++ and Blueprints) and never knew this! Such useful advice. So here's what I've gotten out of it.

FName is similar to a const string, useful for keys/tags/layers which don't need to be manipulated.
FText is useful for strings which need to be localized or formatted. FText comes with all sorts of localization and formatting tools out of the box.
FStrings are more costly to use, but allow you to manipulate them by standard procedures, like concatting, lookup, array indexing, string building, etc.

I agree that this is much more useful for game scripting than general application building.

I'm curious if Unreal Verse is going to be a good scripting solution that's easy to use and have strong IDE support like C# does.

 

Does Unigine even support consoles? A quick glance at their website shows nothing about that. For an engine that has been on the market for so long, not being able to port for consoles is a big deal breaker.

 

Nothing current.

 

To understand if Unigine is good for your project you really have to consider his strenghts and weaknesses...

It is not a generic do it all engine, the engine is originally a simulation engine that recently moved to the game engines world last year.
It's strenghts are very good performance on open world games and huge landscapes, very good physics system, rendering quality and VR (I know of a few projects who also moved from Unreal for this reason) . There are about 50 developers in the company and part of them is dedicated on improving the game aspects of the engine but it is still a work in progress...

The UI system is workable but they are creating a new one (should be in prerelease this summer), material editor is in alpha, console support will come next year.

Code wise it is very similar to Unity, using Components (Monobehaviors), but you can also code in the main loop ( I use that for general game code like UI, gameplay, etc...) It is also quite easy to import assets from Unity or Unreal asset store, and also Unity code with some adjustments.

if you want to have a look at how a very experienced coder uses it (in C++ but you can easily transfer to C#) check out this youtube channel. This guy started his project creating his own game engine in Rust, but then moved to Unigine...

So if you have a strong experience in Unity and don't have those requirements I see no need to consider it. In case you want something very good for open worlds and with a more linear path to the future maybe check it out...

 

Yeah I have, it's not for me. Unreal or Unity all the way, both are good in their respective areas. Unigine is way too far behind in nearly everything that matters to me. I do like their features but the features are more heavily paywalled than one might think, since Unigine's strength is vast distances and you don't get that without stumping up good cash

I'm fairly convinced it's still targeting businesses not games.

 

Interestingly, while I agree there may be a specific Unreal look, I've started to notice the same thing with Unity - namely a sort of hazy, washed out look that lacks crispness and a sense of depth.

Here are a few examples (and all of them are by well-established studios so it's not a case of beginners not knowing where the post settings are):

Spoiler: Examples

Rebel Galaxy Outlaw:


Hardspace Shipbreaker:



System Shock Remake (before switching to Unreal):

 

The name is remarkably similarly close to Unity Engine and Unreal Engine.
Is like word twist, but mimik writting and pronounciation is purposely close to any of both existing engines.
Whether it was smart choice of naming, I think gives field for both Unity and Unreal, to play against the name, if they really want to.

 

I googled up Unity first release (June 8th, 2005) Unigine first release (May 4th, 2005) so it could go both ways ...

 

I heard a long time ago that UE3 tonemapper was adjusted to the limited color space on Xbox 360. Video output of that Xbox dictated a lot in terms of colors and gamma.
I don't remember details, probably you'd understand such issues better than me. Just found some old threads like this.
https://www.avforums.com/threads/is-it-true-xbox-360-uses-a-different-rgb-color-space.1699103/

When we're reworking The Witcher 2 for Xbox 360, the final result was the quite vibrant/juicy colors. But... the entire game lightning, post pro and engine were reworked specifically for this console. And that partially to mitigate Xbox 360 "color output".

 

I think these engine "looks" isn't so much a core engine limitation. More of a people following people thing + finding hacky ways with post to compensate for some rendering problem they don't like.

The crushed blacks and too much bloom - that's got to be just an artistic choice, right? It fits the tone of the Gears games, you can set up post process to create that look in five minutes. Gears was a big success, so others follow.

And too much bloom in unity games, no doubt people are trying to make up for the poor lighting and plasticky look of everything? There seems to be a trend right now to overuse depth of field. Again, you make half the screen blurry, technically it can add sense of depth and a cinematic tone, but the real thing is people are just hiding things they are insecure about.

 

Problem is UE4 and UE5 look rough without their post effects chain and lighting. The moment you start picking and choosing in Unreal land is the moment it looks bad, because to get their visuals, it's a package deal. The heavy post tidies up many core shader and engine decisions and indeed is designed to.

That's really good if you target the generation of consoles for the feature set, but is inherently not a great engine at scaling things while Unity is better at pick and mix.

 

I can experiment with this by turning off post, but what do you mean without the lighting? How could any scene look without lighting? That's what defines what you see, right?

 

I guess with Unity, the difference is that there is no post by default to tidy up the design decisions?

I'm not convinced Unreal looks worse with post disabled, in fact my best guess is that the main differences lie in the performance optimizations done in Unity shaders and lighting - although this is just my speculation.

 

The shaders do not cause artefacts so much in Unity land, and are designed without many of the advanced features that would require some form of post to fix. It is the right decision for Unity currently.

 

You know....

If there's a freely accessible unity scene that isn't protected by "unity only" license, uses internal render, then I could feed it into converter and show what happens to it. Here's an old test:

Spoiler

I used viking village for internal tests at some point, but I believe it is "unity only" restriction, and on top of that it has been removed from asset store.

Last time - that was a few years ago, mind you - when I was transferring assets from unity to unreal engine, the impression I got was that Unreal (at that time) was much more picky to texture quality. Turned out that the author of a kit the project used was lazy and ran the base textures through photoshop filter and called that normalmaps. It sorta worked in unity engine, while in unreal it was instantly obvious that something is very wrong and the textures are sorta flat. Additionally the scene itself had that gears of war look by default, plus Lightmass was sorta inferior to enlighten in terms of quality (no bounces from emissive textures, IIRC).

HOwever, back then post processing made a huge difference, because you could make anything GLOW and affect bloom, even including particles.

That's, likely, one of the reason why Unreal games used to stuff that glowy lighting sfx everywhere.

P.S. I don't feel like there's a ton of optimizations going on in unity land, to be honest.

 

Can you describe what advanced features Unreal has that require post processing to fix artifacts for?

While it's entirely possible that Unreal's shader, lighting and post processing conspire to fix eachother's faults, it seems clear to me that while Unreal's rendering is capable of looking like any of the other professional engines out there, Unity's is not (or at the very least, it's very difficult to do so). All one has to do is look at Polycount or Artstation to see this.

But anyway, I don't want to derail this thread, I just happened to realize that that there was a distinct 'Unity look' even in professional examples, that may or may not be difficult to change. It's something I hear UE accused of as one of its downsides, but it seems Unity has the same issue.

 

Interesting to see that video. Whether it's the settings or something internal to the engine, they look very different. The problems look almost opposite - Unity has too much specularity and UE not enough. There is also a wild difference of contrast.

 

They have sharper texture aliasing/bias/sampling which causes artefacts without heavy temporal antialising to fix it. You can test it in-editor, and read up online about that.

As there is no baking for nanite right now, it means also you don't have a choice but to use lumen and that heavily is tied to post effects too - everything depends on everything else to get the results you see on those amazing videos. Make no bones about it - UE5 is for next gen consoles only for now. I can see it changing but this is an EA engine and they have said so. It's what it is, and when you want to change what it is, that's when you will hit a substantial amount of work.

 

Huh? If you forgo postprocessing in UE4 you basically get what you get out from Unity built-in in PBR (aka, something that looks 10 years old), except the lights in UE4 have proper falloff behaviour. Not sure what you're basing this on.

Unless you mean Unity defaulting to gamma space and looking like 2005 era games by default.

Or are you referring to the UE4 features which depend on TAA to look correct (like the SSAO)?

 

Correct. There's some mention of forward+ coming to URP but you should not pick Unity for having the latest and greatest, you really should pick UE5 or even UE4 for that.

But Unity's biggest strength is realised when a developer sits down, and asks a simple question:

What can I do today?

It is so easy to be swayed by what-ifs, what is coming and even early access engines. But really, if people want to enjoy a productive development cycle with Unity or even Unreal, they need to forget roadmaps and look at what what is available and finished today only. Ignore roadmaps, they are the worst thing any dev can look at, in any engine.

 

The docs say baking support is coming for lumen at some point (interacting with baked lighting) and based on how nanite works it shouldn't take too long for it to get lightmaps support too.

The minimum GPU architecture requirements for both lumen and nanite are AMD GCN and NVidia Maxwell, so support for last gen consoles and Switch is likely in the works already. Not sure lumen will run well there, but the nanite performance boost for "standard poly" meshes is definitely beneficial for those platforms.