Unity Future .NET Development Status

For UI I would have loved if Unity had gone the XAML way in their new UI toolkit, exactly like this: https://www.noesisengine.com (they could've just bough it). It's a breeze to work with and VS already have the necessary tooling for it, along side the excellent Blend which could be used by UI designers. Just imagine how it's easy for developers to use ViewModels, data binding, RX and other goodness .NET developers are used to in WPF, UWP and Xamarin.Forms/MAUI.

 

Thank you thank you thank you <3

 

Isn't WebView2 only the windows specific implementation? I don't think you would get that on iOS or Android. Unity's UI toolkit is already converting web technologies into a cross platform "web view".

 

In MAUI there is WebView that's the version I meant, WebView2 is Edge and only for native window apps required, I got that mixed up.

There is no webView in UI toolkit, just because it uses a CSS-like style syntax with USS doesn't have anything else to do with web. UI Toolkit is closer to XAML, just with different style mechanism.

 

Still blazor could be used. When running blazor hybrid the code runs on the device not in the browser. https://docs.microsoft.com/en-us/aspnet/core/blazor/hybrid/?view=aspnetcore-6.0
Yes, creating a new browser render for each canvas would be a bad idea, but creating something like mobile Blazor Bindings for Unity where you can have custom elements which will spit out normal unity ui elements would be awesome. With the time and effort put into the UI toolkit it could be a really performant and easy to use system.

 

No, the rendering itself uses still the web view (browser), but the component logic run native and not in the browser .

 

No, mobile Blazor Bindings uses native element. https://docs.microsoft.com/en-us/mobile-blazor-bindings/ the blazor render ing engine is really flexible and can be used to Output anything not just html/css

 

HTML content ist still using web view, and otherwise you use XAML and Xamarin.Forms (MAUI in future) with razor syntax. And Xamarin.Forms are mostly wrappers for native OS controls.

 

I think you misunderstand my comments. Yes the Mobile Blazor Bindings project spits out xamarin.forms element from the razor representation. I proposed a new system which spits out unity ui component as the output. No ios/android/windows native code. Using html content could be restricted either at the framework level or through an analyzer error

 

Do you mean UXML it Razor syntax then? That might be more interesting.

 

Something like that. Use razor syntax with custom XML markup elements the same thing the mobile bings uses for native ui elements. Also create new layout elements which are more idiomatic for developers coming from other ui frameworks (tables anyone?) (html/xaml). The key point being that you use the razor syntax for this.
Obviously this would require a lot of work, but given that the experimental Bindings library was made usable with in 1.5 years by 4 devs at Microsoft, working on it part-time, I cant image unity could not do this within a year or two with a decent sized dev team.

 

That is exactly what I asked for in my original request, give us blazor for uxml/uss, if they can expand that capability to staright up allow html/css through blazor too. See

if you want to dig a little deeper into how the blazor component is rendered through maui.

But I think the best suggestion would be for the UI toolkit to have a "Blazor Element" component, which can be styled like any other uxml/uss element. Then the content rendered onto that element would come from html/css of a regular blazor app. That way the existing UI toolkit workflow can exist as is, while supporting those who choose to use blazor alongside or instead of the default workflow.

This is pretty much what Microsoft has done across WinForms, UWP, Xamarin etc. They just provide a component that can render the blazor dom. To be clear, I don't think we want maui, we want blazor for Unity UI.

 

Will this msbuild/csproj version of Unity allow us to specify our output with more control than we have now? I for example would like to have control over where my build output goes when building a player.

e.g All of my library dll's are output to /Build/Libraries, my own project build dll's are output to /Build/Binaries, with an exe in /Build.

Having this kind of flexibility in the player build system would be great.

 

Here lies the problem, HTML/CSS is always rendered with a "browser". The reason is simple: rendering HTML is too complex. Microsoft and previously Opera even abandoned their own HTML render engines.

