Unreal Engine is broken, why do people use it and like it?

[MostHost_LA]

@f35vtol

I get the impression that Unity engine is built by a community. While Epic engine is built by a small group of unrealistic thinkers…

Group of people that DGAF about Quality Assurance, Performance, or Regressions, before submitting a branch.

Fixed.

@Rawalanche
Steve Jobs: an origin story.
Nice, right down to the pickaxe.

Let’s be serious here. The problem is this engine, not the other stuff.
The other stuff you have to comply with for people to be able to use your engine or play your game.
coding a c++ game while making your own rendering pipeline is totally possible. Perhaps even better.

The point of using an engine is just that someone else has done this “tedious” parts for you.
You can jump start a project and work on what is needed instead.

The problem is that Unreal doesn’t really offer those benefits at all. You mostly just have to reinvent the wheel to go around the issues it makes for you.
Which also means you have to waste tons of times in learning about the issues. Smashing your head at them, understand them, and then solve them.

You don’t have to literally fight against any other engine I have ever used.

[Frenetic]

For me, this ^^^.

The one issue I DO regularly have is some kind of memory leak (or apparent aggressive caching hoarding of RAM) where the RAM footprint of an editor session keeps increasing. ULTIMATELY it will run me out of RAM, but rarely have I had it crash on me otherwise.

As for gaming, yeah, I’ve had to learn how to really get the most out of it, but I’m lovin’ it.

[Rawalanche]

It seems to be more of a subjective experience rather than the truth. For me personally, Unreal Engine has done all you are saying. They solved rendering for me, material creation and editing, particle systems, physics, editor environment for advanced level assembly, node based scripting language, and much more.

I can’t even imagine doing all that myself at anywhere close to such quality. Especially not in a single lifetime. And especially not if I also wanted to use it to make a game in the end.

The only thing that requires a little bit of bending is the game framework, but people keep forgetting it’s a choice. You don’t have to use it and can make it all yourself using your own base actors just placed in the level, as you’d do in other engines.

Insanely, I get to use all that completely for free, not having to pay a dime until I exceed an earnings bracket that I could never even dream of.

I’ve tried other engines, but none ever came close to how many problems they’ve solved for me compared to UE.

If you loathe UE to the point you are willing to say that it “doesn’t really offer those benefits at all” instead of something more realistic, such as “it doesn’t offer all of those benefits at the level one would expect”, then why are you still here? I am a bit confused…

[MostHost_LA]

What’s confusing about this engine being a total pile of as of .22 and upwards?

Who said “I’m still here”? All my important projects were jumped to CryEngine months ago.
And it makes Epic look like the QAless chumps they are.

Unfortunately, knowledge acquired about this pile of is nearly unforgettable.
And there’s always some hope that epic finally decides to hire someone competent enough to finally add a proper QA pass to the releases…

Of course, that would literally mean that everything past .18 or so has to be scrapped and re-worked… so the egg heads above him would probably say “no”.

Ue5 was their chance to do this.
They failed miserably yet again.

Epic as far as a company has quite possibly the worst track record in existence with a LOT of things.
Client satisfaction, Community interaction, taking feedback, taking bug reports.
Etc.

You don’t have to go far. They sue little kids for cheating at frotnite. They steal other people’s stuff and get sued for it too.
They pick (arguably rightful) fights with Apple over distribution rights so that the future of your project on IOS is in constant jeopardy. Shall I go on?

You saying that “for you it solved all the problems” means that you have never even attempted to release a game to date, or that all you built was some candy crush clone that can barely run over mobile.

TL:DR
If you are ok with Mediocre Unreal is a good engine.

If you are looking to make real project (the revenue of which would exceed the free licensing in a minute) then unreal is not the right engine for you. Or anyone.

It’s not by chance that game companies make their own version of engines…

And with regards to your comment

@Rawalanche

I can’t even imagine doing all that myself at anywhere close to such quality. Especially not in a single lifetime. And especially not if I also wanted to use it to make a game in the end.

You do realize that this is exactly what most game companies due all the time right?

Source, source 2. Halfle2 to Dota2
Naughty dog engine
Anvil
Foundation

I could go on. Basically almost every engine is made specifically for a game.
And/or had development directly coincide with a game.

Just because that’s not something you are willing to do, it doesn’t mean that you would need more than one lifetime.

