Unity Future .NET Development Status

Coroutines is exactly asynchronous, may be you want to say parallel
Task is asynchronous too, not parallel programming

Technically it is possible to make continuation of Custom UTask to know about GameObject and just delete continuation if GameObject was died. Will be useful for UTasks that actually linked to GO

 

From what I remember UniTask (that's main threaded) allocates less than coroutines. Main difference: Coroutine is a class, UniTask is a struct.

In UniTask you just do .WithCancellation(token) on await. In Net 6 there's similar .WaitAsync method https://docs.microsoft.com/en-us/dotnet/api/system.threading.tasks.task.waitasync?view=net-6.0 . Ye, a bit more code but better and explicit flow control.

I replaced all coroutines with UniTask in my project. Very happy with it, I doubt I'll use coroutines ever again.

 

Also unitask exposes a way to create cancellation token from a gameobject which will cancel on destroy

 

I think it would be better to split the discussion about tasks to its own thread to avoid cluttering this one. What you think @hippocoder @zombiegorilla ?

 

JoshPeterson You missed a question on HTTP2 support by turanmeric on page 16.

 

You missed my question @JoshPeterson. Looking forward to your answer.

 

@JoshPeterson, my question wasn't answered too. Would be glad to get any thoughts on this

 

The real question is though: will HTTP/3 be supported with the switch to .net core?

 

With the advent of System.Numerics and its introduction into Unity, is there a reason we'll need any of Unity's basic numeric types for anything besides compatibility? If we're talking about moving Unity in line with the rest of .NET, I wouldn't mind seeing that namespace used more often.

 

I also want to use `System.Numerics` instead of unity ones too. Also in C# 11 there was INumeric interface that I would like to make generic function for them. I wish unity would adopt that to their types

 

Yes please. A switch to System.Numerics would be incredibly awesome.

 

Please, no. System.Numerics API is completely different from Unity's API. That would break every project.

 

I don't expect fundamental UnityEngine types like Vector2, Vector3, etc to be replaced (as much as I would like them to be), but even if they were: it's something that is trivially solved by Unity's automatic upgrader (precompiled DLLs are a bit more complex, but it's still a solvable problem). That said, at least having support for the System.Numerics namespace would be a godsend, we can use them currently but they don't benefit from hardware acceleration (something that we will eventually get "for free" with the move to CoreCLR.)

 

It shouldn't be removed or replaced. But it should just compatible. Or at least, like `float2` in mathematic package, can be implicit convert everywhere. And should just add some API to support it directly if needed

Also many functionality should just become `in this` extension method and so it would be able to extend instead of cramming it in the main struct

 

Just out of curiosity, do people prefer System.Numerics or Unity.Mathematics, and why?

Personally I like mathematics more since 1. optimized, SIMD, clear annotation and 2. Unity has control over it, which means they can add more 'gamey' methods (e.g. fastinverse) that you might not see in a standard package.

To be honest I would switch over to Unity.Mathematics full stop if it became part of the engine, right now I don't want to force people to import it.

 

Unity could easily add anything 'gamey' to System.Numerics when .net adds this: https://github.com/dotnet/csharplang/issues/5497 then there would really be no point in keeping Unity's Vector3, etc... around.

 

Unity.Mathematics is better in term of pure usability but it could be used only in unity environment. While System.Numerics is standard in various field of dotnet application. Such as pure math or physics research. We could copy code from other codebase into our project and use it as is. So both have benefit and I use both

What I want is to use `System.Numerics` in place of UnityEngine.Vector3

 

Hey, thanks a lot for the response. I believe it would be the best to, perhabs, disable those checks on per assembly basis. Same way you toggle unsafe C#

But I would be happy to see this feature in any way, really

 

I'm not asking you to disable it by default. All I want is option for me to do it in my own assembly. Not even whole project.
Bacause, well, maybe I'm doing my own update manager and I want certain objects to be multithreaded.

Maybe I'm saving the game and want to write many objects and they just happen to need Get Component or simple GameObject.name call
Maybe I want to construct command buffer entirely on another thread and then submit it

You, as an engine, can not guarantee that what I'm doing is safe. But maybe I can, and I do not want to open forum thread for every single time there is an issue
As I said earlier, burst allows to disable practically any checks by using attributes. I see no reason why there can not be an option for advanced users.
It's not even a default. It shouldn't be

 

