Search Unity

  1. Unity Asset Manager is now available in public beta. Try it out now and join the conversation here in the forums.
    Dismiss Notice
  2. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  3. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Unity Future .NET Development Status

Discussion in 'Experimental Scripting Previews' started by JoshPeterson, Apr 13, 2021.

  1. PetrisPeper

    PetrisPeper

    Joined:
    Nov 10, 2017
    Posts:
    66
  2. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
  3. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,085
    https://blog.unity.com/technology/unity-and-net-whats-next
    Can hot reload be added to the list? It seems like a core feature to speed up development.

    Hot reload in V Rising in Unity 2020.3:
    https://clips.twitch.tv/MildSnappyBatBatChest-ij9hDqGk_0vK-DOE
    https://clips.twitch.tv/ReliableWanderingStorkRaccAttack-b6exkxD_YUQ9ttiA
     
    JesOb, NotaNaN, Alan-Liu and 2 others like this.
  4. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    We don't have it on the list currently, but it is something we are watching from the Microsoft side. The current implementation of Hot Reload is a bit too limited, but it definitely has the potential to be an incredibly productive tool.

    It looks like Microsoft will continue to move it forward to cover more and more use cases. Our goal is to support it in Unity when we can come together with a modern version of .NET in Unity.
     
    Luxxuor, cxode, NotaNaN and 4 others like this.
  5. goldbug

    goldbug

    Joined:
    Oct 12, 2011
    Posts:
    766
    It seems there are plans for decoupling the build process from the editor.

    Will it be possible to download & use the build toolchain without the rest of the editor? That would be super cool for ci/cd pipelines.
     
    dan_ginovker, spryx, cxode and 3 others like this.
  6. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    Right now this is not a planned feature. However, this is very much the kind of thing we would like to enable in the future, so I would not rule it out as a possibility. But speaking realistically, we're at least a few years away from having any chance something like this would work.
     
    cxode, goldbug and NotaNaN like this.
  7. PassivePicasso

    PassivePicasso

    Joined:
    Sep 17, 2012
    Posts:
    100
    Is the OP kept up to date about the status of this work?
     
  8. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    Sorry, what do you mean by "OP" here?
     
  9. PerfidiousLeaf

    PerfidiousLeaf

    Joined:
    Aug 30, 2019
    Posts:
    20
    OP means original poster, so you, I guess. I think it would be assumed that you are up to date lol.
     
  10. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    Ahh, ok. Yes, I'm trying to keep the original post up to date with as much information as I can share publicly. I want to be very careful not to give the wrong impressions around release timelines, as people might plan projects around them.

    So I don't update it too much. But when we do have major milestones in releases, I'll update it.
     
    PassivePicasso likes this.
  11. PassivePicasso

    PassivePicasso

    Joined:
    Sep 17, 2012
    Posts:
    100
    Superb thank you, I often refer people here but wasn't sure if the original post contained the most pertinent information
     
    JoshPeterson likes this.
  12. DevDunk

    DevDunk

    Joined:
    Feb 13, 2020
    Posts:
    4,971
    Another great feature of .net 7 is better linq methods with huge performance gains (which also should be used in the mathf library probably):
     
  13. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    1,085
    For more .NET 7 performance gains and some behind-the-scenes details as to why, check out this blog from MS.
     
    Huszky and DevDunk like this.
  14. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,085
    For me what's more important is that these methods will be faster than hand-written normal code. Kind of like Burst but without NativeArray headaches.

    Looks to be using JIT, does that mean it can't work in il2cpp?
     
    DevDunk likes this.
  15. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    1,158
    What I see is it used vector to harness simd hardware acceleration
     
    Magic73 likes this.
  16. m-yukio

    m-yukio

    Joined:
    Dec 22, 2016
    Posts:
    8
    gRPC for .NET has an error in communication because Unity 2021 LTS does not support HTTP/2.
    The only option to use gRPC in Unity is to use gRPC Core, which will no longer be provided after 2022-05.
    https://packages.grpc.io

    I tried to check the operation with the expectation that Unity 2022 supports HTTP/2, but a communication error occurred.
    Should we wait for Unity 2023 and beyond to use gRPC for .NET with Unity?
     
  17. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    1,158
    Unity 2023 is already in alpha. Is it already fix grpc error?
     
  18. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    Once we get the .NET class libraries working with IL2CPP, we plan to implement the same intrinsics as CoreCLR JIT uses. I'm not familiar enough with this feature to know if it requires JIT for good performance or not, but if we can implement it in AOT, we will.
     
    Qbit86 and Harry-Wells like this.
  19. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,085
    I see, found more info about vectorization:
    About JIT:
    I guess R2R means it can work without JIT.
     
  20. m-yukio

    m-yukio

    Joined:
    Dec 22, 2016
    Posts:
    8
    After reading the post, it seems that Unity 2023 alpha is not yet supported, but I will try it.
     
    Thaina likes this.
  21. m-yukio

    m-yukio

    Joined:
    Dec 22, 2016
    Posts:
    8
    I haven't tried it due to another issue.
    I get an error with Google.Protobuf, is the following related?
    https://github.com/protocolbuffers/protobuf/issues/10085
     
    Thaina likes this.
  22. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    Meta-comment: It might be worthwhile to move the gRPC support discussion to a different thread. I suspect that will get lost here, and I think that it is off-topic for future .NET discussion.
     
  23. Katerlad

    Katerlad

    Joined:
    Mar 26, 2015
    Posts:
    17
    I tried searching for the latest update on the work being done for Null-Coalescing Operators in Unity with GameObjects/Objects. Im not sure I saw any timeline or if I missed anything about it. its a long thread haha. Not sure if there are any new developments for this in 2022? Was hoping to see if Unity is planning to figure out the solution to this in the nearer future, or later future..., or if its on the back burner due to some other roadblock other than the ones already discussed. Sorry if the answer to this exists, if it does a link to the most up to date discussion would be great :)
     
  24. ThatDan123

    ThatDan123

    Joined:
    Feb 15, 2020
    Posts:
    11
    Code (CSharp):
    1. /// <summary>
    2.     /// Returns the unity engine object or null if it has been destroyed. Useful for null coalescing or propagation.
    3.     /// </summary>
    4.     /// <param name="obj"></param>
    5.     /// <typeparam name="T"></typeparam>
    6.     /// <returns></returns>
    7.     public static T OrNull<T>(this T obj) where T : Object => obj ? obj : null;
    As a workaround we use this in our project just a little bit more work than putting ?, but it is safe to use and doesnt bypass the internal Unity checks.

    To use it's pretty simple:

    Code (CSharp):
    1. //Example
    2.  
    3. if(exampleGameObject.OrNull()?.GetComponent<Script>().OrNull()?.Field != null)
    4.  
    5. //Or like this
    6. var thing = otherThing.OrNull() ?? alternateThing;
    7.  
    8.  
    Though obviously it would be preferable if Unity did remake the system but that would i imagine take a lot of dev work.

    Actually thinking about wonder if it is possible to make a source generator to add the above OrNull() to any unityobject Null-Coalescing Operators check
     
    Last edited: Sep 21, 2022
  25. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    I don't expect that we will change this behavior soon. It is not on the roadmap for our current .NET Modernization work. As much as I would like to go back and change the original decisions here, we can't do that. I cost of making this change now is just too high.
     
    Katerlad and cxode like this.
  26. Katerlad

    Katerlad

    Joined:
    Mar 26, 2015
    Posts:
    17

    Thank you all for the quick Replys! I will consider that option as well.

    I was really just looking for one of the easiest ways to get a component reference in a script without doing the way alot of beginner tutorials do. which is declare your object, and then assign a reference to it in start.

    To Make it cleaner and one line we were looking at something like this.
    [SerializeField] Player player => player ??= GetComponent<Player>();


    So that it will only grab the component on the first reference to "player" and never again.

    So since Unity overloaded the == operator, we were thinking something like this would work.
     [SerializeField] Player player => player == null ? GetComponent<Player>() : player;


    Not sure if the second option poses any risks at all, since its using the overriden == I would think we should be in the clear it will check null objects as well for destroyed objects.
     
  27. ProtoTerminator

    ProtoTerminator

    Joined:
    Nov 19, 2013
    Posts:
    583
    That's not quite the same since you're not caching the GetComponent into the field.

     Player player => _player != null ? _player : _player = GetComponent<Player>();


    That's basically what
    ??=
    would expand to anyway (with the exception of the overloaded
    ==
    ). There are no risks with that code since it is using the overridden
    ==
    (in contrast,
    ??=
    is risky to use on Unity objects).
     
  28. Mindstyler

    Mindstyler

    Joined:
    Aug 29, 2017
    Posts:
    248
    You really should grab it in Start() and cache it in a property. Using nullcoalescing or a ternary may *look* 'cleaner' but you will pay a good chunk of performance since with every property access, you will have to evaluate a branching statement. And that is something you preferably want to NOT do.
     
    Eclextic likes this.
  29. Katerlad

    Katerlad

    Joined:
    Mar 26, 2015
    Posts:
    17
    Hey Thank you for the Reply! I was thinking that evaluating the Ternary wasnt going to be that much, but thinking about it. I guess Start really is the best, just once, and no evaluations each time the property is called. However I wish there was a feature in C# that is for caching things like this at declaration to make it cleaner.
     
  30. Mindstyler

    Mindstyler

    Joined:
    Aug 29, 2017
    Posts:
    248
    Well it's not really something you do all that much in normal .Net.
    Also it wouldn't be kind of challenging to not have branching in such a theoretical feature. I don't know exactly how unity decides when to call Start(), but there's likely still a if statement or smth on the engine side. It just get's called far less frequently than a ternary on the c# property would be.
     
  31. Saniell

    Saniell

    Joined:
    Oct 24, 2015
    Posts:
    191
    Except that branch is going to be predicted most of the time. Seems like premature optimization to me
     
    MasonWheeler and CaseyHofland like this.
  32. XJDHDR

    XJDHDR

    Joined:
    Mar 31, 2020
    Posts:
    27
    TBH, a lot of the performance penalty with doing a null check with a Unity Object comes from the null checking code making a call to the C++ engine side to see if the object still exists, even if it doesn't in C# land. If you do need a property that has such a check in it, my preference is something like this:
    Code (CSharp):
    1. public Player player
    2. {
    3.     get
    4.     {
    5.         if (!_playerExists)
    6.             _playerExists = gameObject.TryGetComponent(out _player);
    7.         return _player;
    8.     }
    9. }
    10.  
    11. private bool _playerExists;
    12. private Player _player;

    Edit: The above would obviously be for if you never destroy the object in question. If you do intend on destroying at some point, you would also implement logic to ensure that the backing boolean becomes false. Something like this, for example:
    Code (CSharp):
    1. set
    2. {
    3.     if (value == null)
    4.       _playerExists = false;
    5.    _player = value;
    6. }
    Edit 2: Also, I'm pretty sure that, when you have properties with backing fields, the best practice is to interact with those fields through their properties, not by directly accessing the fields.
     
    Last edited: Sep 26, 2022
  33. ProtoTerminator

    ProtoTerminator

    Joined:
    Nov 19, 2013
    Posts:
    583
    That's just as risky as null-coalescing, as once that Player object is destroyed, it will always return the destroyed object.

    Also, I think this has gotten off topic.
     
    Saniell likes this.
  34. Mindstyler

    Mindstyler

    Joined:
    Aug 29, 2017
    Posts:
    248
    Most likely not. Few branches are considered by the branch predictor for prediction caching. Mostly loops. Branches over scope switches will most often not be predicted.
    AND you are still always calling into native code each time you access the property.
     
    Last edited: Sep 26, 2022
  35. TreyK-47

    TreyK-47

    Unity Technologies

    Joined:
    Oct 22, 2019
    Posts:
    1,816
    Agreed. Gotta steer this back to the topic at hand, but feel free to create a new thread about this if you want to keep the convo going. :)
     
  36. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    610
    So what you're saying...

    Code (CSharp):
    1. private Rigidbody _rigidbody;
    2. public Rigidbody rigidbody
    3. {
    4.     get
    5.     {
    6.         for (int i = 0; i < 1; i++)
    7.         {
    8.             return _rigidbody != null ? _rigidbody : (_rigidbody = GetComponent<Rigidbody>());
    9.         }
    10.     }
    11. }
    My 2 cents: look, if you're really concerned with minute optimizations like these then you shouldn't be using Unity in the first place / program in ECS. In my experience I have never had performance issues because I'm doing the null check and if you have this issue because the component is used in 100.000 places then there's bigger ways to optimize, e.g. Job System.
     
  37. Mindstyler

    Mindstyler

    Joined:
    Aug 29, 2017
    Posts:
    248
    What you just did is far worse and does not help with branch prediction. Also, this whole thing is NOT premature optimization.
    I am indeed mostly programming in ECS, but that was not the point here, because there was someone who was asking about this code(not me). Now there is a correct solution and other much worse solutions. No need to drive this further.
     
    Energy0124 and Huszky like this.
  38. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    610
    That was kinda the joke though
     
  39. sam_paladin

    sam_paladin

    Joined:
    Oct 5, 2021
    Posts:
    12
    Hey, question.

    If I understood correctly Unity 2021.X now supports ..NET Standard 2.1 so in theory, http/2 is included here. Using grpc-dotnet now should work as intended.

    Has anyone tried this out?

    Regards.
     
  40. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    Unfortunately HTTP/2 is still not supported, as the underlying implementation of the Base Class Libraries is from the mono/mono repository, where HTTP/2 support does not exist. I'm expect that we will have support when we move to the Base Class Libraries from the dotnet/runtime repository, but I don't have an ETA to announce for that yet.
     
    cxode, sam_paladin and Thaina like this.
  41. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    Status update time!

    It has been a while since we've given a general status update, but that is not for lack of progress! For the last few months the team has been focused both making the Unity marshaling code safe for use with the CoreCLR GC, and getting the internal Unity test suites to pass with the CoreCLR scripting backend in a Unity player build.

    I'm happy to report that our first large test suite is now passing on a nightly basis in Unity's main branch! Over the next few months we will continue to enable test suites and complete the work to make Unity's managed/native boundary safe to use with a precise, moving GC.

    In this process we've also discovered more problems that we need to tackle. It looks like we make have the entire problem space mapped out now, so we're focused on execution to make the CoreCLR player a reality. With that additional work though, we also have more uncertainty about when we can ship any of this work and support it long-term, so I'm not ready to make any announcements about release dates.

    We're continuing work, and I'll drop updates here as we cross internal milestones. Thanks!
     
  42. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    223
    Hey Josh
    does any of those internal tests include performance metrics? We all know that .net6 is a lot faster than unity mono in general terms but I'm really curious in how the engine responds.
     
    cxode and ErnestSurys like this.
  43. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    Unfortunately no, we've not been able to compare performance just yet. We don't yet have enough of the code GC safe yet to run our normal performance tests, so I don't yet know about end-to-end performance

    We have done some targeted profiling in cases where we can test, and the results look promising. Sorry for the tease, but I don't have any data that I can share publicly yet. I can say that the increased performance in .NET6 and later is paying off.

    We're planning to have some more formal numbers about early performance data in these targeted cases in an upcoming Unity blog post. I'll be sure to mention here when that is published.
     
    stonstad, DrummerB, Nad_B and 19 others like this.
  44. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    610
    Hype

    Quick dumb question, but when you are talking about .NET6, in theory that should mean .NET6-and beyond right? The way I'm reading it is you're focusing on .NET6 as that includes .NET7 (and depending on release time .NET 8) for free anyway.

    Especially .NET7 Linq improvements will be exciting for my own rampant use of that library :3
     
    Nad_B likes this.
  45. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    Yes, I should be clearer. Our goal is to stay up to date with the latest .NET code from the dotnet/runtime repository.

    Since we're in development at the moment, we're not pinning to a specific .NET version. At the moment our fork of dotnet/runtime is synced to the upstream repo as of August 8 (you can follow it here https://github.com/Unity-Technologies/runtime).

    We actually were into September, but ran into a few issues around problems with some new frozen heap APIs, so we backed off a bit and need to circle back to implement those properly.

    Once we are ready to release supported Unity builds that use .NET, we will pin to a specific .NET version (e.g. 6, 7, 8 depending on timing). Then we will plan to release an updated Unity version with the latest .NET version when Microsoft releases a new .NET version.
     
    eterlan, Nad_B, SpencerGR and 26 others like this.
  46. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    610
    Something else: where is async on the planning?
     
    bdovaz likes this.
  47. simon-ferquel-unity

    simon-ferquel-unity

    Unity Technologies

    Joined:
    Apr 1, 2021
    Posts:
    67
    Async/await support does not need CoreCLR, and 2023.1 should bring support for:
    - Ability to await on frame events (NextFrame, EndOfFrame, FixedUpdate,...)
    - On any UnityEvent
    - On any AsyncOperation
    - On GPU read callbacks
    - a custom async compatible return type "AwaitableCoroutine" specifically tailored for use in Unity (a bit more efficient than Task, with continuation scheduling more fitting game development and heavily using object pools to limit allocations and GC pressure)

    The implementation is done and waiting in our merge queue. Still need some work on docs :)
     
    mh114, stonstad, LuGus-Jan and 28 others like this.
  48. goldbug

    goldbug

    Joined:
    Oct 12, 2011
    Posts:
    766
    That's pretty awesome!, is it comparable to UniTask?
     
    Nad_B likes this.
  49. MiTschMR

    MiTschMR

    Joined:
    Aug 28, 2018
    Posts:
    482
    I hope we get examples to showcase some of these features. Really looking forward to it!
     
    Nad_B likes this.
  50. JesOb

    JesOb

    Joined:
    Sep 3, 2012
    Posts:
    1,106
    Is it names actually AwaitableCoroutine or Unity found a better and shorter name?
    May be UTask, UnityTask etc
     
    Nad_B, M_R, tomfulghum and 7 others like this.