[jwatte]

If a metaphor is allowed:
Unity might be like the Ford Taurus of game engines. Well known (at least in the US,) reasonable second hand value, easy to find a mechanic when it breaks.
Unreal might be like the Lamborghini of game engines. Very fast, very sexy, but breaks more and harder to fix when it does.

Now, is the argument that a Taurus is the right car for everyone? I think that would be a dumb argument. Different people prefer different cars. Different developers need different engines.

And, honestly, I feel Unreal Engine 4 is more like a BMW – maybe less reliable than a Toyota Camry, but not at the trouble level of the Italian supercars. For that, you need the pre-release UE5 download

[MostHost_LA]

Godot seems pretty solid to me.
Of course you end up having to do most things yourself - but for my projects that was the case with unreal too, so it didn’t really matter.

BTW, when you folks up there in the wee early posts say “photorealism”…
Do your even realize that currently if you shadow 1000 cubes you get 14fps or so? (~2k 1080ti overclocked)

Those cubes have 6 faces. Each face has 2 tris.
Do the dman math!

Assume that a half decent (speedtree) tree has likely 1500 to 3000 tris.

How many trees can UE4 support before you can right click the project folder and just delete it???
(2ND Grade level algebra right there).

Now go off and do 1000 lit cube test across the other engines.

Based on that, you know which one has a better baseline rendering thread.
(Which could mean nothing at all if your settings for the initial tests are off too. The scene / pp stuff and engine setup have to match. Don’t go testing raytrace on ue4 and comparing to regular render in unity for instance )

[jwatte]

@MostHost_LA

Do your even realize that currently if you shadow 1000 cubes you get 14fps or so? (~2k 1080ti overclocked)

There must be some other assumption in that statement, not stated.

Assuming you use shadow maps, the number of objects almost doesn’t matter at all. Maybe if you simulate them all, and they all are close to each other, and you run in debug mode, physics will suck up a lot of performance? Maybe if you create a separate material for each of them, rather than using a material instance, the state changes end up costing a lot? I bet if you tesselate each cube three times, making 128 triangles per side, instead of 2, you will see almost no change in fps – it’s very unlikely the triangle count is the actual problem.

But, as I said – for that number to mean anything, a lot more variables need to be controlled for. (You mention that that needs to be done when benchmarking against other engines, but I’d like to see what causes 14 fps for you.)

I put together a simple scene – a ground box, 1024 boxes, physically simulated, with cascade shadows on them. (I’m using Force No Precomputed Lighting, in 4.26.2)
This scene runs in 2k in the editor at 90 fps while the objects simulate, and 120 fps when the objects come to rest.
I didn’t even package it up – clearly, something else is going on in the “14 fps” number.

(Yeah, when the editor is switched to the background to take a screen clipping, the FPS is ■■■■, as can be seen – you’ll have to trust me it runs at 120 fps )

[jwatte]

I packaged it up and ran it on a 1440p GTX 1080 Ti. Ran at smooth 60 FPS – the display there doesn’t go faster, and I didn’t bother to turn off vsync. GPU load was ~70% according to nvidia tools.

[DomusLudus]

Many times the problem is that you have not chosen the correct engine for your game and of course the fault is not yours is the tool, an inert and lifeless being.

So this type of post always falls into some of the following categories:

1. The game you are trying to make is beyond your capabilities.
2. You want to do a pong and you don’t need the framework. (Even if your game has a game mode, players, a camera, and a controller)
3. Unreal does not use C #.
4. Your computer is a coffee maker that doesn’t even move paint.
5. You want to make a huge open world.

[MostHost_LA]

Assuming you use shadow map

No. No shadow maps. Games, so fully dynamic.

Maybe if you simulate them all, and they all are close to each other, and you run in debug mode, physics will suck up a lot of performance?

Actually no.
Neiter chaos build nor PhysX from launcher have physics issues with simulating 1000 cubes. (Then again I’m on an I9, I wouldn’t really expect a performance issue on the CPU side).
To test it, turn off shadow casting on a directional light.

Maybe if you create a separate material for each of them, rather than using a material instance, the state changes end up costing a lot?

No. But they aren’t supposed to be instanced. Ofc, isntancing would cost less.

