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. ProtoTerminator

    ProtoTerminator

    Joined:
    Nov 19, 2013
    Posts:
    583
    Care to share the code?

    Again, care to share the code? If the solution is to pass down a cancelation token, then I agree, it's easy. But that's exactly what the other person was arguing against.

    It seems like you skipped the part about performance. Bad performance is bad for games. (Though there are third-party Coroutine packages that improve performance over built-in Unity Coroutines...)
     
  2. a436t4ataf

    a436t4ataf

    Joined:
    May 19, 2013
    Posts:
    1,924
    Most of the cases where we use coroutines performance is entirely irrelevant (for me the main exception is when using them to quickly throw together a scripted animation - performance matters there, but only in a small way: I don't want to lose 60 FPS just because of a crappy primitive, but I can't remember coroutines ever being the limiting factor there).

    If I'm going to do something performance intensive I'll be using a different paradigm. My argument is: coroutines are excellent for general Unity game development, I'm not making a claim on performance-intensive operations (where they can work - I've sometimes used them for that - but personally I'd normally go with something that's more effort to code, more effort to maintain, but lower overhead).
     
  3. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    1,157
    @a436t4ataf Every things about CoRoutine you argue can be done in the same way as `async`/`await` and better because it would be more sensible. Instead of `yield break` which is unfamiliar for most people you can just `return` for example
     
  4. TheOtherMonarch

    TheOtherMonarch

    Joined:
    Jul 28, 2012
    Posts:
    862
    We stopped using coroutines years ago and switched to using Update() based timers. At this late date single-threaded asynchronous programming for game logic is rather dubious. Synchronous Update() based times that trigger either single or multithreaded code is a better architecture.

    For a GUI "async and await" still have a place and are superior to Unity coroutines. Unity coroutines just needs to go away.
     
    Mindstyler likes this.
  5. ScottKane

    ScottKane

    Joined:
    Aug 24, 2019
    Posts:
    81
    Use MSBuild4Unity, that will give you the ability to use and modify a csproj file for your Unity project which can then just take a dependency of a regular source generator class library project. This sample project I was playing with isn't perfect but should get you off in the right direction: https://github.com/ScottKane/MSBuild4Unity-Sample

    Assets/Game.Dependencies.msb4u.csproj is what is injected into your Unity auto generated solution and will do this for you on rebuild, it contains any other dependencies your project might have, just use it as the csproj for your Unity code that you are able to edit.

    Source/Game.sln contains a custom project referenced by the msb4u.csproj (this could be your source generators). You can also add nuget packages to the .msb4u.csproj and they will be available in your Unity code, nuget packages used in projects in Game.sln will function as normal so you can just use nuget. Hope this helps.
     
    Last edited: Jun 24, 2022
    kerjemanov likes this.
  6. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,085
    Thanks for this long explanation but I don't want to use any plugin that may break with Unity updates. I had some issues with for ex. NuGetForUnity that made me waste some time fixing it.
     
    Last edited: Jun 25, 2022
    antosond and Harry-Wells like this.
  7. ScottKane

    ScottKane

    Joined:
    Aug 24, 2019
    Posts:
    81
    Sure, it's not likely to break until Unity moves to .NET Core as it doesn't actually do anything with code, it just hooks into the Unity build system and runs some extra MSBuild jobs to pull all the DLL's into Unity for you under Assets/Dependencies. I've upgraded my project through the past year or so of engine versions without any issues. The only thing I had to do was make it target netstandard2.1 (the version of MSBuild4Unity in my git repo) as the version on github (https://github.com/microsoft/MSBuildForUnity) was built when Unity only supported netstandard2.0 but that's not going to change again now.
     
  8. hummer_4x4

    hummer_4x4

    Joined:
    Feb 3, 2013
    Posts:
    25
    I have my own script for MSBuild that builds the build. The only drawback is the long compilation of scripts by Unity engine.


    Transferring the build, customization and integration of external projects with the Unity project. Now I can configure directly in the Unity Editor how it should work. And it also supports automatic mode when you press the Build button in VS Project.
     
    Last edited: Jun 29, 2022
  9. PetrisPeper

    PetrisPeper

    Joined:
    Nov 10, 2017
    Posts:
    66
    I've noticed this:
    The IL2CPP scripting backend will now always generate fully shared versions of all generic methods. This will allow use of generic type combinations that are not present at compile time to avoid a whole class of difficult-to-detect errors that can occur only at runtime.
    while reading https://blog.unity.com/technology/unity-20221-beta-is-now-available-for-feedback.
    Does this mean that IL2CPP does no generic specialization at all now? Even on value types? If so, this is going to be terrible for performance.
     
  10. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    No, by default IL2CPP generates unshared generics for value value type generic parameters. This new feature in Unity 2022.1 means that is _also_ generates a fully shared version that will work (but is slower at run time) for cases there it could not see the value type generic argument at compile time.

    There is an option in the Player Settings to _only_ generate the shared version for value type generics. That option is disabled by default, but is an available for projects that want to favor smaller code size and faster build times.
     
  11. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    610
    That seems kinda overkill. I’d say this is up to the developer to decide the best way to deal with it.

    I would rather Unity added an attribute that I as a developer can throw on generic methods for if I want THOSE methods to generate shared versions, rather than build-bombing my entire project. This attribute can then be referenced in an error log if it ever occurs.
     
  12. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    We found that the code size cost for these additional full shared generic methods was trivial for most projects.

    Emitting them in all cases allowed us to remove a good bit of other code (both during code conversion and in the runtime), since we now have eliminated an entire class of errors (the ExecutionEngineException). Additionally, I don't think most users are aware of which generic methods would need this attribute, and communicating that correctly would be difficult.

    So we judged this change to be very low cost (code size) and useful (elimination of a class of runtime errors). That is why we enabled it across all projects.
     
  13. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,085
    I'd say opposite, il2cpp should "just work" in all cases. Additional header could be there as an option disable full generic version for advanced usage.
     
  14. PetrisPeper

    PetrisPeper

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

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
  16. PetrisPeper

    PetrisPeper

    Joined:
    Nov 10, 2017
    Posts:
    66
    JoshPeterson likes this.
  17. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    610
    A buddy of mine just told me about Generic Math in .NET 6 (or Generic Maths if you're English) and I'm instantly excited.

    I was hoping that
    A: Unity.Mathematics will implement this. (You can already do float4 + float so it shouldn't be a problem).
    B: Unity Vectors will implement this. (Things like Vector4 + float would need to be considered and implemented).

    I'm really on board with this idea of writing these highly flexible methods and I would love to apply this strategy in some of my packages, but for that conversion to work both Unity.Mathematics and Unity Vectors would need to support it.
     
    Qbit86 likes this.
  18. runner78

    runner78

    Joined:
    Mar 14, 2015
    Posts:
    789
    Generic Math is just a preview feature in .NET 6 but should make its way into .NET 7.
     
    Qbit86 likes this.
  19. Qbit86

    Qbit86

    Joined:
    Sep 2, 2013
    Posts:
    487
    It would be great if standard System.Numerics.Vector3 also implemented some of the Generic Math interfaces.
     
  20. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    610
    Hi @JoshPeterson I'm unsure how much you'll be able to comment on the massive layoffs that just happened at Unity... to be really pragmatic, I would like to know if your engineering team has been hit by this?

    Sorry about anyone they let go you were close with.
     
    Last edited: Jul 3, 2022
  21. DevDunk

    DevDunk

    Joined:
    Feb 13, 2020
    Posts:
    4,969

    .NET 7 will have great performance improvements for reflection, which is used a lot in Unity!
     
    Tanner555, Thaina and CaseyHofland like this.
  22. Mindstyler

    Mindstyler

    Joined:
    Aug 29, 2017
    Posts:
    248
    Generic math in particular is currently only meant for number types, which vectors are not, which is also why
    will not have generic math interfaces applied for the time being.

    Furthermore, Unity.Mathematics is designed to not use operators and instead use simd-like methods like math.mul() and similar for all operations. So adding 'generic math' would not make any sense from my viewpoint.
    What unity *may* add and *may* be useful would be the feature generic math builds upon: static abstract members.
     
  23. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    610
    That's actually why I thought it would be great. The team could simply make math.mul() a generic method taking an INumber (or rather an IMultiplyOperators). I see no reason why this wouldn't be simd.

    Fair enough though, vectors aren't numbers. I wasn't thinking and forgot that whilst
    float4 += float
    is solveable,
    float += float4
    is impossible. Or undefined? I dunno, whichever mathematical term is more apt.
     
  24. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    1,157
    Generic math is actually a just special extension of the bigger new feature, static interface. And it was unity's responsibility to adopt it (after update dotnet version or switch to comply to dotnet ecysystem completely). It just that unity's type must implement static function and overload operator with generic interface with static declaration, which don't really care about it being a math or number class at all

    This is actually could be a killing feature in C# based framework for many design pattern to just work with generic static interface and demand any static functionality of the developed class
     
    Qbit86 likes this.
  25. Qbit86

    Qbit86

    Joined:
    Sep 2, 2013
    Posts:
    487
    It's not meant only for number types, it can work for any type that implements any of Generic Math interfaces like IAdditiveIdentity<TSelf,TResult> or IMultiplyOperators<TSelf,TOther,TResult> [1]. And vectors are perfectly fine.
    Tanner Gooding from Microsoft said: “its something being looked at for a future release of .NET» [2].

    [1] https://docs.microsoft.com/en-us/dotnet/api/system.numerics?view=net-7.0

    [2] https://twitter.com/tannergooding/status/1542994277155803136
     
    CaseyHofland and Harry-Wells like this.
  26. Mindstyler

    Mindstyler

    Joined:
    Aug 29, 2017
    Posts:
    248
    yes, which is why i said
    And yes,
    as i said, it may be worth exploring.

    This i already talked about as well. Still good to have elaborated on it a bit.
     
  27. gllebede

    gllebede

    Joined:
    Jul 7, 2022
    Posts:
    2
    I've made a proof-of-concept application that fetches nuget packages from nuget.org and repacks them into NPM packages. The package contains .netstandard2.0 dlls from nuget package and a package.json file that has package description and dependency references.

    This worked really well. For example, I can fetch System.Text.Json and the Unity brings in System.Buffers, System.Memory, etc.

    Would it make sense to publish NPM packages while NuGets are not yet easily consumable?
     
  28. Huszky

    Huszky

    Joined:
    Mar 25, 2018
    Posts:
    109
    https://github.com/xoofx/UnityNuGet
     
  29. gllebede

    gllebede

    Joined:
    Jul 7, 2022
    Posts:
    2
  30. MasonWheeler

    MasonWheeler

    Joined:
    Apr 2, 2016
    Posts:
    219
    Please don't. NPM is garbage; the last thing anyone needs is more of it!
     
  31. skyake

    skyake

    Joined:
    Jun 7, 2019
    Posts:
    11
    I just did some benchmarks against C (MSVC compiled with -O2), .NET 7 and Mono, and got this interesting result:

    upload_2022-7-9_16-32-54.png

    Benchmark code for C# is a re-transcription of C.

    Note that in some test cases .NET 7 even performs better than C, while mono is always the slowest one.
    As for the "Seahash" test case, the C compiler managed to evaluating the result at compile-time so the benchmark result for this case is invalid.
    I believe switching to coreclr will bringing major performance boost for Unity.
     
  32. TheZombieKiller

    TheZombieKiller

    Joined:
    Feb 8, 2013
    Posts:
    265
    You should provide the code you used for the benchmark, otherwise these results are unverifiable. There are also a lot of tricks you can use in .NET Core to get the most out of the JIT, so it can likely be improved much further.
     
    antosond likes this.
  33. hummer_4x4

    hummer_4x4

    Joined:
    Feb 3, 2013
    Posts:
    25
    JoshPeterson, Can you tell me why DOTS is very much from the coming new versions of Unity, we can expect that DOTS will be available by default in alpha 2023 ?
     
  34. jiraphatK

    jiraphatK

    Joined:
    Sep 29, 2018
    Posts:
    293
    Tanner555 likes this.
  35. JesOb

    JesOb

    Joined:
    Sep 3, 2012
    Posts:
    1,106
    The same but with il2cpp and burst
    upload_2022-7-10_1-59-38.png
     
  36. skyake

    skyake

    Joined:
    Jun 7, 2019
    Posts:
    11
    I'm using nxrighthere's benchmark code with a few modifications to adapt new .NET features.
     

    Attached Files:

  37. R1PFake

    R1PFake

    Joined:
    Aug 7, 2015
    Posts:
    533
    I hope they will integrate the "official" .NET 6 / 7 runtime from MS and make it easy to just use never versions of .NET and C# in the future once they are released by MS and not their own Unity specific fork which will be outdated again soon after they release it.

    It looks like this is their plan (from reading the last few pages) but I hope they can do it and no showstopper shows up which forces them to use a own fork.

    Tbh the change to .NET 6 / 7 is what Im looking forward the most in Unity, I don't care about most other things they add until this change happens (oh and world scale support for the new UI system would also be nice, otherwise it can't be used for any VR project, but that's a different thread)
     
  38. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    Thanks for asking - our engineering team was not directly involved.
     
    spamove and Qbit86 like this.
  39. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    Sorry that I missed most of the discussion about .NET math function performance - I was out of the office on vacation for a bit (but I'm happy to be back now!).

    There have been a few similar discussion threads around the forums here over the last year or so around math function performance in Unity, both because it matters for pretty much every application and because it is fun to benchmark and optimize :). I'lll try to make a few general points about our thoughts here, and hopefully answer some questions.

    TL;DR Use Burst and Unity.Mathematics for the best numerics performance with Unity.
    • In Unity 2021.3 we shipped some improvements in UnityEngine.Vector3 and friends to fix some low-hanging performance fruit, especially around proper use of aggressive inlining with IL2CPP. I don't know of any current efforts in Unity to make additional improvements that are happening now.
    • If you are looking for the best run time performance out of math/numerics, you definitely want to use Burst and the Unity.Mathematics package - that is where Unity's optimization time and improvements have gone in the past. As the benchmarks @Jes28 showed, the numbers for that combination are usually as as good or better than all of the other options (with a few caveats).
    • The new APIs in .NET 7 are really exciting - I do expect Unity to take full advantage of them in the future. But to be clear, that future is a few years away. We need to get the Unity editor running on CoreCLR before we can require .NET 7 everywhere in Unity. Once that is complete, we will look at a path to migrate to newer/better math APIs.
    Let me know if I've missed any other points/questions in this summary.
     
    Tanner555, LuGus-Jan, NotaNaN and 5 others like this.
  40. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    Check out the GDC talk from our team for more details about this: https://blog.unity.com/technology/unity-and-net-whats-next.

    Our strategy is to have a fork of dotnet/runtime (you can find it athttps://github.com/Unity-Technologies/runtime) while we are in development doing this work. We plan to upstream as much as possible. We don't want to maintain a fork long term.

    However, I don't expect user to ever be able to drop in a new .NET version to Unity. Unity is really a native application that hosts the .NET runtime, so it has many more points of coupling with the .NET runtime than a normal managed application would have. Our goal is to release a version of Unity with the latest .NET runtime and class libraries from Microsoft when Microsoft does though.
     
  41. Hertzole

    Hertzole

    Joined:
    Jul 27, 2013
    Posts:
    421
    For clarity regarding using Unity.Mathematics. Should we still use it even if we don't directly use Burst? Like in general, if I'm doing some normal position calculations and whatnot, would I just get "free performance" by just switching my Vector3 to a float3? I understand Burst greatly benefits from it, but will the normal mono/IL2CPP runtime also benefit from it?
     
    DragonCoder and NotaNaN like this.
  42. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    That is a good question. I would say in general no - Mono and IL2CPP are not optimized to work with Unity.Mathematics in the same way that Burst is.

    I don't see a benefit to using float3 instead of Vector3 for Mono and IL2CPP.
     
  43. ProtoTerminator

    ProtoTerminator

    Joined:
    Nov 19, 2013
    Posts:
    583
    What does that mean? Virtual generic methods with structs will work? What are the performance implications? Does it just treat the arguments as boxed objects? And does that mean invoking a generic method with reflection will always work?
     
  44. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    Yes - you can find a bit more detail about this specific case in the blog post here: https://blog.unity.com/technology/feature-preview-il2cpp-full-generic-sharing-in-unity-20221-beta

    Code taking the fully shared generic path is slower at run time. In general we're not using boxing in most cases (although in a few we need to). For the most part, the code uses metadata to get the sizes of types and then allocates memory on the stack in C++ and uses memcpy calls to move data around.

    Yes, it will!
     
  45. ProtoTerminator

    ProtoTerminator

    Joined:
    Nov 19, 2013
    Posts:
    583
    @JoshPeterson Awesome! What about generic types (structs and classes) created through reflection or through a fully shared generic method? That won't break? Is that where boxing comes into play?
     
  46. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    Correct, these cases will work as well. We try to avoid any additional boxing, although the full generic sharing implementation does involve the use of dynamic allocations on the stack, so it will suffer a performance hit vs cases where the generic types are known at compile time.
     
  47. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    610
    Hi ho! Checking in: will building to CoreCLR be available in 2023.1? I have a vague memory of CoreCLR Player heralded for 2023 some 20 pages ago.
     
  48. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    Hey, sorry that I've been quiet recently about this. I'm hoping to have a minor-ish update on our progress in the next week or so.

    I can say now that we won't have a CoreCLR player in 2023.1 though. We originally targeted that release, but at the time we were planning to use the CoreCLR GC in its conservative mode (which we used for internal prototyping with .NET Core 3.1). But that mode was removed in .NET 5. So instead we need to go the entire way to make Unity code work with CoreCLR's precise GC. We were planning to do this eventually anyway - the lack of the conservative mode simply changed our order of implementation.

    The direct outcome of this is that we needed to bypass Unity 2023.1 for release.
     
    Qbit86, NotaNaN, foonix and 13 others like this.
  49. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    610
    That's great news! I think a lot of voices in this forum agree quality is paramount.
     
    mariandev, JesOb, mischa2k and 3 others like this.
  50. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    Using the conservative GC mode wasn't so much a quality issue, as it was a performance issue (although you could argue those two things are not different). In the end we were always planning to ship the CoreCLR GC with it's full feature set enabled. Now the .NET Core folks have made the decision about when to do the work to support that much easier. :)