SerializeReference Attribute?

Any quick word on what the SerializeReference Attribute mentioned in the release notes is?

[Apologies in advance: no time at present to download and install the alpha and its documentation to check if it's already documented there...]

 

This is very cool!

 

Sweet, sweet heavens. @jasonm_unity3d that is huge. Is there going to be more information on this, perhaps posted in the blog? It seems to me that an update to the Serialization in Unity blog entry would be super handy. (This assumes the manual will get its own update, of course.)

 

It's... Beautiful

 

Can you quantify "performance hit" in some way?

We'll have to benchmark our own code, of course, in the long run. We already serialize references with Serialization Callback shenanigans. My fingers are crossed that the new built-in approach is at least as fast as our custom solution...

 

Will this serialize dictionaries, mainly because that's an old request and we can finally put it to bed if this solves it?

 

Sweet Lord, at last!
*runs in circles in tears of happiness*

 

Holy S***. Does that mean we'll be able to serialize interfaces? I'll finally be able to use interfaces without feeling like Unity is fighting me by not letting me reference them in the inspector.

 

Nice!
Does this means we will also get a way to get System.Object reference from SerializedProperty?
pretty please

 

Wow! I can't believe this isn't mentioned in https://forum.unity.com/threads/preview-of-2019-3-features.678820/

Serialisation support for references *and* polymorphic data? Are you kidding? It is always such a massive pain to write complex tools for unity because you need to restructure your data to work around Unity's serializer. This will make things so much easier.

 

After some messing about, it seems very flexible so long as you are exclusively using custom classes. Also, (kind of expected) the inspector gets really weird really quickly and is frequently causes crashes when editing values of data that has been tagged as SerialiseReference. (It really likes crashing the editor!) The data does serialize and deserialize correctly - it's just that the rendering is a little broken in the inspector.

If you need complex data structures like this that support reference serialization then you are probably putting together something relatively complex, so you will probably be manipulating this data with a custom editor of some sort...so its not such a big deal! In my test, I was able to 'poke' the data on my monobehaviour using 'ContextMenu' methods and verify that references are maintained as expected.

Overall, very very very cool! It is a shame that we still can't reference UnityEngine.Object's via their interfaces though..! But at this point I'll take what I can get...!

 

ouch. this is exactly what I wanted it to do (being able to code against interfaces and the implementation can be either a MonoBehaviour or a ScriptableObject...)

 

Hell is officially affected by climate change!

 

I have wondered for a while, whether there should be some way to apply an attribute to a collection, rather than the elements. Ever since the change was made to apply attributes to the elements of the collection, there has been no way to apply attributes to a collection itself, requiring custom inspectors to override collection drawing behaviour, which was annoying but not a showstopper.

Now that there's an attribute that fundamentally alters serialization to this extent, it sounds like this should be looked at.

Granted, if I must serialise a collection by internal reference I could wrap it in a class, but it would be great not to have to.

 

I'd find applying attributes to a collection rather than its elements useful too. Here is an actual case where I would use it.

 

I was expecting this...

 

Ditto. And wider use of reorderable lists. Currently the options are a custom inspector or jumping through hoops. For a previous project I had a custom root inspector to allow several custom attributes for UX purposes, allowing per-collection attributes, but that approach wouldn’t work with attributes that change serialisation behaviour.

Anyhow, this is off topic now, I’m just sad when the opportunity for a QoL improvement is missed. The feature implemented here removes the need for huge amounts of involved boilerplate on my end as it is.

 

That's a real bummer. Interfaces are an important part of c# since you can't use multiple inheritances with classes. If I want to implement a dependency injection solution then this limit makes it a lot less pleasant to assign implementations to interfaces.

 

Oh boy! As an Odin developer, this feature is super exciting to me, as supporting custom serialization, especially in the context of the new nested prefab system, has been getting very problematic, and we've been trying to pivot our focus onto evermore sophisticated editor and workflow features instead. As such, I have a question/request related to this new attribute.

It is becoming increasingly complicated for plugins like Odin Inspector to keep track of whether Unity is serializing something or not, as we need to create our own logic that, based on the Unity version in question,
tries to guess for any specific type or field, whether Unity is indeed serializing it. A dazzlingly nightmarish array of factors can make a difference, from the backing type of an enum to entirely unique behaviour for many types (UnityEngine.Vector3 is not marked [Serializable], but Unity breaks the rules and serializes it anyway; we just need to hardcode stuff like this).

With this new addition, this will only get more complicated and difficult to maintain, especially as I can imagine that a feature like this might see a lot of change, additions and adjustments as people begin to adopt it. Can we have a thread-safe API (or at least, an API that can also be invoked from Unity's loading threads during deserialization) that will let us pass in a given type and member to determine whether Unity is serializing it?

It could, for example, take the following shape:

Code (CSharp):

1. SerializationType unityWillSerializeType = UnitySerializationUtility.GetSerializationType(Type type);
2. SerializationType unityWillSerializeMember = UnitySerializationUtility.GetSerializationType(MemberInfo member);
3.  
4. public enum SerializationType
5. {
6.     NonSerialized,
7.     SerializedNoReference,
8.     SerializedReference // The new serialization mode triggered by this attribute
9. }
10.  

Having this would solve a *lot* of issues for us! A single method that "documents" Unity's serialization behaviour would be much better than trying to figure it out through trial and error and sifting through year's worth of patchnotes (which we've done so far).

 

Does this make it possible to serialise Vector3? Always found it weird that such a essential object that's used everywhere can't be serialised.

 

What gave you the idea that Vector3 wasn't serializable?

 

When using the System.Serialized attribute on a class with Vector3 Visual Studio warns about the variable not being serializable

 

Perhaps because the Vector3 struct isn't decorated with System.SerializableAttribute.

 

I always serialize Vector3 no problem:
public Vector3 test;

I've never noticed any issue with Vector3 and serialization.

 

All of those types built into Unity are serializable without being marked with the System.Serializable attribute.

 

This is very exciting. I'm still learning Unity and it's quirks in editor tools department. Had to bang my head quite a bit around the limitations of the built-in serializer. I wonder how exactly the polymorphic fields will be rendered in the default inspector. Will there be some kind of "Create/Destroy" button with ability to choose a sub-class from a drop-down list?

I was trying to implement this at some point with a custom property drawer, but ended up using plain old MonoBehaviors (creating a bunch of empty game objects - far from ideal) or ScriptableObjects (not convenient when I want this data to be specific to a scene, prefab or an object) instead via some base class.

Features I'm missing the most in the current serializer:

- Serialize auto-properties.
- Serialize generic types.
- Serialize dictionaries.
- Provide some attribute to attach MB's and SO's to an Interface type field if these objects implement that interface (I use a workaround solution for this, but it requires creating a wrapper class for each Interface I want to expose via inspector object field).

I wonder if there's any plans or considerations about the above features I listed.

 

you can put a

[field: SerializeField]

attribute on the property. the display name is ugly though

the other 3 I want them too

 

Yeah I know but it's not a solution. The underlying backing field is compiler-generated, it's not guaranteed to remain the same. And it's ugly, as you mentioned. I'd better write some boilerplate with a normal backing field.

 

Could you give a bit more information and / or examples about this:

- Referenced values cannot be shared between UnityEngine.Object instances. For example, two MonoBehaviours cannot share an object that is serialized by reference. Use ScriptableObjects instead to share data.

 

It means that you cannot have a linked list of things serialised in two MonoBehaviours and expect them to maintain being a single linked list on deserialisation. Each serialisation context would get its own copies of the objects.

 

Will dictionary serilization support ever be added? I feel like it's quite an important feature for a lot of people

 

To be honest, while it would be very nice to have, it is one of the easiest things to do using ISerializationCallbackReceiver, i.e. it is not and has not been a show stopper since that interface was added, which was a rather long time ago now.

Sure, it'd be very convenient but that's it.

 

Is there any way to insert data into a field with [SerializeReference] from a custom inspector?

 

What exactly are you stuck on? Just set the value on the field.

 

Does this help in any way with Unity supporting serialization of arrays containing different types of objects?

Like in my query here?
https://forum.unity.com/threads/cha...ype-within-the-inspector.700709/#post-4684499

 

Yes.

 

Just so I'm clear, would polymorphic serialization support the following situation?

Code (CSharp):

1. [Serializable]
2. public class Animal
3. {
4.     public string name;
5. }
6.  
7. [Serializable]
8. public class Dog : Animal
9. {
10.     public bool isTailWagging;
11. }
12.  
13. [Serializable]
14. public class Cat : Animal
15. {
16.     public bool isPurring;
17. }
18.  
19. // This will be the serialized class
20. [Serializable]
21. public class Farm
22. {
23.     // This will contain Animals of all types (Dogs, Cats, etc)
24.     public List<Animal> animals;
25.  
26.     public Farm()
27.     {
28.         animals = new List<Animals>();
29.         animals.Add(new Dog());
30.         animals.Add(new Cat());
31.     }
32. }

I know I've had problems with cases like this in the past with Unity's serialization, so it'd be a big relief to have this fixed!

 

Yes.

 

Awesome! Glad to hear it. Thanks for the clarification!

 

I'm not sure if this is the thing I've been waiting for for years now or I didn't get this straight

I tried to mess around with this thing in an empty project, the serialized field appears in the inspector as a name only, you can't fill the values of that object. so I'm not sure if this is a bug or I'm using it wrong ?

also, what I have been waiting for is something like this

Player Class has IMovement interface, and you can drop any component that implements IMovement in this field, but what I understood is that won't be possible since a component is already UnityEngine.Object

if that's the case, what is this really about? is this just for data classes ? if that's the case, my original question is still there, is it a bug that it's not appearing in the inspector?

 

In the latest alpha, I am seeing

every time I perform an action on a behaviour that has a list field with SerialiseReference attribute.