Introducing Unity 6, the next major release of Unity.

You can combine them but the main advantage of ECS is moving away from GOs. Unity likes to push that you can combine them because they're likely years away from even basic animations. There are third party assets such as Latios and Agents Navigation but you have to be willing and able to rely on a third party.

IMO unless you're willing to rely on these or you're willing to build your own frameworks I wouldn't use ECS. Jobs and Burst are pretty solid though and I do recommend them if you need any form of multithreading.

https://github.com/Dreaming381/Latios-Framework
https://assetstore.unity.com/packages/tools/behavior-ai/agents-navigation-239233

 

Nothing in that post benefits my workflows besides minor perf boost in some niche scenarios. I'm not interested in ECS. But I'm sure it's relevant for anyone building the next V Rising.

The key features presented at Unite were the upscaler and the GPU rendering tech developed by Weta Realtime folks who are now getting laid off with these features unfinished. So I just can't get excited.

 

Kinda. The developers had to modify the engine (and presumably DOTS) to make the game they wanted.

https://unity.com/case-study/v-rising#building-confidently-source-code-access

 

Well, its certainly benefiting my project, which involves dynamic rigidbodies with thousands of individual voxel parts, representing a vehicle constructed by the player. Everything is faster. Just dragging and dropping renderers into an Entity subscene increases framerate by a significant amount. I'm developing on a 2011 generation 2 Intel cpu, mismatched DDR3 ram, and a 2017 RTX 580, but from tests I'm able to squeeze out a huge amount of performance. E.g. (In a performance test every frame): Dynamically getting 1 million currently existing entities that have 3 specific components, getting those components, reading them, checking distance, and setting values (such as position) back to them, barely touched my framerate. 0.02 milliseconds on the main thread. Version 1.2 of ECS, Netcode for ECS, Unity Physics, and Entities Graphics are currently in a 'release candidate' state. There's been some good improvements since 1.0 released.

The workflow can actually be faster than with GO's, and certainly ends up being cleaner. You don't have to manage references & dependencies so much. You just say that a system requires certain types to exist or not, then it can automatically acquire those types and iterate them in the most efficient way. Kinda like some magic. E.g. you say: This system requires entities that have ComponentA and ComponentB, but do not have ComponentC, and the system automatically runs when that combination of components exist on an entity, and it automatically has access to them, you just pass the query to your job.

What I'm most excited about, though, is the netcode. Faster servers means cheaper servers. And its nice to have all the built in features such as lag compensation, and proper deterministic predicted physics, or client side prediction at all.

Personally, I'm loving the workflow of it all. As someone that learned to code with OOP, it took a while to get into the ECS mindset of "just iterate it", though. I still struggle with my OOP habits telling me to do the opposite of what ECS wants. But when something wants you to avoid random memory access, you start to realize how often you're actually doing it and why it can be so bad.

 

The primary point of my post is that you shouldn't try to combine ECS with GOs. You either go completely ECS with third party frameworks to make up for missing functionality or you don't use it at all. Your project is actually a great example of this as nothing you've described is dependent on GOs.

You would also mostly if not entirely eliminate the performance advantages too by trying to use the systems that work with MonoBehaviours.

 

Well, some things will still need to be GOs, such as any VFX Graphs. But since all of my dynamic things are "hard surface" robot parts, I don't need skinned meshes renderers, so I'm not suffering from the lack of an animator. However, there's no reason you can't use GameObjects for the animators. You can keep references in managed ECS components, or in managed systems. It won't slow down your ECS code, especially since most of it is running on worker threads anyway, your main thread has some time to do some work with GameObjects. But in the case of skinned mesh renderers, they're very optimized already, using DOTS "behind the scenes" for efficient access. However, there's quite a lot of tricks that you can do to avoid accessing the GO's in a typical way for animation, while still using Mecanim.

There are some things that make sense as objects, though, because the whole point of ECS is to avoid random memory access. It organizes memory for you, so that your similar entities are all together in memory, in chunks of 16 kb. This allows the memory to be read extremely fast and moved to CPU cache in chunks so that your scripts are always working with CPU cache memory instead of RAM. If you need a complex network of relationships between entities, then you're starting to do random access again, where you're pointing to all different places in memory and causing tons of cache misses again. Although, doing such things with DOTS would still be faster.

 

