Unity Future .NET Development Status

I suppose he meant, that native C# classes still count the UnityEngine.Object inherited classes as referenced (which stops the GC from collecting them), which makes 100% sense as they are managed by the C++ side anyways...

Why you would want this and not already expect this behavior is beyond me.
E.g. The reason why null-coalescing doesn't work is because UnityEngine.Object aren't actual C# objects...

 

Yes, thank you. The docs don't explain a lot about this. Here it just says:

There's also this thread with information about this. There's a bit of confusion in some parts of the thread, but I think it's an interesting read.

The main thing is that when Unity runs it's own native object GC (i.e. when calling UnloadUnusedAssets, or when loading a Scene non-additively), it still looks into WeakReferences to know if an Object is being used. C#'s GC does skip them, though. This can cause various errors in different circumstances. It seems like Unity can handle when the native part of an Object is removed while the C# part still exists, but there are multiple weird things that can happen when the C# part is removed and the native part still exists. I've never looked at Unity's C++ internals, so that last thing is mostly a guess.

Just to be clear, C#'s GC can still collect them. It just can cause some errors with UnloadUnusedAssets.

I do expect it. I expect it because it's in the docs. I think it'd be nice if they were supported. It can be very nice for some optimizations and patterns. They can be useful for caching the results of expensive queries, or registering observer Objects without causing an unnecessary memory load. A lot of other engines/frameworks where Objects can be destroyed have this functionality in one way or another because it's useful.

I'd never say it's a bug, and I can live with this limitation, and I still really like to use Unity; I'm just saying it'd be nice to have. The fact that the docs say the word "currently" when talking about this limitation, makes me think maybe some people at Unity think support for WeakReferences could be useful too.

Right, in a way, it feels like these problems are related. I think they have an opposite flow of information, though:

• When checking if a UnityEngine.Object is null from C#, C# must look into the native part. We have ways to do that by casting to a boolean or using the equality operator. These ways serve as workarounds for the lack of support for null-coalescing operators.
  
  
• When unloading unused objects, the native part must look into the C# part to know if the object is being used. There are limitations to this; I think they are, in order of importance to me: lack of WeakReference support, that it can be very slow and freeze the game for a bit, and that it doesn't look into the Stack. I'm just wondering if the fact that the native part of Unity will now be more aware of C#'s GC features could remove some of these limitations, especially the WeakReference one.

EDIT
Hmm... Thinking about it, my guess that the reason it doesn't work is because UnloadUnusedAsset doesn't skip WeakReferences doesn't make complete sense in some ways. Please take that with many grains of salts. I'm pretty sure that it can cause errors and weird behaviors, though.

 

I dont want to specify an assembly for our main codebase, thus it defaults to Assembly-CSharp from Unity itself. You cannot refer to this from the test assembly definition sadly.

 

@TJHeuvel-net There were talks about testing

Assembly-CSharp

over in https://forum.unity.com/threads/unity-test-framework-2-0-ready-for-feedback.1230126/, I suggest continuing that topic there.

 

I made some tests. My previous theory in my previous post for why it doesn't work is wrong. Sorry for the late update, I should've tested this before to provide better information.

UnloadUnusedAssets does collect objects that are only referenced inside WeakReferences. Some of the errors seem to be caused by accessing objects that are being removed while UnloadUnusedAssets is running (as it is async). WeakReferences let you access Objects that are being removed, something that would be impossible otherwise. Comparing those Objects to null in these cases returns false, but using those Objects still causes errors. If comparing those Objects to null returned true, the errors could be avoided.

I think most of the rest of the information in that post is still valid.

 

Yeah, now that I think about it you're right... Though I do suppose their use-case would be quite limited (especially because they would probably only give a real performance benefit, if the number of objects is a lot...)

Anyhow, I would love if Unity would support such features, but I am afraid that such a thing might never be possible or even feasible right now, if UnityEngine.Object stays on the C++ side...