1) How about just tell your teams not to use it ever if you would have such a big problem.
The tool must not get in a way of a developer, this is literally what Mike Acton said on unity channel talk (5:10 timing)

2) Somehow changing memory allocation settings of the editor itself is allowed, yet guarded heavily so you won't do it by accident and probably be hesitant to touch it out of curiosity. UI can always be figured out. That is not a real problem

3) Now I wonder how adding single && to an if statement is a structural change worthy of source code license

 

Dots?

 

Well, if technically it is indeed problematic then too bad. Then I would recommend at least going through your APIs that do only reads and at least do something about them. Like Application.productName, it is actually read only. But I still have to cache it so writing to a file doesn't have to go to main thread, get this name, and go back ti actually do the job.

Also, can't I know that noone changes camera when I call that method? Because unless CalculateFrustumPlanes itself somehow writes to camera, it shouldn't change.
Though now I agree that's a bad example since I actually rewrote it not because of safety, but to use Span and more generic parameters instead of reference to a real Camera, my apologies.

Well, I sure want to rewrite my whole game because of few things that could be multithreaded. As soon as DOTS is also actually production ready, of course.

I will hope that Hybrid DOTS will make things better, but relying on unity to release new stuff has not worked out for me so far

P. S. Also, it's not cool to use dots as an excuse for not doing anything about GOs. It's pretty obvious they are not going away any time soon

 

Perhaps you could introduce a whole lot of implicit conversions and overloaded methods and support both options for a while? You might also need to introduce a special case into the serializer to ensure that Unity-styled math structures (with lower-case coordinates of

x

,

y

,

z

, and

w

) are seamlessly changed to standard-styled math structs (with upper-case coordinates of

X

,

Y

,

Z

, and

W

).

Then keep an eye on how people use and talk about them; when projects that use the "standard" math types become more prominent than the ones that don't, it's probably time to sunset the older ones. Types that have no equivalent in

System.Numerics

(like

Vector2Int

) could remain as-is. Or, if you're feeling bold, you could contribute them upstream to be a part of

System.Numerics

. Unity has some pull in the .NET committees, right?

Of course, no Unity math structures should be obsoleted until at least the end of the last LTS line to not provide

System.Numerics

(which I think will be the 2020 series). So, probably about this time next year.

 

One other item of feedback I'd like to give about packages; right now, Unity's current package system can be easily used for non-code assets. It's not common, but it's possible and easy. Please keep it that way.

 

There is one parallel programming pattern where it's possible to guarantee thread access safety: parallel for loops. In such scenario, no main thread Unity engine code will be running and can't write to anything, since the main thread will be blocked waiting for the other threads to complete their work.

A special type of ParallelFor job which forces the main thread to block until the job is completed when scheduled could be usable for some Unity object read-only access. Any method that only reads data and doesn't write could potentially be used in such cases.

The C++ side already pays the cost of an if/else/throw on each one of these methods. Getters and methods deemed read-only could be guarded by a separate flag telling if they should do the thread check or not. Add a method to toggle this flag on/off from the C# side, but don't make it directly available for users: instead, make it be used internally by this "IParallelManagerForJob", which disables the checks when it starts and enables it when completed.

 

In the end, all of that would still be kindof a 'hack'. Don't get me wrong, I'll take it, but I think the best solution would be if we could write our own Serializers. And obviously I don't mean OnBeforeSerialize and OnAfterSerialize, I mean writing a script that lets us serialize any type we want.

