UE5

Unity doesn't even need Nanite. It would just be nice to have any mesh decimation and a billboard generator (a smooth 3D one like Amplify Imposters) built-in to the engine. This didn't work well the last time I tried.

 

I could open ue's demo project on my computer smoothly and quickly, play with everything while the shader is compiling AT THE SAME TIME. But open such a demo in unity will surely take a whole day and I can not do anything at all...

 

Unity doesn't need fancy tech, it needs to focus on being a cohesive editor and easy to use with reliable features.

I can't believe this is an area that Unreal seems to have pulled ahead.

 

That's an absolutely fantastic response chaps. I've been reading some of the replies and I won't even pretend to say I understand what's been said. I feel blessed to be part of such a learned community but I do feel unity is where we belong.

 

I tried installing 5.6 yesterday, and man ... it really underlines how slow the editor has become. The constant time wasted on blocking popups is driving me nuts.

I do hope this is their takeaway, should the devs read this tread. People didn't flock to this engine due to cutting edge tech. Chasing that wild goose puts them way behind, and in the process throwing the one advantage they did have.

 

All Unity needed to do was add incrementally to the framework they had already built. More features to the system everyone liked, built carefully.

Alongside Mecanim could have come a character creator, a cloth system, an input system, a realtime GI system, an LOD system etc, built right into the engine, fully supported and documented, there to either stay or get fully replaced at some future date in an entirely new version of Unity.

But no. Take the UI text for example, first came UnityEngine.UI.Text. Instead of building on that, they throw in TMPro text out of nowhere. As soon as people get used to that, no it's still not the right answer, now we have UIElement.TextElement. There are literally three different types of text floating around in the engine, there is no convention for which one to support for asset devs, and each one is in a state of perpetual uncertainty as to its future.

That's just text though. How about the render pipelines, of which there seem to be innumerable versions floating around without any ability to work with each other, spread across several different versions of Unity - inextricably tying the support for a specific version of Unity with not one version of the pipeline but a whole range of versions frozen in various states of development.

The main thing that the package manager seems to have enabled is the ability to develop features completely out of sync with the core engine development, without needing to plan ahead and be sure about whether they are a good idea or not. I think this approach has destroyed the Unity development culture that existed before, where everything was done right or not at all, and where the final, polished product was elevated as the goal above everything else.

If it wasn't for Unreal's example, I might have believed that development speed and polish was a tradeoff, but I find it hard to believe that Unity could not do three quarters of what Unreal is doing while maintaining the level of quality, consistency, and supporting materials they did before.

In any case, with the fast and loose approach that Unity have now, one would imagine that they could at least beat Unreal in terms of speed of development of new features, but it's not even close to happening. So it's not really clear in what area Unity is attempting to excel right now.

 

For me UE5 early access in May shows that they can be trusted in their announcements.

Unity is a coin flip and now after being publicly traded it may get worse. Dots netcode post from 2019 is the best example:


I still like C# more than C++/blueprints but is it enough to keep using Unity?

 

Fully agree with your post, but to add a bit to this point, it seems Unity is allergic to iterating on features. Once a feature reaches v1.0 it's done and it has only the most basic of maintenance done to it.

I used to think "this looks promising" when I tried a new Unity feature that had some issues. These days I think "Oh, it's going to be like that forever, huh?".

 

wow, hope no one took that diagram seriously.

 

UNITY DOESNT NEED X, BECAUSE I USE Y

 

Yeah, except that as soon as the package manager comes along, things like the render pipelines just get broken left and right like it's nobody's business.

My opinion is that Unity should release a new version every 2-3 years, each feature should be major version locked to that version of Unity and polished right up until the next cycle arrives. That way everyone knows that everything is dependable for at least several years.

In the space of a few years, we have Unity 5, Unity 2017, Unity 2018, Unity 2019, Unity 2020, Unity 2021. Each one with their own drama. I'm not particularly familiar with Unreal's development cycle, but it seems UE4 came out in 2015 and now six years later UE5 is coming out. Did they add and remove things in the meantime and pull everyone around? I don't know. But I'm guessing that part of what allows Epic to develop in huge steps like this is the separation of versions. And it allows them to commit to things, work on them for years (I think I heard nanite has been going for a decade) polish them, and release them to a very good quality.