It would theoretically be possible, e.g. for a main menu, but as I said, in my opinion something like this would not be suitable for games. I don't know the performance of Razor, but these technologies are designed for websites, they may be way too slow for gaming.

On the web, for example, SVG is also used and instead of HTML, the CMS that I use, for example, creates the page tree in the backend using SVG, and as far as I understand it, because it has better performance.

 

Also does Unity have any plans for a quantized mesh renderer akin to UE nanite?

 

Go watch the video I linked, you don't need a browser. This is how in maui you are able to work with native capabilities inside blazor. If it were in a browser you would be limited by the native capabilities exposed via the browser, which you aren't in maui.

 

Stay on topic or we will have to clean up the thread.

 

For the sake of getting maybe back on track, I didn't see the actual GDC Unity talk linked yet (which unfortunately has some audio problems but still worth the watch). While we wait on maybe a more in-depth blog.

 

Awesome news from the talk. Thanks Josh!

 

Good stuff. In a way I watched that video twice.

 

Thanks for sharing!
Great news by @JoshPeterson again. Nice to see so many technical details instead of marketing speak.

Sounds like a lot of sane decisions, like transitioning from custom asmdef to existing .csproj.
Really gives hope for the future of Unity!

---
Btw if you are on mac, you can slide output to the right speaker to make the video sound normal:

 

@JoshPeterson Thank you for the great talk on GDC. Everything you mentioned seems great, and I am really excited to see the future of the .NET development with Unity.

The only problem that I can see is with the package management you described. From the talk it seems that you still want to keep UPM around, and keep Unity code off of NuGet. I understand that Unity might find in uncomfortable to use NuGet as a distribution platform, but doing it in the described way just makes no sense to me. As it seems the UPM packages will still fundamentally ship plain cs files and assets, and the only improvement is to to the build pipeline. This means that instead of shipping dlls and assets, the shipped source files need to be compiled by the consuming project. Also it means that when you want to reference other projects distributed through UPM (which will happen all the time) you have two different ways to track versioning of dependencies, which makes an already hard task even harder.

I understand that you don't want to confuse people with publishing nuget packages only meant for unity but we already have this - in .NET 5 you can't consume framework packages or Xamarin, but everybody just accepted this and we are okay with it. Having 2 different package managing systems doing literally the same thing makes no sense and it also means that unity has to keep another team around to maintan UPM

 

@xoofx yes, thanks for the in-depth reply

 

In the GDC talk you mention the Unity CoreCLR Player with a Milestone of "Future".
Any chance we might get a more concrete estimate in the blog post?

 

I don't see the point of

AwaitableCoroutine

. Why not just make the Unity APIs return

ValueTask<T>

which can be implemented efficiently internally? Users can use the existing

Task/ValueTask

for their own async code, or other libraries that are already optimized for general async/await like

UniTask

and

ProtoPromise

. I think tutorials just need to start teaching

async Task

instead of coroutines.

[Edit] Also the guy that said async/await doesn't work on web, it does. It's just some of the APIs that use threads don't work (like Task.Delay)... Also hoping to get managed threads on the web at some point.

 

Btw, I am a fan of

CancellationToken

on Unity objects, but a better name might be

OnDestroyedToken

or something like that.

CancellationToken

itself is not descriptive of what it's for, and conflicts with the name of the type itself.

 

I second this. And if for any reason you have to make your own task-like construct, please rethink the name. I believe it would be wise to move away from the coroutine naming..

 

Unity please buy UniTask or use it as basement for your version.
UniTask already do it work good and have good short name please buy it or make your version from it as open as possible and name it UnityTask not AwaitableCoroutine nor SpecialCaseUnityTaskThatReplacesCoroutine!!!

We dont like long names they dont help to understand code

UniTask.Delay work everywhere because UniTask mostly is Async programming not parallel. It dont use threads under the hood. In My opinion UniTask actually better then .Net Task of ValueTask exactly because it make explicit distinction between asynchronous and parallel programming not fuse it together like Task do

 