I came across a case where I wanted to serialize DateTime (and TimeSpan, but that didn't exist in Unity's C# environment yet). I opted for the simplest solution, which was writing my own serializable "SerializedDateTime" type that could convert from and to DateTime. It's... dumb. It works, but it's dumb. I would much rather just have had a way to serialize DateTime without having access to the actual script.

 

See https://github.com/dotnet/runtime/issues/24168 this would be the equivalent of Vector2Int, just Vector2<int> which gives far more flexibility. Also https://github.com/dotnet/Silk.NET/tree/main/src/Maths/Silk.NET.Maths was created as a performant generic maths library for engines, so could be an option (already works from netstandard2.0 - net6.0 so good compatibility and is part of the .NET Foundation).

 

Couldn't you just use IObservable<T>, at least from a managed side? This gives you the flexibility to decide the threading model on a per subscription bases and not one size fits all. Microsoft make heavy use of it throughout the framework.

 

Good documentation is incredibly important.
One of the best part of .NET is the comprehensive open-source documentation!

Using only MSDN, I can learn almost any technology, get 99 percent of the information. You can get all the details except high-level architecture and low-level questions (there are roslyn/runtime repos on github for that)

But in the unity world...
You have to do it all the time for an interesting property/method/class:

1. Read XML-doc in IDE
2. Read Unity Documentation. Often it's just one sentence.
3. Search topics on Unity Forum/Unity QA/Unity Learn/StackOverflow to find any useful information.
4. Search user blogs on web to find corner cases and how to correctly use it.

Most of the topics were created several years ago.
Some things are outdated.
Some things don't work anymore.
Some things can be done much better with the new API.

Lots of API are almost not documented. Users on the forums are experimentally trying to understand what it is. Other users are reading this thread, but is the information correct, or was it only correct for a few alpha versions from five years ago?

Even the Unity Manual which is the face of Unity contains typos, outdated parts, inconsistent code quality with bad smells. One page explains what a vector is, another briefly lists dozens of settings (especially Graphics sections).

Please move the core and packages' Manual & Documentation to github. There are users who will improve the documentation. Github has a history of changes and PR discussion, which is also increase quality of docs.

MSDN has an auto translation with manual correction, which will also improve the accessibility of Unity.

 

Agree with above. Maybe unity would be better if everything that could made into package would be opensource and accept pull request. I know unity has release its code only for premium license but some of unity source code are obviously not a secret

 

I would like to second this. We should really have a Task object to watch the status on things like start and Awake functions. That way we can make code respond correctly to the asynchronous initialisation of Unity Objects (e.g. await the Awake task before starting an update function).

 

Nevermind that! Show the docs team what a great success this thread has been and encourage them to start a discussion about this! That way the community is actively involved in getting the community actively involved!

 

can you do it also for Webgl Csharp/cpp wasm, in future for webgpu, C# Webgl2 netcode multithreading support.
8core Devices 8 or logical 16, its not enough to use only 1 Thread, in Webgl.wasm; let mono/ms +threads.

 

In that talk it was mentioned that you can force the CLR to layout fields the way you want, but it seems that may not be the case for SequentialLayout. https://github.com/dotnet/runtime/issues/63474#issuecomment-1087332123 claims that if the struct contains any reference types, the CLR will ignore the sequential layout and switch it to auto layout. You may want to clarify that with Microsoft before you forge ahead with that assumption.

There is also an old StackOverflow answer that described how SequentialLayout was not behaving as it should. https://stackoverflow.com/a/24744714/5703407 That was in .Net Framework, but it seems that was carried over to Core. That particular issue is probably not relevant to the work you're doing, but I thought I should mention it, since you seem to be relying on SequentialLayout.

 

i know that you can't provide dates on the transition, but can you tell us if we can expect the .csproj workflow only after the .net transition or might that even happen before the transition? because sdk style .csproj is also available for .netstandard projects

 

Just tell people not to update to the latest version beyond a certain point when it is implemented, normally when you finally commit to a project you should NOT be chasing the new latest game engine versions anyway - thats on the developers not Unity. Don't hold the rest of us back because some people foolishly update their game engine to a major new release mid way through a project and are surprised stuff breaks - that is expected and they should read the release notes before they commit to updating.

There is many things that should've long been replaced but has stuck around to avoid breaking projects, but that leads to slower advancement. We still have a Text and TextMeshPro side by side in the UI components and have done for years for example when Text should've been yeeted long ago - no reason for it to stick around.

 

We actually do this for a variety of reasons. Mainly that we're using bleeding edge features like UIToolkit. That being said, we don't mind upgrading through breaking things either!.

One thing that definitely needs a feature identical update is the legacy animation system. Currently as I understand it there is no other way to create animations at runtime however. All other solutions rely on Editor support.

 

Well there is one coming for DOTS but I don't recall a new one coming for regular game objects on the road map?

 

There probably isn't one coming either. It seems runtime animations aren't something a lot of people do and if they do then its apparently mostly with the legacy system (as there is no alternative anyway). Anyway let's not get this too off-topic. Point is, we'd be happy to break our project if we get these fancy new toys as a result.