I honestly think that Unity's current development process is to blame for the state that it's in. Not just the fast version cycle but the package system. It's too easy to start something new every few months or every year, make a big announcement, quietly bin it if it doesn't pan out, and move onto something else quickly when excitement dies down. It's resulted in not just a lot of new ideas not being fully realized, but also apparently things are passed around and iterated on in a haphazard way as departments are always reorganizing around new things.

 

UE Still adds major features between versions that aren't point releases. Major: (4.10 > 4.11 > 4.12... 4.25 > 4.26) and so on. With each getting some hotfixes (4.10 > 4.10.1)

UE4 > UE5 is actually fairly 'relatively' easy to upgrade your project to, as long as you're using a supported UE4 version (currently 4.26, and upcoming updates will be supported as well)

Compared to UE3 > UE4 which was much, much more work. (more breaking changes)

 

Unreal is more likely to perform destructive updates that will break C++ code than unity. In unity if you pull code from version 5 and launch it in versio n2020, chances are it will work.

In unreal if you're trying to do something with skeletal mesh generation, for example, it can be broken during point release, because you relied on a fairly deep functionality, and it got refactored.

 

As opposed to Unity where if you have an issue with a feature, they tell you that one’s deprecated, use the new one. “Technically” there’s less breaking changes but the pain is actually worse.

 

And then you do the right thing and ignore their advice completely and live happily ever after? I mean if it still works then it is not deprecated enough.

In Unreal 4, a plugin crash kills the editor outright.

So, let's say you have a subroutine in a plugin where you generate a skeletal mesh by hand and feed it into the engine. In a version 4.X.Y. it works, but in 4.X+N.Y it crashes the editor the moment the mesh arrives on screen because someone combed through the codee and changed SOMETHING 15 levels deep into the rendering part which is quite non-trivial to understand, and in order for the skeletal geometry to PROPERLY generate its rendering counterpart and stop crashing, you have to do some unknown action, because, apparently, in case of other editor code is pretty much generated by an unknown module asynchronously through means mortals aren't meant to know. And your code does not trigger the benevolent rendering structure generator because reasons.

So.

Works in one version, doesn't work in another version. A fix requires unknown interaction with unknown module, which is not documented anywhere.

This is not fun at all.

 

Fair enough.

Like @AcidArrow mentioned though, it's one thing to break code on a fairly short interval, it's another to introduce and deprecate features on the same cycle. It's hard not to break code here and there when you're working on improving something. But abandoning the feature entirely, introducing a different concept, or leaving it in limbo is something else.

I do think Unity have a bit of an unhealthy perspective on breaking changes. I've seen people point out obvious problems only for Unity staff to say "imagine how many games would break if we did that" and then we've got the render pipeline thing.

That's why I think engine versions and major features should run on a cycle of a few years, because that way you get relatively small breaking changes and plenty of polish in the interval between, and then a big break when a new one comes out - which is relatively fine.

 

Basically everyone wants Unreal's way of working but Unity's ease of coding.

 

I think it all boils down to trust really.

Unity lost the trust because they started working in a sloppy way and not being consistent. I dont think anyone here really cares about nanite or lumen - but Unreal is showing consistency and delivers on things we all care about.

 

Unity did move from 3 "major" releases / year to 2. Which makes a lot more sense and is already providing dividend in terms of stability and bug fixes. We'll see but at least they are moving in a better direction IMHO.

 

I agree, IMHO it became a train wreck after 5, and my output and publishing of games dropped dramatically as a result. This is my fault because I trusted what I was told.

Basically I lost a lot of productivity because Unity changed around that time.

Basically, Unity's a great engine but don't be charmed by anything that isn't 100% complete. Unity has made some progress by hiding preview packages and tying packages to editor builds more tightly so there's some form of stability.

However should epic create a decent scripting language, or support C# natively, it will cause a lot of users to migrate.

 