We heavily use UniTask and in general async methods in our codebase. We don't use a single coroutine as the current interface for those feels very dated when async/await exists and performs pretty well already. So this sounds like a step in the right direction. I like the idea of implementing an even more optimized version of async/await handling in the Core of Unity, but please make sure it follows normal async/await conventions as much as possible.

Its good that you're already talking with @neuecc and I'm looking forward to seeing what the Unity implementation looks like

 

I think the direction Unity is taking now with the .NET Core integration and talking with other devs to improve the engine is very promising

 

We also heavily use UniTask and at this point, I don't know when I last saw a coroutine! What I especially hope for when it comes to your own implementation is that there will be no weird issues with threads. With UniTask, everything runs on the main thread but easily gives me the option to switch to some other thread using UniTask.SwitchToThreadPool() and back with UniTask.SwitchToMainThread(). It makes working with async/await a breeze! And the fact that it's so similar to normal .NET tasks makes it easy to convert to and you can use your async skills if you're working with UniTask or with normal tasks. No weird "Unity specific workaround".

I really hope Unity doesn't provide a stripped-down experience or something too custom to Unity. I would expect parity with UniTask at least!
I look forward to seeing what Unity has in store for us!

 

I totally agree, the Unity system needs to integrate seamlessly with existing async/await enabled libraries and core dotnet functionality. UniTask allows that already so its definitely doable and I really hope the customization is only the cherry on top and not a wholly different cake fingers crossed

 

I just downloaded Unity 2022.1.0b14 beta, and it seems that HTTP/2 is still not supported. Would you be able to share an expected date for HTTP/2 support for Unity?

 

Mentioning threading. In that GDC talk you said that no changes to thread-safe Api will probably be made, which is a shame honestly.
Can we at least get "I know what I'm doing and I don't mind crashing the engine" mode that disables such checks? Because it makes no sense to me why I can disable any safety checks when running Job/Compiling Burst, but unity still babysits me on managed side.

There are plenty of APIs that just read value or pure functions that aren't marked with this magic attribute. I'm pretty sure CalculateFrustumPlanes is/was one of those, for example. I want to get application name from another thread, what can possibly happen to it at runtime?
Or as another example, I know why GetComponent may not be thread safe, but if in my game, I do 100% know that when I call GetComponent noone touches that object, noone destroys component then why am I forced to be limited with no option to do what I want?

If being fast is focus of unity, then I believe you should do something about "non thread safe" nonsense

 

I'm also really interested in this for gRPC because as it stands we have to use Grpc.Web in Unity to fudge things over Http1. This doesn't support bi-directional/duplex streaming to my knowledge so has been a bit of a pain point.

 

Also I have been using UniRx as there is issues using the regular implementation of System.Reactive in Unity. Do you guys think the move to CoreCLR will mitigate this or is there some deeper problem as to why Observables don't work out of the box in Unity?

 