I bet if you tesselate each cube three times, making 128 triangles per side, instead of 2, you will see almost no change in fps – it’s very unlikely the triangle count is the actual problem

No. Not with a dynamic lights. The cost is Per tris, per light. So more tris = grinding halt.

I don’t think I had anything particular going on last time I gave this a whirl.

Standard 3rd person template. Pop in a cube. Set to simulate physics. Set Movable.

Alt drag to make copies up to 10 vertically.
Alt drag to make 20/30/40 so on up to 100. Place them a bit randomly if you will.
Select all then alt drag them all to make 200/300 etc. To 1000

Randomly placed each time and with overlaps to cause physics to you know, atrually test. Given initially chaos was doing very poorly with high numbers of simulating bodies.

No need for forcing no precomputed light on it either, the cubes are movable.

I doubt I had other windows open, since it was so bad I filmed it last time, closing all windows is the first thing I’d have done…

And yes it was obviously very bad and just due to the shadows.
Disabling shadows jumped right up to 120fps.

Either way, no other engine reacts so poorly in dynamic lighting situations for simple cubes so far.
And .20ish didn’t bat an eye / ran over 80fps np problem on all those stress tests way back when.

[DomusLudus]

But unreal 3/4 has never been for those parties of lights and dynamic objects, it has always been for rooms (even with trees and rivers) and ligmaps, that’s why CryEngine maintains its niche for open worlds.

[jwatte]

@MostHost_LA

No shadow maps. Games, so fully dynamic.

There’s something about words here.

Light maps are static. Shadow maps are dynamic. They’re the “SM” in “CSM,” for example.

The cost is Per tris, per light. So more tris = grinding halt.

That’s not what I’m seeing. Changing the cubes to spheres has no impact for me.

[quote]no other engine reacts so poorly in dynamic lighting situations
[/quote]

And neither does Unreal Engine. There’s something different between your scene and my scene.
Run it yourself: https://watte.net/SimpleShadowTest1000Cubes.7z [132 MB]

There’s no precomputation here – there’s an actor that spawns 1024 cubes in On Begin Play, offset a bit so they actually do the bouncing-arounding thing.

Edit: Actually, I updated it all to be a little more packaged, for anyone who’s interested and want to benchmark themselves. I updated the executable above, and also, here’s the project (all blueprint):
https://watte.net/SimpleBenchmark_UE4_26_20210911_Project.7z [63 MB]

[anonymous_user_f7db3d16]

Back 10 years ago we had issues with dynamic shadows not culling out like they should, it showed them culling but in reality they were not being culled and were being drawn when they should have been culled out. That was causing terrible fps. That was with speed tree dynamic shadows NOT CULLING so we quit using them and turned our trees in to static meshes and put them into the foilage editor to solve that issue. If you set it to cull at whatever distance you will see it looks like they are culling at that distance, but everything that is not showing is still being rendered you just do not see it, basically what we came up with was lets draw all shadows complete a the way out even if you se them culling at 500 they are not. It is still drawing everything all the way out. We did some tests way back (10 years ago) to prove it.

Is there still a dynamic culling issue going on?

How we tested that was turn on all dynamic shadow all the way out no culling, check the fps , then set it to cull at 500 check your fps is it the same or did it get better with culling? ours stayed the same. we had same fps wether we had culling on or were drawing all the way out. Told me that they were not being culled. turn them off completely watch the fps go thru the roof.

[jwatte]

Is there still a dynamic culling issue going on?

My scene has all dynamic shadows (shadow maps, cascaded shadow maps.)

[MostHost_LA]

Edit: Actually, I updated it all to be a little more packaged, for anyone who’s interested and want to benchmark themselves. I updated the executable above, and also, here’s the project (all blueprint):

I’ll give it a whirl.
Just re-installed my work rig, so it’ll take a bit.

Maybe it’s because of how they are spawned under the hood that you get better performance?
Instead of instance copy/paste?

And yea, I red that as baked light map rather than “shadow maps”.
Doesn’t really change too much in the sense that the items being set to movable prevents the light from baking anyway so I guess it’s a moot point.

That’s not what I’m seeing. Changing the cubes to spheres has no impact for me.

There’s a starting cost for the initial render, and an additional to every tris. It’s not a 1:1 ratio (though according to epic docs it seemed like a direct ratio.
I read this just last month and I can’t find the in question via Google, so It was likely edited? O_o)