I'm not counting these use cases as in these situations the GO is just a glorified point in space and not a moving, animating, colliding entity.

You totally can but again it comes back to you're throwing away the performance you were trying to get in the first place. You have a million entities in your scene. Good luck doing that with GOs w/ Animators. It's not happening.

 

That's thinking in an all or nothing mindset, which is something people discuss in the ECS forums from time to time. Not everything has to be an entity. If you only use ECS for 10% of your game, your game will still run faster than it did before. That's a win. If you use it for 90%, then well, you could have anywhere from 4x to 100x better performance, or sometimes even more. (E.g. in the case of iterating millions of entities, that can be more than 100x more performant than iterating millions of gameobject transforms)

It also makes more sense when you stop thinking in terms of "objects". You can split up your data however you want. Some data that represents a part of a feature can be ECS, some of it can be in gameobject land, or however you want. Data oriented design teaches you to think of data independently, rather than as a comprised "object". E.g. you don't have a Rigidbody anymore. You have a PhysicsVelocity component, and a PhysicsMass component, and etc. Its split up into its most basic parts. And you never have your logic with your data. Data is just... data by itself. Logic goes elsewhere, and uses that data.

 

Maybe. It's very much dependent on the game. Most of the work projects that I've had wouldn't have benefited from ECS because they weren't being held back by the CPU. Instead they were typically held back by the GPU thanks to HDRP. In fact the CPU would often be idling waiting for the GPU to do a frame.

 

Maybe. I can see an improvement in framerate just by dropping a handful of cubes and spheres into an entities subscene, which automatically converts them to entities, then just hit play. Although I haven't compared against the new feature that allows gameobjects to render with ECS's fast path.

The better framerate is because the CPU is still used for quite a lot of things in rendering, such as culling to determine which renderers are visible, and preparing and sending draw calls to the GPU to tell it which ones it should render, and much, much more. A lot of work is being moved to the GPU lately, as they are currently shifting towards a gpu-driven approach.

 

Looking back it might not be clear but I'm not saying everything has to be an entity. I'm completely fine with the idea of keeping things on the side of GOs that have little to no impact on performance. For example UIs. I'm just saying that you should only go with ECS if you're prepared to have the heavy hitters in ECS.

Sure, but you can also just use

DrawMeshInstanced

and achieve almost exactly the same performance. It's when you want more than just a simple object that things start becoming tricky.

 

This is nothing against you, but; Reading through the forums, I've been starting to see why Unity didn't rush to implement their own Nanite. There's so many users who's (properly informed) complaints about features boil down to: "that doesn't make my mobile game better". It makes sense, though; If someone isn't working on something modern, they probably wouldn't be all that excited about modern features coming to the engine. They just don't need it.

 

You're not looking at it closely enough. Unity's biggest source of income by far is mobile ads. Unity licenses are not even remotely close and the asset store is even further down. It's why we had the installation fee fiasco.

 

Yes, but that doesn't mean everyone is working on mobile. There are some of us who get excited for the new features for HDRP, ECS, etc. Also, I don't think Unity wants to become typecast as just a mobile engine.

 

I'm not saying there aren't people excited about non-mobile features. I know because I'm one of them. I'm simply saying that it's not people asking for mobile that are resulting in the focus on mobile. It's entirely Unity.

Unity doesn't really care about the engine. Unity is literally laying off everyone that is involved in the engine's development while leaving the ads people. Just this past week we saw the layoff of one of their best graphics engineers and most of the URP team.

 

Layoffs are happening everywhere, including other game engine companies.

As for the URP, if they really are ditching URP, I think that would be a good thing. I'm using HDRP on, as I mentioned, a 2011 gen 2 Intel cpu, mismatched DDR3 ram, and a 2017 mid-tier GPU. As far as I know, all the new mobile devices support compute shaders, but I haven't looked that up, that's kindof an assumption. The lack of compute support was the main reason for URP in the first place. HDRP relies heavily on compute, but to support all hardware, they needed a branch that doesn't rely on compute shaders.