As someone very invested in Unity with my main game Tabletop Simulator being developed on it starting with Unity 4.3 back in 2013 (now on 2019 lts). I complete agree with the frustration you all feel. Rendering, Dots, Networking, UI, etc all seem to be in limbo. I also agree these woes all seem to line up with when Unity went from a perpetual license to subscription model after Unity 5.6.

New CEO, plans to go public, recurring revenue, and turning everything into a service all explain the madness we are currently having to deal with. If Unreal had any typed scripting language other than C++, you likely would never see me posting on these forums lol.

 

Lumen I do care about, nanite a bit less so. Baking lightmaps is a pain.

 

I mean they are really interesting to me because most my game projects have pretty large world and realistic style graphics, and I will be messing around with them once I get to art production in my projects, but I make an assumption the average indie doesn't care so much about these things because their games are smaller.

Baking lightmaps though - that is still going to be a much more performant option though, right? I mean Lumen might be better dynamic lighting but its still dynamic lighting? I dont know I havent read anything about it.

A lot of artist seem to think with nanite now they can just throw zbrush sculpts into engine and be done. Not gonna be the case. And there is still no reason to use more resolution than you need. Same idea with lumen but again, I havent read anything about it - maybe it is more efficient than even having baked lights.

 

Resolution of meshes is easily dealt with, it's not the main attraction though. It's just a nice perk for film. The main attraction is the fact you never need to make optimised levels beyond that. You don't care about LOD or even polycounts beyond file sizes.

It's much easier to work if you kitbash the entire world and it runs 60fps on a 2070 with realtime lighting and GI.

The real problem is making enough art to begin with. If you use Quixel, it means your characters and buildings and vehicles or whatever else has to match that fidelity or look like an indie car crash.

 

Not sure, I haven't tested just yet. But I'm guessing it does a good job on PC. It seems lumen doesn't work for VR though.

Regardless, baking lightmaps and baking models are definitely two of the most time-consuming parts of game dev. If there's a cost to avoiding it that's acceptable, it might cut an insane chunk out of game dev time.

 

Unreal also has screen space global illumination, it comes with SS limitations of course, but it's a nice alternative to the more expensive Lumen.

 

Epic are deprecating a lot of raytracing and SS features because Lumens is actually better and faster, running on non nvidia hardware.

That said, they can and have said they will be adding optimisations for GPUs where need be. You may find this information in their docs for UE5.

 

Yea nanite is definitely the cooler tech. Basically having infinite poly budget for rigid objects with no LOD pop-in is game changing. Can it work without an ssd on more modest poly counts for just free performance? With more testing and time we will see how both play out nanite and lumen.

 

Are you talking about LightPropagationVoluimes?

They killed it.
https://docs.unrealengine.com/4.26/en-US/BuildingWorlds/LightingAndShadows/LightPropagationVolumes/

Apparently there's still SSGI which wasn't present a few versions ago and which I now need to check out.
https://docs.unrealengine.com/4.26/en-US/RenderingAndGraphics/GlobalIllumination/

Global illumination, by the way, was a nice example of feature disparity.
If you use unity's enlighten, then emissive texture output will light up the environment.

In light mass however, at some point lit up emissive texture areas were simply ignored as in they did not produce light bounces....

Not sure if it has been fixed, though.

 

This.

Our biggest pain point in UE4 has always been the connection between the IDE and the editor being kinda of flaky and UE's version of c++ is a little on the messy side. (i.e. making changes in code not always showing up the editor without a restart.) Visual scripting in UE4 fixes this somewhat, but trying to make complex logic in visual scripting can be difficult.

To me Unity's strong point has always been the c# and complex loop architecture as compared to UE's c++ and simple loop architecture.

 

How is Unity's loop complex and UE's loop simple?

Spoiler

Legit asking.

 

I second this question - something i legit want to know too since i dont understand a lot about coding and general game architecture. Like to me as an artist everything about UE seems vastly easier. But most people say writing code in c# is easier. They say that you dont have to do as much pedantic memory management.
Does it just boil down to how much busy work you have to do? Or is there like, a ton more exceptions and complex dependencies you have to learn when working in UE? Does development take longer because of this? Like I am doing some tutorials using blueprints in unreal and now things that were hard to understand are really making sense to me. Granted I am doing nothing complex but I am making viable prototypes with common gameplay mechanics. And so far it all seems pretty straightforward.

 