Actually a sad thing.

 

It's probably feasible in ECS land... if it isn't supported already, maybe bring it up in their forums while it's still young.

Thinking about it, if ECS will support nullable that would be amazing too. It shouldn't be too hard... most code works with structs anyway, so there's relatively less to support.

 

Anyway now that I'm all caught up again, what I actually wanted to post:

After almost a year-and-a-half, the mathematics package got a new update: we're in 1.3.1! It's got a few new methods, nothing too exciting, but it also has better documentation, and I have a question about the following page:
https://docs.unity3d.com/Packages/com.unity.mathematics@1.3/manual/compatibility.html

It provides details about porting over code to unity.mathematics and compatibility. I don't know if this is the right forum to ask, but is this a soft confirmation that Unity is going to drop official Vector3 and Mathf support, even if it's in the distant future?

Spoiler: Casey rants about math and it's like really petty

The question has been up in the air for a long time, especially with C# now providing their own Vector types and Mathf functions: which is best to use? Currently, you should definitely keep using Vector3 and Mathf, since Unity methods use it and conversions are just free performance-loss. However, when Unity enters .NET 7 land, there is finally an answer: the

INumber

interface.

It would be beyond amazing if one day Unity, in all its methods, started accepting the

INumber

interfaces, and whatever the

IVector

equivalent will be. Users could then freely choose what library they wanted to use, provided it implemented those interfaces. However, with the way unity.mathematics is aiming to be such an integral and versatile mathematics package, I would expect them to adopt these interfaces first chance they get.

What's frustrating is the confusion around this. Not to mention, the fact that generic math for Vectors doesn't even exist. Sorry, this post turned into kind of a rant, but I'm out here once again: should we port over to unity.mathematics? Can Unity just make a decision and port it into the main engine already?

 

Afaik, a lot of Vector3 math is (and probably will keep) running in unmanaged/c++ land, whereas unity.mathematics is pure C# (with extra burst friendliness). I might be too pessimistic but a full unification looks like something for 2030...

A side rant: funny how they chose the library "style" to make it look like shader code and how that makes it a real hassle to migrate from vector3 and mathf stuff.

 

That’s to be expected: for maximum performance float3s (for example) need to be as small as possible, so no extra methods or properties allowed. Something like lerp then needs overloads for everything from float to float4x4, which is a lot like *drumroll* shader code!!!

It makes sense to kill 2 birds with 1 stone and have the new library interop with shader code since they’ve done vectorization right for years. It also makes sense from a developers perspective to learn 1 math library to use for 2 different skills! But man I hope Unity realizes unity.mathematics full potential. Vector3’s… not the most optimized, but the most used. It’s frustrating.

 

What kind of size are you talking about here?

 

In memory byte representation

 

That just makes it sound like nonsense. Methods don’t add space to anything unless there’s dynamic dispatch involved, which can’t be the case for non-boxed structs, and properties for these mathematic primitives should always be computed properties, not taking up space either. Vector3 has the same size and memory layout as float3 for all architectures I’m aware of.

 

I will concede that I am out of my league here, but from what I understood it is important in ECS to keep data stupid simple, with no extra methods or properties so it could be properly optimized by burst ‘n stuff. But I don’t have proof, frankly all I understand about SIMD is that it makes your processor go vroom vroom

For vanilla Unity where everything is loaded-as-needed, unity.mathematics provides no intrinsic benefit though, I know that much. But some of its methods are more optimized or provide faster versions (if you know e.g. a vector is normalized AOT) and it has better architecture, so I’d still love to see it replace Vector3.

 

The rule should actually be simple: Unity.Mathematics wherever Burst is used, and Vector3/2 and Mathf in a pure Mono. And with Reinterpret you can also use both in the same array.

 