They should just focus on 1 pipeline. Make HDRP as scalable as possible with all the latest tech, but able to toggle everything off. As it is now, almost everything already can be toggled off or tweaked. Then they just...call it the built in pipeline. The Unity pipeline.

 

Have you not seen their high-end upscaler?

https://forum.unity.com/threads/unity-6-beta-2023-3-feature-highlights.1532590/#post-9560452

 

Yeah we discussed that earlier, scalable temporal post processing. It works wonders for HDRP.

In a heavy test in editor, I went from 18 ms down to 10 ms frame time, rendering at 60% resolution and upscaling.

 

Right, well, it's dead now.

 

That's a pretty big assumption. I don't know if he's "one of their best", but, I would imagine that Unity owns it and can continue to use it and develop it. Changing developers isn't uncommon. Many of the people working at Epic and Unity aren't the same developers that were working there 5 years ago.

 

That's fine. I'm telling you he was. He's likely not the only one that was let go either and since he was most likely in the HDRP team I fully expect to hear that they've lost most of their developers too along with the URP team.

 

That would imply that they would lose everyone working on rendering.

The old "built in" pipeline is fully deprecated, as it should be. Its kind-of a mess, and was built on old assumptions from the early 2000's. A new pipeline is due, built for current hardware. I wouldn't want to just band-aid some old pipeline that's been around for 20 years, either, if I were them.

 

Almost everyone. Word is there's a couple of people left for URP. I fully expect the same for HDRP soon.

I wouldn't be surprised if they just gave up on SRP and went back to a "built in" pipeline. Just a new one built from scratch rather than the existing one upgraded.

 

Well, this is getting into the realm of speculation and assumptions, so, we shouldn't debate that, since there's no way to come to a conclusion. I hope they're restructuring for 1 rendering pipeline, though, and foregoing support for ancient hardware in the process, so it doesn't slow them down.

It would actually make sense, considering that "Scritpable Render Pipeline Coexistence" is "in progress" on their product board, which is to allow support for both pipelines in one project. Might as well focus their efforts on just making it 1 pipeline, rather than trying to fit both in. From some other forum posts, it seems that is the long term goal.

You can see the product board here, which shows major features. The list for HDRP is quite a lot bigger than URP. URP's is kinda... boring. Not to mention that some of the stuff in the other tabs, such as GI, Vfx, Foundation, etc, are things that people would likely be excited about if they're also excited about HDRP. The list on the product board for HDRP was even larger when 2021 stuff was still listed on there, when much of the groundwork was still being added, but that's been phased out of the board.

High Definition Pipeline - Unity Platform - Rendering & Visual Effects | Product Roadmap (productboard.com)

 

Unity has a very bad track record switching teams under projects. Most likely they just silently abandon the project where the original developers leave.
And when some new people come in to maintain the project, they usually take the project in a very wrong direction just because why not. The great example of this is the Input System package. They are doing absolutely redundant l'art pour l'art development while more stressing problems remain unaddressed. Like broader input device support or serious problems with touch controls. Instead of those we are getting another setting menu with even more crappier editor.

 

Hmm, maybe. We'll see. Its entirely possible that it may end up making more sense to just roll with FSR and DLSS. They're both supported for HDRP now anyway. I would like to see where STP goes, if they don't abandon it, though.

Ah, I was unaware of issues with touch controls with the input system. Anecdotally; I've had no issues with it, but I just need standard keyboard/mouse & controller support, no mobile.

 

This would be great. I actually hoping that unity going back to old naming system also mean that it would also back to the (new) old reliable built in render pipeline.

but it's also already proven to be more performant, reliable, and flexible.

 

It is not more performant at scale. You can't just dive in and perform a test with few cubes. Think of it like a multithreaded job. The job has some overhead to start, but once you scale up, its going to vastly outperform some regular single threaded operations that run on the main thread. If you're just doing a few operations, though, then the overhead of initializing the job is going to be higher than just doing the few things directly. Now, extend that to an entire pipeline involving tons of setup with both CPU threading and compute shaders, and whatever other preparation is done for scalability.