The thing that irritates me about the package manager from the beginning (and it's symptomatic of current leadership's way of thinking) is that they already had a working system for developing features out of sync with the core engine development. It was called the Asset Store. Unity was already providing features and sample assets through the asset store, all they really had to do was just make a dedicated section for Unity-produced features to make them easier to find. What difference does it make if you get ProBuilder through the Asset Store vs Package Manager? None. But no, they had to waste a bunch of time reinventing the wheel, just so they could make Unity more like Unreal (Package Manager is basically Unreal's plugin manager).

 

When they changed from perpetual to subscription they told us it was so they didn't have to hold back features for big releases.

In hindsight, this was a red flag. What it really meant is that they no longer had to make sure all features played well together. It was a sign that they viewed each feature as existing in a vacuum and not as part of a whole.

What ended up happening is even worse. Since they no longer had to make Unity versions worth selling, they also stopped making them worth using.

 

As always, Unity gets the best value feedback whenever their competitors release something. Beats any poll and woe betide the company that would gloss over it.

 

Do not want to derail the thread but this book "Game Engine Architecture" by Jason Gregory (i have the second edition) goes into great detail about engine architecture in general and the difference between a complex loop update and a simple loop update.

There are pros and cons of both. Even if you do not have a major technical background I do recommend the book. The book will shine a light on why Unity and Unreal Engine do certain things.

 

ah thanks. i actualy have that just havent read it yet. Got to now

 

It would actually be great if you explained what you meant, because the book in question does not appear to mention "complex loop update" at all.

The loop is described in chapter 7, The Game Loop and Realtime Simulation.

So, at which page is it describing simple vs complex game loop update?

 

UE5 can now render more cubes than Unity.

Game Over!

 

Dynamic ones?

 

One dev on their stream said that he has ancient valley project on hdd and it works fine as IO operations are spread over time. Next question is: will nanite be able to scale down everything when building a project to make it run on all platforms.

 

But UE still doesn't have C#, so it is a massive Cuben miss-IL-crisis... (I'm not sorry)

 

Not if you can ... verse ... your code differently.

 

Unreal focuses mainly on static scenes, for best performance.
Now try do something dynamic in real time and fancy with "cubes"
If that all happening on GPU, your options are quite limited.

 

Isn't that one of the fortnite features? Destructible map and ability to build stuff?

Unreal games frequently feature modular building systems which actually allow large structures build by players. Two examples I can think of are Conan Exiles and Satisfactory.

Spoiler

https://www.reddit.com/r/Satisfacto...ours_playing_satisfactory_no_mods_heres_what/

 

The day Tim Sweeney can get his head around data oriented design and decide to refactor UE to be more data oriented, is the time Unity will really need to step up. For me, data oriented design has changed my programming completely and will never look back. I mean, if an OOP programmer can relearn everything and get in depth with DOD, s/he will realize whatever they learn from OOP is almost a joke.

 

I have it on (a very old gaming laptop) HDD, it works just fine. I tried testing details to see if any problems occur but it worked seamlessly.

 

UE has always been more artist friendly, and Unity has been more programmer friendly. UE is years ahead of Unity in terms of rendering. but in terms of architecture, UE's bloated gameplay architecture has probably made huge improvements since their UE3 days, but still far behind Unity's monobehaviour/gameobject system. Not to mention the new DOTS is just nothing short of revolutionary.

 

But what if they broke it and refuse to fix it? What happens then? What if my game needs 2+ more years of development and I need to know I can rely on the features I use, what then?

You're telling me that people at Unity are either clueless or liars and "deprecated" "production ready" etc mean nothing.

That makes me feel really good about the software I'm using.

These flimsy excuses are things I expect to hear from Unity evangelists, not users.

In Unity, the editor can crash on its own without the help of plugins.

 

Oh my goodness that would be fantastic, my daughter mentioned it might resemble godot script? Do you think it will release fairly soon?