The struct size is the same. logic code resides in a separate piece of memory. And almost everything in the math library is inlined i(Burst or JIT for mono copies the content of the methods where they are called to reduce function calls).
The reason why the functions are no longer in the data structs is probably also to separate data and logic.
And to make it easy too, because you use the same function(overloads) for flaot2/3/4, and not 3 different ones.
(But what has always bothered me is the naming in math)

 

what's wrong with the naming?

 

The naming in Unity.Mathematics is based on shader function/type names, and not on the C# naming convention that Unity uses in the Unity.XXX namespace. However, there are also methods in it that adhere to it. Its a mess. As a hobbyist, and someone who rarely has anything to do with shader code, I often find it difficult.

 

Yeah, it not conforming to C# naming is not too great, but in this case understandable, i guess. I've not actually seen C# naming conforming methods in it tho...

 

Make sure when official removes asmref and asmdef, official should provide path to be able to do the same thing at coreclr land. My use case is using [assembly: InternalsVisibleTo("")].

 

using [InternalsVisibleTo()] is not dependent on asmdef

 

No. I mean asmref. I have special use case for that.

 

InternalsVisibleTo can be specified in csproj. It has been already discussed in this hread.

 

To put it to bed:
I have a concrete use case that uses asmrefs and conveniently wrote a blog post about it before it was ever a discussion here. You can see how I use them to provide users with safe access to internal unity code.
https://itch.io/blog/565936/safe-access-to-internal-unity-code

I've refrained from posting it since it borders on self-promotion, but in this case it may actually help to clarify the issue. The method in the blog could only be done with asmrefs, since it references an assembly that has internal access and then allows you to safely access internal code (which is still bad practice, only use if you know what you're doing).

I think people here are mostly concerned that the above will not be possible anymore, meaning it should be a good case study for this effort to bring .csproj to Unity. That said, I would still welcome the deletion of asmrefs if it meant better integration with visual studio builds, faster compilation, all that good stuff: the community will find a way to hack into anything anyway.

 

Great article!

To be honest, I hate the idea of the centralized handling of assemblies and references. There goes the modularity. Now if you install a folder with some code, it can act as a module and you don't need to tweak around anywhere else. As soon as we switch over to .csproj files, this will change. Now, obviously if nothing really changes, just use module.csproj instead of module.asmdef and module.asmref (and we can inject code from the client side with this), then I don't care. I don't like XML, but I can live with it, convoluted MS system, as usual. But I honestly doubt that it would be the case, if nothing really changes, there is no point to replace asmdefs with csprojs.

 

What are you talking about??

'convoluted ms systems' - ok, well i don't know what you classify under 'convoluted', but an I would not classify an almost always nearly empty file as convoluted. And in cases where there's actually more in it, i can classify it as 'powerful' since all the msbuild stuff you can do with csproj you cannot do with asmdefs at all.

'centralized handling of assemblies and references' - how? you would literally replace all the asmdef with csproj, reference them, and have just as much modularity as you do now with asmdef.

'if nothing really changes' et al - wtf. 'there's no point to replace asmdefs with csprojs' - there's every point and reason. it opens up the whole of msbuild and more to you, as well as project interop, which isn't really possible with asmdefs, and more.

 

I think he was just criticizing the XML usage in MS Build Products and I agree XML is really a waste of space, hard to write without an IDE (and honestly with one as well) and hard to read...

I wished everything would've been TOML

 

Oh, trust me, I'm glad I was wrong because if I wasn't, that would be terrible news for everyone.

 

I agree that XML isn't the most beautiful thing out there, but it has good points speaking for it too: it's easy to parse, it's similar to html, it supports custom properties, be it nested ones or not, is widely supported and used, and is easily human readable.

If we still had .net framework style csproj, i would agree that it's not nice to work with them, but with the new and simplified style, it's really easy to just read it like any basic html site.

 

That's not true at all, you have a misunderstanding. The null-coalescing operator works exactly as intended, it checks the actual reference for null. The reason why it quote "doesn't work", is because UnityEngine.Object overloads the == operator, and the engine hijacks the meaning of null so that if one of the operands is null it actually does an "is destroyed" check.