Where you're going to get your performance gains is when you're actually using everything that the pipeline is preparing for. Much of which you can toggle, but even still, there's going to be some overhead.

When you've added your procedural skies with procedural clouds, physically based atmosphere, your volumetric lighting & fog, your auto exposure, screen space reflections, screen space global illumination, etc, and you've ticked on some of HDRP's large list of shader graph features, such as clear coat, translucency or subsurface scattering, maybe have the water system with an ocean or rivers or whatever, throw in some volumetric vfx graph stuff, essentially bringing your game up to par with what people are currently making for the economy tier of the current generation of game consoles, then HDRP is going to absolutely destroy the old "built-in" pipeline.

Not to mention that everything I just noted is done with a relatively small amount of clicks and/or mouse drags...

 

I hate when Unity staff comments and then deletes it, I never know if it was wrong information or just the Sword of Damocles stopped swinging over their head and got the angry chat to remove their public comment right away, because this company can't have transparency. I guess we will never know...

 

Make up your mind.

 

Also, shiny new features (none of which are useful to me, but that's just me), mean nothing unless Unity addresses their core problems, a major one being abandoning features in a half finished state and long standing issues remaining issues forever.

Firing the person making STP before it was done is a big indication that nothing has changed on that front. The people that could take over Timothy Lottes that still work at Unity can probably be measured with the fingers of one hand (that lost a couple of fingers in carpentry accident) and they would still need several months of downtime while they understand the code and shift their domain a bit, plus, I bet they are busy working on other stuff.

So a list of half finished features isn't exciting at all, because they will remain half finished forever.

And unless Unity communicates clearly something different (with evidence and plans), I will keep assuming this "restructuring" is either them pivoting towards ads, or the panicked flailing of managers and C-Suites.

So yeah, to me, Unity 6's feature list seems like a lot of hot air.

 

Those were two different topics. One was in regard to just dropping renderers into an Entities subscene, the other was HDRP vs BIRP's scalability.

These shiny new features mean quite a lot to me, and are what makes my project even possible for a solo developer. (In a reasonable amount of time, that is)

 

Well,

Good for you.

Have fun working with half finished features. Hope you don't need anything fixed or improved after Unity 6 comes out.

 

I actually tested in real projects, it's a pita and a waste of time switching to URP, trying to optimizing the game to run as smooth as before, then ended up switching back to built-in

 

I'm not sure what you're arguing at this point. Is it that Unity is going out of business? Or that they shouldn't focus on current & future tech, instead of patching the old? That they're going to abandon the massive amount of work done on their primary rendering pipeline (HDRP)? And yeah, I'm saying that's their primary pipeline. I can't look at the massive list of features for HDRP, and the relative tiny amount of features & updates for URP, and say that URP is their "favorite". I would imagine that its not very exciting for the developers at Unity that are working on URP. Every decision they make has to revolve around whether or not it will work with ancient hardware.

That aside, I see great things coming. They're just ramping up their multiplayer, which so far, is awesome. Everything in one service. Dedicated server hosting, matchmaking, lobbies, economy, inventory, cloud saves, cloud code, voice chat, friends, leaderboards, etc etc. So far, its been battle-tested by games like Apex Legends, whom uses it even though their game is made in UE. And with Netcode For Entities, you get hyper optimized server code, with lag compensation & client-side prediction, including for deterministic physics, and all the bells-and-whistles that you would need for a competitive, "serious" server.

 

I'm saying they have a pattern of not finishing or iterating on features and that doesn't seem to have changed.

I'm sure even Unity doesn't know what their primary pipeline is at this point.

 

Oddly, Ive had the same experience. I want to URP, everyone raves about it, but, despite it all, if i convert my project, suddenly now i have to redo all the lighting - which is annoying, but OK.. but then i find bugs, and places where light leaks and it never did before, and so i just scrap it and stay on built in, cos well, it works the way i want.. is it slightly slower.. yes, but, it works.. id rather lose 10-15fps and have it work than it look like dung. And i never have been able to make the lighting look as nice.

 

Idk, some people are happy with the way things are going. I suppose this is how it is for every engine, though. I just clicked on Unreal's forum, and the topic of the top post is, and this is a direct quote:

"Why Unreal Engine 5 has too many issues?"

But the Scripting thread is just full of bugs and issues people are having. Also, if you google for things like "Unreal unfinished features", you'll find similar complaints to what you said. Or look around the time when they were transitioning to UE5. Despite the advertising, the forums were full of people complaining about features not working or incomplete features. E.g. Nanite's shadow issues, or not working with trees or anything dynamic, crashing, unstable performance, etc etc. Have to take this stuff with a grain of salt, though, so to speak. Many "bugs" are actually just user-error, but are reported as engine-error.

Also, their CEO recently said, after some layoffs, that they're "spending more than they're making". So, its kinda the same boat over there at Epic.

 

(emphasis added)

But I'm confused, are you agreeing with me that Unity does not finish its features and are just pointing out that Unreal does it too (which I guess somehow makes it better for Unity users?), or are you disagreeing with me?

 

I think, off the top of my head at the moment; In terms of a game engine, I don't even know what a "finished feature" really is. When do you say "that's done" and never work on it again? It seems like, the way tech progresses these days, by the time you get to that point, its time to move on to the next new innovation that's been revealed, or you just fall behind and people lose interest.

If a feature is usable for a nice production release, could we say its finished? E.g. the people releasing with Nanite in UE 5.1 may have felt like it was a nicely rounded feature, but people using UE 5.3 will have a much smoother time, and people a few years from now will have it even smoother, unless some better tech comes along and makes it kinda pointless to continue working on nanite, in which case they absolutely should move on to what's better.

 

Yeah, you are dodging the question. You don't even know what it is, but you know Unreal does it too.

Cool.

Have fun.

And good for you.

 

You could extrapolate from what I said, but, if you want a straightforward answer: Unity does not finish (all) of its features.

However, going down the list of notes in the alphas and betas for 2023, they've been putting quite a lot of work in, and I'm liking it.

So, now that the question is answered, where are you going with it?

 

Now that you've mentioned unreal, I actually use unreal too, and I could say that even if their feature still have problems here and there, they are more mature, which is understandable since they got there earlier.

I just wish that Unity stays as Unity, not trying to be the next Unreal.

 

Oh yeah Unreal is a great engine. Its used by numerous AAA studios and is battle-tested with some really big games. I only brought it up as an example that you can find users with similar complaints wherever you go. That's just the nature of it.

 

This decision has to be reverted(firing stp guy) its unacceptable. We need to speak it loudly to unity management.

 

Well, I have a bit more information on the topic --

I just tested FidelityFX Super Resolution 2, which was introduced in 2023.3 beta, and, after setting it to upsample after post processing, the performance is about the same as STP. I also googled for a bit more information on it, and, it seems that FSR is open source, but also maintained by AMD, and all versions work on nearly all modern hardware. FSR2 is currently officially included with Unity 2023 beta, but FSR3 is not yet. FSR3 was released at the end of last year, with only a couple of games supporting it at first. I don't see any "official" support for FSR3 from either Unity or Unreal yet, only third party plugins.

So now we have to ask the question.. would it be worth paying someone (or a team) to work on an in-house solution, when AMD and an open source community are tackling it already? I'm personally not sure. For some features, in-house is definitely best. But, for something like this, idk.

With that said, though, the creator said that STP is "going into Unity foster care" now, implying that Unity is taking it over. We'll just have to see where it goes.

 

Same developer (Tim Lottes) worked on both teams (technically directly on FSR 1 but I imagine some of his work went into FSR 2 too). In fact I think the only things he hasn't worked on are DLSS and XeSS.

 

Ah, that guy gets around, eh? His colleagues were likely sorry to see him go. We could only speculate at the reasoning behind it. Definitely a sad personal story, but he seems to be taking it well, at least appearing to do so.

 

When is Unity 6 releasing?

 

this year..

allegedly