I have a question about async/await implementation showcased. In the video you have an example where you used async/await to call into Unity API functionality like WaitForEndOfFrame. Now, since Unity API is not thread safe, my understanding is that you either limit async/await to single-threaded model or these calls to UnityAPI actually just some syntactic sugar and it is compiled to some kind of co-routines calls in the end.
Regardless of what it is, though, in both cases this is becoming dangerously close to aforediscussed situation with null comparison operator overload. Through the whole talk it was stressed multiple time how one of the goals you want to achieve is bring development in unity closer to familiar, traditional .NET [C#] ecosystem dev. However, when we talk about asynca/wai in .NET development we usually talk concurrency and typical concerns that come with it: shared data protection, thread-context awareness, which is not the case for a given in the slides example since that would be executed on frame-by-frame basis on single thread.

 

@simon-ferquel-unity I did a deep dive on async method builders for ProtoPromise (similar to UniTask), and the way it works is it passes an

Action

to the awaiters for continuation. The awaiter handles how that

Action

is invoked, which could be from native code like you said. But how does that help with your custom async type? The awaiter controls the continuation, unless you use the builder to force continuation on the main thread like

Task

does with the captured context, but that's less efficient, and that still must be done on the managed side, so I don't see how it helps (and you already force the existing complete callbacks to invoke on the main thread).

That has nothing to do with

async AwaitableCoroutine

. If you await an

AsyncOperation

and it invokes the continuation from native code, it will do the same thing whether the state machine is an

async UniTask

or

async AwaitableCoroutine

. So what are you gaining there? You can't raise an

async AwaitableCoroutine

's completion from native code as you claimed, because it has to go through the managed state machine to run user code. It has to complete from managed code.

New APIs such as

EndOfFrameAsync()

don't have to return

AwaitableCoroutine

to invoke from native code. They can use any awaitable type you choose that doesn't necessarily have to work with the async keyword. In fact, I would argue that returning

AwaitableCoroutine

wouldn't even make sense, as that type screams "this is user code!" to me.

And of course your implementation would be more efficient than Task/ValueTask. That's why UniTask even exists, because Tasks aren't very efficient (though they have gotten much more efficient in Core than Framework).


I don't mean to be aggressive here, I'm just really trying to understand the real benefits of such an addition over UniTask. The only benefit I see is forcing all continuations on the main thread, which is really only a benefit for beginners, and Task already does that by default since you added the

UnitySynchronizationContext

.

Okay, maybe that's a real benefit? I admit I haven't worked with Burst, so I don't know if that would be useful or not. But you also said that hasn't even been talked about.

[Edit] Ah, I just realized you use the

AwaitableCoroutine

's builder to efficiently hook up to known awaitable types that Unity uses, like

AsyncOperation

, instead of passing the

Action

continuation through the interface. That makes sense and now I feel stupid about the rest of my post. But tbh,

UniTask

could do the same thing if you decided to work with them instead of creating one from the ground up.

[Edit2] If that is your optimization plan like I expect, you should check out another thread where I tried to do exactly that, but still saw boxing allocations in IL2CPP that you may want to fix. (I originally posted in this thread, but it was moved) https://forum.unity.com/threads/specialized-operation-inside-a-custom-async-method.1231227/

 

I wish ReactiveX like UniRX or System.Reactive would also come into unity system. Currenly now I have a hard time trying to get System.Reactive to work in unity

 

Totally agree on this, however we only need nuget just for using old library so it could be separate system altogether. Which there was already UPM that support source code import from git url. I wish you would focus on complete that feature (allow git package dependencies)

On the other hand I agree that next gen coding would be more welcome source code package everywhere. And I disagree that package that has been written in unity would only usable outside of the Unity ecosystem. There are many times I would like to split my code into be unity parts and utility parts. The latter could be useful anywhere and that's why I very need git package dependencies. So that I could distribute my utility code in one package and have my other package also rely on it

 

I don't understand why having Unity source included in projects isn't optional. e.g if I want to be able to modify sources, enable a checkbox that uses UPM, otherwise pull in precompiled from Nuget. While I agree that the use case of modifying engine code exists, I think it represents a much smaller section of users. I have no need to modify any of it, so why am I paying the compilation cost for something I don't need. Should always be opt in.

 

Because even if you don't modified it, recompile it give many benefit such as preprocessor directive per platform/condition. And debugging. Also you can learn and investigate the internal process and how to shape the parameter when calling API if there was any problem

And the catch here is, unity also try to cache the compiled of package for you. So you just compile it once when you import and you will get the dll cached locally if possible. So you don't have that much burden of recompilation even all the package is raw source code

 

I'm very excited about this and can't wait to hear more.

I also want to reiterate what has been said before. This thread is the best example among all the Unity features for good and transparent communication on such ongoing developments. Very much appreciated!