Where is this from? If I may ask… The .NET Blog?
1 Like
And why does this need to be brought up? It was already clear that Godot has a different implementation of .NET into their engine.
2 Likes
While differ it was a free engine with smaller team and less resource
Not to mention since the last time we talk about this, now you know full well how unity handle their own human resource
1 Like
Its also a considerably smaller/simpler engine, making it magnitudes easier to modify to work with newer C#.
I don’t think it is that difficult to comprehend that both engines are vastly different! You can’t compare them as apples, it is apples versus oranges. Both are fruits (game engines) but they are different.
Unity handles their manpower somewhat strangely I admit, but the .NET team was not involved in the latest layoffs. Project is still ongoing. And why you are again kicking up dust, I will never understand. Mods, please close this thread as well… Thanks…
1 Like
You said this first… What they are saying is correct, it’s just that it doesn’t need to be brought up again. We already know that godot has been way faster in .NET Modernization.
.NET Standard 2.1 and C# 9 has served me pretty well. Even if Unity decides to never upgrade the .NET stack, I don’t envision that there are things that I cannot do in Unity without a newer C# or .NET version at this point.
2 Likes
It’s been almost a year and COMPLETE silence on CoreCLR / .NET Modernization … all our fears seem to be confirmed.
I tried the C#9 / C#10 support hacks for Unity, the mono runtime performance is just too bad and it’s still lacking a large number of features I use in my library. So… no time to port to Unity, in whilst in Godot, Unigine, Flax, Stride, … it just works… (and that’s what I’m using now)
Would love to see Unity finally catch up.
2 Likes
what fears? They said .Net CoreCLR will take years to complete, and my guess they’ll aim for it to be in Unity 7, let them work on it in peace lol
2 Likes
Unity 7/Core CLR will start working on Half Life 3 rules if folks keep making comments like this.
3 Likes
They work in peace to came up with new hub that link new project to cloud project by default
Actually required to all new project, and changed to by default when people protest, not to mention with hideous UX at first version and need to hurry hotfix when people complain louder
Moral of the story, the result of unity working in peace is these kind of thing for us
The .Net modernization team is not the same as the Unity Hub team, stop twisting reality to make irrelevant points, complaining here about the speed of CoreCLR integration won’t magically make it ready for release now, they said it’ll take time and it is taking time and that’s the end of the story.
7 Likes
Any team in unity is all under unity executive’s order
Unity hub team were people who should work to make hub become better tools for us, and they was ordered to make hub become like this
.Net modernization team were people who should work to make core engine become better tools for us. What they was being ordered to do?
I am not twisting anything I just point out the comparative evaluation about how unity manage their resources
There are many feature that the hub should be implemented. But the hub team was being reprioritized the team member to go do that feature instead and that was shove to our face in 3.13.0
This is how unity company manage their manhour resources for almost every feature since 7 years ago. So why couldn’t I be skeptical about every team include .Net modernization team
How many member was leaving from that team already again? How many member left?
How many times the word AI was being repeated in Unite last year?
fyr
Nope, CoreCLR in Unity started as a small personal project of a former Unity employee, he pitched the idea to the executives and they assembled a team to make it a reality, years later after the CEO fumbled and left Unity did some restructuring and a new CEO came, and the CoreCLR team explained the project to the new leadership and they said it was received positively and were given another green light to keep working on it while the new Unity leadership turned its focus to other things and fired other departments that they didn’t deem as necessary for the development of the Unity’s core products…
The point is the CoreCLR project started from Unity employees knowing they need a new backend, and it survived both the old and new leadership, this proves everyone at Unity understand how important it is to have the new backend instead of the outdated Mono.
These attempts at painting a concern over the project are misguided, made from an ill-informed outside perspective, and in many cases it’s mixed with bad faith argument, and I’m sorry but “AI” is another bad faith argument, if you have paid attention to Unity lately they stopped mentioning AI as much as they used to, marketing material for Unity 6.1 had no mention of AI whatsoever and you can check for yourself here (try to find a single reference to AI):
Unity 6.1: Supported Update with Enhanced Performance | Unity
And I need to re-iterate this point, Unity internally knows how important CoreCLR is, many other backend systems beyond .Net are being reworked btw like “spoiler alter” the graphics backend, they said the work is ongoing and they’re targeting Unity Next-Gen which probably means Unity 7, and that’s the end of it, misguided complains won’t help, if anything they could just trigger Unity to shut off these communication channels (they already did with CoreCLR, people couldn’t shut up with their made up theories and Unity decided it’s not worth it to give people a channel where they can freely communicate with the CoreCLR engineers).
8 Likes
To add on to this remember last week Unity just released a major step in unification of the render systems that is already in a public Unity version. Unity had to merge the Render Graph API backend for all SRP before they could move forward. This unification came out last week for testing and they made a post on it. Will link to Unity’s official post at the bottom.
So far Unity hasn’t abandoned some of the major foundation stuff that other tools are build on. I know they had to push back Terrain Tools, but I am talking about the stuff other tools are built on.
-
.net CoreCLR - They already got an editor with it working last time I heard just not the runtime player yet, but I think they made great progress since last time.
-
Render Pipeline Backend Unification (in public alpha already) - They got the Render Graph API mostly unified making most Render Graph API work for all SRPs. Please note there are differences because of targeted systems, but most stuff use the same API calls and backend now.
-
Graph Toolkit ( has a public package already ) - They had to solidify the foundation for Graph Toolkit first because the new animation system, Shader Graph 2.0 major rework, and more relied on it. I already have a custom Dialogue Editor working in my project in an alpha build that people are playing, so it does work well.
-
Low Level 2D physics (currently in the physics samples 2D package on Unity’s GitHub while they are finishing testing it for release soon) - This involved updating the Box2D library integration to a new major version that was written in a completely different language than the last major version. Previously was in C++ and now it is in C which probably took some time to integrate.
There are more things like the ATG (Advance Text Generation ) that came along with the UI Toolkit World Space and custom shader support. And Yes, we have custom shaders in UI Toolkit now. Look up the Swirl UI Toolkit Shader example in the manual for Unity 6.3.
Long story short they have been doing a lot of foundation updates first so the future tools won’t need any heavy rework allowing them to make features faster and easier to bug fix. That a lot fo time with how many things they are updating and creating a stable foundation for.
Render Graph Updates in Unity 6.3 - Unity Engine - Unity Discussions
10 Likes
I believe that when I hold an alpha of this in my hands.
They’re still working on Burst and IL2CPP, which would almost fully be superseded by CoreCLR/RyuJIT/AoT compilation.
This tech should have been in Unity 6.0. The effort is overy 8 years old at this point.
1 Like
I think that Unity’s across the board modernization is pretty garbage as far as speed is concerned, but the problem here is that the alternative is that they cease work entirely on Burst and IL2CPP when those are both things that are being actively used in production in a lot of games, which leaves us in the position we were stuck with when they stopped doing anything with BiRP and told us the SRPs were production ready.
3 Likes
In the keynote? If memory serves, it was exactly 16 times, 9 of which were in Google’s sponsored segment. I think most of the other mentions were in the segment that Silvia and I did, when we talked about how we used Inference Engine - or Sentis as it was then called - to compress character cloth deformation data for Time Ghost to the point that it could run in realtime on a phone. (I remember this because the folks in the Youtube stream chat were keeping a running count, and went nuts when Silvia dropped the first mention in the show).
Anyway.
As we said back in April, we’ve changed our strategy to how we’re working on these things: we’re providing a smoother upgrade path, and we’re delivering what we’re doing more incrementally instead of trying to pack everything into one big release. By breaking it up into pieces, we’re going to be able to start shipping those pieces earlier than otherwise, to make it easier for you to begin using them, and to check that the quality is where we need it to be at each step in the process.
The .NET Modernization team are currently taking the work they did under the old strategy and adapting it to the new strategy. For example, under the old strategy, we implemented CoreCLR without much concern about whether we were breaking Mono in the process; but under the new strategy, we plan to ship some versions where Mono and CoreCLR coexist, so we’re working back through what we’ve already done with a bit more care, to integrate it into the codebase without regressing any projects. At the same time, we’re taking advantage of the opportunity to break the work up into smaller pieces that we can land, polish, and ship earlier; for example, decoupling “CoreCLR runtime” from “.NET 8 profile,” so that we could ship the former while the latter is still being completed.
8 Likes
THIS is what I have been said I am being skeptical that dotnet modernization team was being reprioritized from the executive’s order to do something aside making dotnet modernization
The change of strategy means more work that was push into them to do. And delayed was inevitable again, and again, and again
How many times they have been ordered to change the plan already. Everything was done in a way that make dotnet modernization cannot happen in every step possible
How can I trust unity that this year there wouldn’t be “new strategy” that need them to rework everything they did again and push dotnet modernization to eternity 7, or 8, or unity 40k ?
When you will release it is the true question that never being answered
All of the thing you said here is so dreamy
And I mean totally so DREAMY
1 Like