The point of the

is

operator,

?.

operator, and

??

operator, is to bypass custom == implementations and check the actual reference with null. i.e.

a is null

is equivalent to

ReferenceEquals(a, null)

, not

a == null

. This means these operators work as designed, they are intentionally designed to bypass any custom stuff, which is what Unity does.

 

Technically OP was wrong but I think we all got the idea.

Either way thanks for clarifying!

 

and we've had many a discussions about this before, here and otherwise, and last update on it is: Unity is looking into improving it.
I don't think we need to up this discussion again, at least not at this point.
All still valid points though.

 

Literally what I said...

 

Ok I will explain what I meant by that sentence...
They are not actual C# Objects, because the "real" objects, that are going to be handling collision, rendering, etc live on the C++ side which makes them not "real" C# objects...

I hope that is understandable....

 

which is actually wrong, since they are indeed real C# objects that wrap a c++ object.

 

Which is why I had the real in quotes, because technically speaking they **are** still C# objects...
Anyways this is suuuuuper off-topic and my bad way of describing things is something, that I *should* work on.

Important thing is, in the end we all know what we are talking about

 

Yes…









…Unreal, amiright?

 

I am actually crying right now. Unity released a 'C# style guide' and it's awful.

 

Is it this one? https://unity.com/how-to/naming-and-code-style-tips-c-scripting-unity

 

yeah i think so, although i also made an ebook and yt video about it....

 

What is it you don’t like about it?

Personally I wouldn’t call it a style guide, since they don’t specify what you should do but what you can do… other than that, I guess they’re helpful tips. But very elementary, more for beginners than professionals.

 

Ok… what the hell? Some unexpected news just dropped: Visual Studio for Mac is going to be retired.

https://devblogs.microsoft.com/visualstudio/visual-studio-for-mac-retirement-announcement/

@JoshPeterson does this pose problems for your team, or that compilation won’t be as fast on Mac since there’s no MSBuild support?

 

Where are you getting “no MSBuild support” from?

 

Following the links from the alternatives section in that article, it seems that Microsoft is boosting C# support in VS Code. They added their own extension to support Unity in the market place that works with the UPM package for Visual Studio. They also recommend a C# dev kit extension that has Build/Run support with the .Net Build command, which uses MSBuild. I feel like they aren't dropping support for MSBuild on Mac if VSCode is meant replace Visual Studio for Mac.

Personally, I look forward to being able to use VSCode with Unity projects again. It's such an agile and customizable editor. The reviews for the relevant extensions seem to suggest they need some time to mature, but there's still a year of support left for Visual Studio for Mac while that happens.

 

Well, thankfully MSBuild does not require an IDE. But that does suck for Mac devs. The only real alternative is Rider, which isn't free.

 

Btw Rider has started dropping free nightly builds!
Not the EAP builds, these are separate! These nightly builds are new "buggy" builds that appear to stay usable, until the next nightly build and honestly I'm using them and it's a blast!

 

I only took a quick look due to time constraints, but what do you think awful? From what I've seen it's very close to the official C# guidelines.

After trying Rider, I quickly switched. Maybe it's because I work with PHPStorm professionally, I get along much better with it than with VS. And I've never really gotten to like VS Code.

 

I see, great news then! I tried VSCode for Unity a couple of years ago, back then it was awful, but I didn’t realize they were building their own supported extensions now.

Back then, sometimes changes in Unity (e.g. create new assembly) wouldn’t trigger in VSCode and you had to close and open it again, manually. It was dumb.

 

No, it looks way more like the current Unity engine 'style' than the official guidelines. I think that says enough.

 

Example?
The biggest difference is properties from C# guidlines and UnityEngine.XX namespace, and there is no guideline for properties in Unity's guideline.
The Unity.XXX namespace uses naming closer to the official guideline.