Also performance wise Directional Lights and PointLight have some wierd differences.
If you were to make your pointlight large enough to shadow all items the same, you’d expect same coats. but it’s not so… because you know, unreal consistency?

My scene has all dynamic shadows (shadow maps, cascaded shadow maps.)

You also aren’t really looking at all the spheres. There’s maybe what 100 on screen and most of the rest is culled out and/or has no need to render a shadow?
Freeze rendering and see what was actually being computed.

Perhaps the difference was that, the way I test it all the cubs are on screen at the same time, there’s no culling involved at all.

Either way I’ll give a look at your shared thing.

Is there still a dynamic culling issue going on?

I’ll give that a whirl too.

There wasn’t one in .25
Basically setting the CSM to something stupid small (1.5m? I think?) Was the only way to get around 60fps steady on a heavy scene.
But the distance range was definitely affecting performance, so if now it’s not that’s a regression.

[Zeblote]

Getting very low fps from many shadowed objects can mean that you just configured your light incorrectly. Have you set your directional light to movable or stationary? If it’s stationary, make sure the CSM distance is not zero and inset shadows for movable objects is disabled.

[f35vtol]

Have you seen how sexy and fast Unity HDRP with RTX really is? Makes me think of Unity as like a 800hp Subaru STI against your Lambo. Boils down to the skill of the driver. But a Subi costs way less, and maintenance is easier…

[jwatte]

@MostHost_LA

There’s maybe what 100 on screen and most of the rest is culled out and/or has no need to render a shadow?

I was absolutely looking at all of them at the same time. They’re slanted on spawn specifically so I can see all of them. Not to mention: The shadow map cost is based on culling from the point of view of the light, which, being a directional light, sees all the objects. Objects you can’t see (because they are behind other things,) still can cast shadows you can see, so the engine can’t not draw those objects in the shadow map.

The very clear correlation was “number of physics objects simulating” versus “frame rate.” With all objects simulating, it was at 80 fps or so, when all of them come to rest it tops out at the rate of the display.

Number of triangles is a very weak correlate to performance on any modern graphics in my experience – all the cost is in the setting up / coordinating the drawing of each “batch,” and the graphics cards are just SO GOOD at drawing triangles within each “batch.” Especially if the triangles cover the same number of pixels in the end, most typical game scenes will not be triangle count limited. (And then, with Nanite, that becomes double true …) (But then, “typical” varies for each creator.)

[bitcloud1]

It’s brilliant, but it’s oh so broken in oh so many ways.

Some things are just insane, like autokey not working. Fundamental things. Nanite is cool and all, but if your basic UI is broken, if basic things like duplicating a map and having the ability to actually duplicate dependencies etc isn’t there, then whats the point?

It would be great if the next release was IDENTICAL to the last release on features, but just a complete consolidation of basic features. You only need to do things once to realise they’re broken. The man hours that go into everyone who uses the software going through the same nonsense over and over again is mind boggling.

[BIGTIMEMASTER (Aljav)]

@DomusLudus

You want to make a huge open world.

I can’t write code and I’ve started learning how to use unreal less than six months ago.

I have a game project that I tried to make in the other U engine but it was not possible to complete in that engine due to performance issues, both in build and in the editor.

Unreal and its robust blueprint system has allowed me to remake the game myself whereas before I had to hire a programmer. I’ve built it better, bigger, and it performs well.

Also, it’s a big open world with dynamic lighting and tons of foliage.

I like Unreal because it has empowered me to make games almost entirely on my own. It has mitigated the technical issues and the many thoughtful tools included in the engine make work fast and efficient.

I think people who have problems are probably having the same problems you’d have with any engine - trying to force it to do something it isn’t designed to do. Same problem I had in Unity - I tried to make it run a large open world 3d game. It just can’t handle that sort of thing. But unreal has been keeping me very productive and happy. It empowers me to be able to make the games I want to make with very little compromise.

For people who think the engine is broken I’d say you probably aren’t as clever as you might think. Because I’m a moron with computers but I am able to create non-trivial games without too much issue. Like, if I can do this - and I can’t even understand much of what is written in this thread - and you can’t, I’d question what sort of game you are trying to make and also if you are being disciplined about following common best practices or not.