Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

4.5 - Serialization Depth

Discussion in 'Editor & General Support' started by LightStriker, May 27, 2014.

  1. LightStriker

    LightStriker

    Joined:
    Aug 3, 2013
    Posts:
    2,717
    UPDATE

    This error-as-warning have been added to the deserialization process of Unity. In some case - like mine - it can throw hundred or even thousand of them when you press play or you rebuild your code.

    When this error is thrown, it does not corrupt your data and does not affect your deployed game. In some case, it can hang Unity for minutes while it process some data. However, if too many are encountered, Unity can crash by out-of-memory.

    The serialization between 4.3 and 4.5 did not change. The only changes are support for struct and this new error. While Unity added that error as a way to highlight issue in your serialized code, it also highlighted an error in their code and documentation.

    Fact #1; Unity stops serializing object after 7 levels of depth. Beyond that, it assumes it's an error - a reference dependency loop. Before 4.5, Unity simply didn't tell you anything and silently erased your data, now it pops an error.

    Fact #2: Private or protected field are not serialized unless you manually flag them with the SerializeField attribute.

    What 4.5 highlighted is that private and protected field, while not saved on disk, are still processed by the serialization pipeline. So while you think your public field does not offer any chances of dependency loops, your private/protected fields might, and the Editor doesn't like that one bit.

    FIX

    Obviously, the best fix would be for Unity to perform serialization as they advertised and ignore private/protected fields. However, for now, the workaround found was to manually flag your non-serialized field with the NonSerialized attribute.

    Code (csharp):
    1.  
    2. public class Node
    3. {
    4.     [NonSerialized]
    5.     private Node parent;
    6. }
    7.  
    For some unknown reason, explicitly flagging a field in this way prevent Unity from trying to access it in its serialization.
     
    Last edited: May 28, 2014
    coding_crow likes this.
  2. DFT-Games

    DFT-Games

    Joined:
    Jun 24, 2010
    Posts:
    454
    @Unity guys:

    I'm having tons of this:
    at 'GameDraw::part'. There may be an object composition cycle in one or more of your serialized classes.

    and this:
    Serialization depth limit exceeded at '::AudioItem'. There may be an object composition cycle in one or more of your serialized classes.

    No crashes (yet) but this is quite upsetting as there is no explanation about the error and what can cause it. Upgrade Guide and Known Issues are not saying anything about hundred of errors... Are we sure that this is a step forward? :confused::confused::confused:
     
  3. LightStriker

    LightStriker

    Joined:
    Aug 3, 2013
    Posts:
    2,717
    Found out I also have this issue on my spline class!

    Code (csharp):
    1.  
    2. public class Path : MonoBehaviour
    3. {
    4.     public List<PathNode> nodes;
    5. }
    6.  
    7. public class PathNode
    8. {
    9.     public PathHandle bezierHandleA;
    10.     public PathHandle bezierHandleB;
    11. }
    12.  
    13. public class PathHandle { }
    14.  
    Just this depth appear to be enough to trigger the error.
     
    Last edited: May 27, 2014
  4. Burglecut_0001

    Burglecut_0001

    Joined:
    Nov 26, 2012
    Posts:
    8
    Just to chime in some more.. I just upgraded to 4.5, and now when I press play, I'm getting about 120 errors:

    Serialization depth limit exceeded at '::Item'. There may be an object composition cycle in one or more of your serialized classes.

    Maybe this message is innocuous; at least I don't see any effect on the application functionality at first glance. But I think I'll downgrade for now to be sure.
     
  5. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Report bugs please guys.
     
  6. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,649
    IIRC: The actual behavior here hasn't changed; what's new is the warning.

    i.e. it was always the case in the past that beyond a certain depth the serializer would just stop storing stuff (I think it was like 8 levels or something). So you could define a deep tree of things and Unity would just start silently failing to save your data.
     
  7. StarManta

    StarManta

    Joined:
    Oct 23, 2006
    Posts:
    8,773
    First of all, wow, that's a very arbitrary time and a terrible instance of when to fail silently.

    Second: it's certainly not 8 levels deep. It's 2 or 3. I get this warning on a class that goes MonoBehaviour -> DataClass -> ClassThatGivesWarnings.
     
  8. LightStriker

    LightStriker

    Joined:
    Aug 3, 2013
    Posts:
    2,717
    The error pops up at level 3 (?) which is rather low. I have submitted the issue... Will post the bug number when I get it.

    I haven't lost any data to the error, however I do get crash where I used to have the issue #593979.
    The issue #593979 have been closed on the bug database, but the issue (very very long time of wait when pressing play) is still there and now crash a lot more. Anybody know how I can re-open a closed bug? #593979 is far from being fixed.

    I hope deeply that Unity will have a proper object-oriented serialization in 5.0 and none of that nested serialization context.

    [EDIT] Bug number for this error poping up all the time; #610122
     
    Last edited: May 27, 2014
  9. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,649
    It does sound like the warning is being thrown at a shallower level than I'd expected it, for sure. That part sounds like a bug.
     
  10. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    I'm just guessing based on the context of the error but I think it is asking if you essentially have a property that acts as a factory method and it stops so as to avoid a stack overflow. For example, let's say you have this class:

    Code (csharp):
    1.  
    2. public class Foo
    3. {
    4.    
    5.     public Foo Normalized { get { return NormalizeThis(); } }
    6.  
    7.  
    8.      private Foo NormalizeThis()
    9.      {
    10.  
    11.  
    12.      }
    13.  
    14. }
    15.  
    16.  
    The class above when serialized would have it's "Normalized" property serialized, which in turn returns another Foo object that has it's own Normalized property and so on... so it's a never ending path. I'm guessing that's why it means by composition cycle.
     
  11. LightStriker

    LightStriker

    Joined:
    Aug 3, 2013
    Posts:
    2,717
    Dustin, you know Unity does not serialize or care about properties, right?

    I can understand the purpose of the warning/error.

    Assume;

    Code (csharp):
    1.  
    2. [Serializable]
    3. public class Parent
    4. {
    5.     public Child child;
    6. }
    7.  
    8. [Serializable]
    9. public class Child
    10. {
    11.     public Parent parent;
    12. }
    13.  
    The above would create a recursive serialization in which we would get infinite children and parents. Unity does not consider class deriving from System.Object as "object" or "reference", but as data container that are serialized by the container that derive from UnityEngine.Object.

    Most serialization have way to avoid this issue, by serializing objects only once and giving them an ID. Every reference to that object are replaced by the ID. Sadly, Unity is unable to do that.

    However, I can assure you, I have no case of recursive serialization in my code. When I need an upward reference, I propagate it downward on OnEnable. So far, I managed to have no horizontal reference.
     
    Last edited: May 27, 2014
  12. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,649
    In which case you'd best report a bug with the code it's choking on. They'll either fix it or point out the cycle that you missed :)
     
  13. LightStriker

    LightStriker

    Joined:
    Aug 3, 2013
    Posts:
    2,717
    #610122
    The code is fine. I even check the serialized file. The deserialized data is also fine. Unity is claiming nonsense for anything beyond 3 level of object depth. It's not breaking anything, just very annoying to have 7000+ error popup when you start your game.

    #593979
    Again... How do I reopen a closed issue? This one was not fixed, and 4.5 just make it crash even more. It was closely related to object nesting, as complex structure in an EditorWindow makes Unity hang for minutes while handling serialization!
     
    Last edited: May 27, 2014
  14. uniphonic

    uniphonic

    Joined:
    Jun 24, 2012
    Posts:
    130
    I'm getting the same error after updating to Unity 4.5

    :(

    -Jacob
     
  15. echologin

    echologin

    Joined:
    Apr 11, 2010
    Posts:
    1,078
    IM getting the same problem at 3 levels deep with 4.5 but the data all seems intact and app runs
     
  16. djweinbaum

    djweinbaum

    Joined:
    Nov 3, 2013
    Posts:
    533
    I'm getting a bunch of these too.
     
  17. Grespon

    Grespon

    Joined:
    Apr 13, 2012
    Posts:
    388
    Same here...
    Can't work ! :(
     
  18. sonicviz

    sonicviz

    Joined:
    May 19, 2009
    Posts:
    1,051

    Me 2...or more like me 120
     
  19. Grespon

    Grespon

    Joined:
    Apr 13, 2012
    Posts:
    388
    Well,
    I made a test here.. I created a brand new project and imported GameDraw. That was enough to get these errors.
     
  20. sonicviz

    sonicviz

    Joined:
    May 19, 2009
    Posts:
    1,051
    I know testing is a pitfa, but are you seriously telling me they fixed 450 bugs and didn't pick this one up?
     
  21. Grespon

    Grespon

    Joined:
    Apr 13, 2012
    Posts:
    388
    Yeah,
    It's happening with Ultimate FPS too. It's probably happening with a lot of assets out there..
     
  22. sonicviz

    sonicviz

    Joined:
    May 19, 2009
    Posts:
    1,051
    Mines not crashing with it, but I'm unsure of the ramifications of it.

    Anyone?
     
  23. Dosetsu

    Dosetsu

    Joined:
    Dec 22, 2011
    Posts:
    39
    I'm getting this error as well, related to Clockstone Audio Toolkit.

    Edit Fixed in latest update, thanks!
     
    Last edited: Jun 1, 2014
  24. djweinbaum

    djweinbaum

    Joined:
    Nov 3, 2013
    Posts:
    533
    Yeah I get it for AudioToolkit and UFPS
     
  25. Acegikmo

    Acegikmo

    Joined:
    Jun 23, 2011
    Posts:
    1,294
    I'm getting this in Shader Forge as well
     
  26. Lucas-Meijer

    Lucas-Meijer

    Unity Technologies

    Joined:
    Nov 26, 2012
    Posts:
    175
    Hi everyone,

    Let me try to better explain what is going on here than the warning message does.

    In contrast to what most users expect, Unity's serializer (that is used for all our c++ classes, and as well for your c# objects), does not support several things. amongst those are "null", polymorphism. Also, Unity actually serializes classes using value semantics. This means that if you have serializable class like this:

    Code (csharp):
    1.  
    2. [Serializable]
    3. class MyCustomClass
    4. {
    5.    MyCustomClass friend;
    6. }
    7.  
    Unity will always generate a 7 level deep object graph out of that, regardless of wether that field was set to null or not when you serialized it. Our serialization system is used as a basis for many other systems inside unity, amonst other our native garbage collector, prefab system and backwards compatible loading. What we found when we were improving overall Unity performance is that many projects have these classes that they serialize that have a field of their own type, or indirectly cause a loop, which in contrast to what people expect, actually has a detrimental effect on performance.

    I have looked quite extensively at how achievable it would be to support polymorphism and null, and the preliminary conclusion on that is that while not impossible, will be a incredibly invasive rewrite of the serialization and prefab system. The premise of "we need to know ahead of time what the datalayout is of the objects we serialize" is an assumption that is deeply rooted in the serialization system. While I would still at some point love for these limitations to be removed, we felt that it would be a very bad idea to not let people know that they have accidentally stepped off an enormous performance cliff. what the message is basically telling you is "your projects could be load much much faster if you were to get rid of the nested type loop".

    some examples of code that will trigger this message:

    Code (csharp):
    1.  
    2.  
    3. [Serializable]
    4. public class MyTree
    5. {
    6.     public List<MyTree> children;
    7. }
    8.  
    9. or
    10.  
    11. [Serializable]
    12. public class A
    13. {
    14.     public B b;
    15. }
    16.  
    17. [Serializable]
    18. public class B
    19. {
    20.    public A a;
    21. }
    22.  
    Bye, Lucas
     
    marsonmao likes this.
  27. Tak

    Tak

    Joined:
    Mar 8, 2010
    Posts:
    1,001
    This message usually means that you have a cycle in your serializable objects. Previously, Unity has silently broken these cycles after a certain depth (currently 8), but if you have a lot of them, it can lead to poor performance, increased memory usage, apparent hangs, etc.

    In 4.5, we still break the cycles, but we also emit this warning, to let you know when your scripts and scripts from Asset Store packages are triggering these issues.
     
  28. Kaldorei

    Kaldorei

    Joined:
    Aug 12, 2010
    Posts:
    112
    The warning cause massive freezes in our project by spamming the console (more than 90k warning at each compilation and play) changing the way that we manage datas will be like starting again our project since it's the foundation of it (nodal system) we don't serialize datas into MonoBehaviour we use the binaryserializer so the warning is even invalid. Because of that we just can't upgrade to 4.5 even if we need occlusion culling fixes, may you consider adding a custom attribute to prevent serialization depth warning to be triggered on editor ? (The project just work perfectly fine when built the problem is only on editor) thanks.
     
    Last edited: May 28, 2014
  29. WJ

    WJ

    Joined:
    Oct 25, 2012
    Posts:
    97
    This is just bad, really.

    Take my case for example, I have a custom serializer (thanks to the fact that we can not CLONE a scriptable object with a hierarchy) where I serialize the scriptable object myself and use that info to create an instance of a nested scriptable object hierarchy, now keep in mind the following:

    1: I use id's for identical objects, all objects are stored in a single list at the root level with a reference ID.
    2: All serialized fields point to these reference id's and only contain the field name, reference id and thats all!

    example from my serialized data entity

    Code (csharp):
    1.  
    2.  
    3.     [Serializable]
    4.     public class SerializedObjectData
    5.     {
    6.         public string Type;
    7.  
    8.         public string Id;
    9.  
    10.         public List<SerializedField> Fields;
    11.  
    12.         public List<SerializedObjectData> Objects;
    13.  
    14.  
    This screen shot shows how far my nesting goes, it never ever even if I expand every single node go deeper than this.

    $Screen Shot 2014-05-28 at 11.32.16.png

    The screen shot below shows references working, look for reference ID 4, also shows the max complexity of my serializer along with it's max depth and the fact that I have 0 circular references they are all unique id's and never the same object serialized twice, ever. If you are wondering the list drop downs are just id's to other reference obects or in the case of simple types are just the value..

    $Screen Shot 2014-05-28 at 11.34.58.png

    The serializer contains one root SerializedObjectData and it has its fields pointing to to Objects using reference ID's and SerializedObjectData that are in the Objects field have their own SerializedField entries but all pointing to the list of reference objects in the Objects field which is only available at the root node!

    Basically you are assuming that everyone who has a list that points to the same class type the list is stored in is some how in the wrong.

    I have no depth issues, I have no duplicate objects and I have nothing that references itself, nothing but a totally unique list of objects stored only at the root level and field entries that use an int to link to said objects. And when I serialize this to XML it's plain as day that my Objects depth is a measly 1 and then you just have the fields from the root object and the fields from the child objects which are 2 to 3 deep but all from the serialized objects that are 1 level deep so the system avoids any deep nesting so it doesnt have to do any complex look up's during serialization, all is accessible through a simple dictionary map by their id's

    But I get a crap ton of errors when I launch. My game even though I HAVE NOT LOADED THE OBJECTS YET! I'm talking I simply launch a splash screen with an image and a simple script on it, I have yet to even access these scriptable objects and I get bombarded with errors.

    It's a bit late in our project to upgrade with these errors as refactoring the serializer to use different classes for each depth is out of the question, not to mention that our engine relies on our custom serializer because your's just doesn't work for complex games at all! It's so broken and scriptable objects are pointless beyond simple games, we simply use them to store the structure and serialize that structure into our own format that solves all the issues that your system just doesn't support. Everything from circular references to game object caching without serializing the game objects (indexed caching), nested scriptable object cloning for unique hierarchical cloning etc.

    We might never be able to upgrade at this rate as this would require a time investment into our engine which we cant spare for the foreseeable future at this point. It's a pretty complex system that we invested 2 years of dev time into and grew it along side our projects.
     
    Last edited: May 28, 2014
  30. Lucas-Meijer

    Lucas-Meijer

    Unity Technologies

    Joined:
    Nov 26, 2012
    Posts:
    175
    Hi WJ,

    The intent of the warning is for exactly this scenario. where you know your datastructure and know you have no object loops, but where we know that Unity serializes that in a way you are most likely not to expect. When you get this message, it means that you have in fact fallen off a performance cliff. The message doesn't try to say that your code is aweful :), it tries to warn people that they have fallen of performance cliffs when they didn't expect.

    You can obviously say "but there should not be a performance cliff here!" and have a reasonable point. But at least there is a performance cliff here today, and with 4.5 decided we should at the very least let you know about it.

    How to fix it?

    make sure Unity no longer serializes the field that causes the loop. in your case, one option is to add a [NonSerializable] attribute to this field: " public List<SerializedObjectData> Objects;"

    if your other serializes happens to also use that attribute, you can make the field private with a public getter.
     
  31. WJ

    WJ

    Joined:
    Oct 25, 2012
    Posts:
    97

    So are you saying that if I changed public List<SerializedObjectData> Objects; to be public List<SerializedObjectDataReference> Objects; the problem would go away? It would be pretty dirty on my part as it would be a copy/paste of the SerializedObjectData class lol.

    SerializedObjectData
    - Objects
    -- SerializedObjectDataReference
    --- Fields
    - Fields

    This really makes no sense as none of the Entries in my list reference each other and none reference the root object either except by it's ID, I think the issue here is Unity really needs to fix it's serialization and bring it up to par instead of errors that force such a big change on us, I mean circular references are a common thing, having a class that stores a list of the same type through implementation or concrete types is also a common thing.

    I think I will be forced to go going back and storing my data as XML which has a performance hit, I serialized it to a field because it was more performant at the expense of the size of my scriptable object however it was worth it for mobile as instantiating the hierarchy was much faster. I'll have to cache the deserialized info somewhere in memory now and re-use it to instantiate new clones to overcome the performance hit from doing it for each character.

    I have attached an xml version of what our serialized hierarchy actually looks like in whole.

    http://pastebin.com/4xigiDma

    o = Object
    r = Reference ID
    f = Field
    i = id

    I have included all fields for this example, we dont serialize most of stuff like position/open trees in the editor etc.

    As you can see its very simple and should not be causing issues.
     
    Last edited: May 28, 2014
  32. Lucas-Meijer

    Lucas-Meijer

    Unity Technologies

    Joined:
    Nov 26, 2012
    Posts:
    175
    You could do that, but you could get much better performance than you are having today if you were to use unity's serializer, and not use "class loops". looking at your xml file, you already have your data in a format where you store instanced using a reference id. if you make c# classes that excatly mirror what you have in the xml there, you will not have a "class loop", not get this new warning, and performance would be a lot better.
     
  33. LightStriker

    LightStriker

    Joined:
    Aug 3, 2013
    Posts:
    2,717
    I've checked, and unless you started serializing private field without the [SerializableField] attribute, there is no cycle in my code.

    I just noted something in all your post... You talk about "knowing ahead of time", and just remember how you have issue with having field to null. Does that mean that private field, even if they are not serializable, Unity will try to create an instance on it, which could lead to a loop?

    Do I understand than THIS would be a problem too;
    Code (csharp):
    1.  
    2. public class Node
    3. {
    4.     [NonSerializable]
    5.     private Node child;
    6. }
    7.  
    Since it's not serializable, shouldn't it be put to null by default and not create an instance of that class? If this is the issue here, that would be a very easy fix and a behaviour people would expect.

    I really hope you would consider rewriting this for Unity 5 into a full object-oriented serialization. You already do it for reference between UnityEngine.Object by replacing their reference with an ID. You would just need to do the same for objects in that serialization scope.
     
    Last edited: May 28, 2014
  34. Grespon

    Grespon

    Joined:
    Apr 13, 2012
    Posts:
    388
    But the problem is that it's not just a warning, it's an error and the project will not run.. Should we contact all the Assets developer to fix their packages to fit Unity 4.5 ?
     
  35. LightStriker

    LightStriker

    Joined:
    Aug 3, 2013
    Posts:
    2,717
    This specific error should not prevent the project from running. If your project doesn't run, you have other issues.
     
  36. Tak

    Tak

    Joined:
    Mar 8, 2010
    Posts:
    1,001
    Private fields are serialized in some circumstances in the editor.

    No, this is not a problem. (Provided that you use NonSerialized instead of NonSerializable ;-))
     
  37. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    I am aware, it was just an example made to be easy. Not sure why you're picking at semantics but it appears that my assumption was a good portion of the issue. You don't even need parent/child, you could just as easily do it with:

    Code (csharp):
    1.  
    2. [Serializable]
    3. public class Parent
    4. {
    5.     public Parent otherParent;
    6. }
    7.  
    And even if null weren't an issue, if you were assigning otherParent in the custructor it would create one.
     
  38. LightStriker

    LightStriker

    Joined:
    Aug 3, 2013
    Posts:
    2,717
    It is...

    I have a prefab that the serialized data look like this;

    Code (csharp):
    1.  
    2. MonoBehaviour:
    3.   m_ObjectHideFlags: 1
    4.   m_PrefabParentObject: {fileID: 0}
    5.   m_PrefabInternal: {fileID: 100100000}
    6.   m_GameObject: {fileID: 100000}
    7.   m_Enabled: 1
    8.   m_EditorHideFlags: 0
    9.   m_Script: {fileID: 11500000, guid: 9c413ebb772197e4cabeec623ce18802, type: 3}
    10.   m_Name:
    11.   m_EditorClassIdentifier:
    12.   nodes:
    13.   - path: {fileID: 0}
    14.  
    Where the code look like this;

    Code (csharp):
    1.  
    2. public class Path : MonoBehaviour
    3. {
    4.     public List<Node> nodes;
    5.  
    6.     [Serializable]
    7.     public class Node
    8.     {
    9.         [SerializeField]
    10.         private Path path;
    11.  
    12.         public Handle handleA;
    13.         public Handle handleB;
    14.     }
    15.  
    16.     [Serializable]
    17.     public class Handle
    18.     {
    19.         private Node node;
    20.     }
    21. }
    22.  
    You can see from the serialized text that all is fine! Yet... Unity throws the errors about serialization depth. You can use this exact code, create a node in the list in the Inspector, place your GameObject in a prefab and trigger a script reload; BAM! Error. 48 of them in this case.

    Yet, one would assume that "private Node node" is not serialized, and seeing from the serialized data, it is not. However, Unity still doesn't like it and throws the error... Now, the funny part.

    If I do this;

    Code (csharp):
    1.  
    2.     [Serializable]
    3.     public class Handle
    4.     {
    5.         [NonSerialized]
    6.         private Node node;  
    7.     }
    8.  
    The error disappear! Wait... Shouldn't private field not serialized by default? How is explicitly flagging the field as [NonSerialized] supposed to change anything? And in both case, the serialized data is the same!
     
  39. WJ

    WJ

    Joined:
    Oct 25, 2012
    Posts:
    97
    Well I got rid of the error and with 3K data entries the profiler time for my old system that threw the error was 0.02 ms and with the fix (2 hours wasted) I don't get the silly errors anymore but my profiler time is still 0.02 ms so performance wise it made 0 difference to the speed of my serializer.

    Either way I'm just happy I was able to be rid of it so quickly lol.

    fyi: I was measuring from start to finish so reading in all the entries and creating a new clone of the hierarchical scriptable object tree.

    Not sure what difference it made to the scriptable object itself though don't really notice anything different in my start up.
     
    Last edited: May 28, 2014
  40. LightStriker

    LightStriker

    Joined:
    Aug 3, 2013
    Posts:
    2,717
    In our case, it's invisible on the profiler. We had up to 100 sec of hang time - not showing on the profiler - when the designer pressed play in the editor. For some reason, Unity allocated over a Gb of Ram and started doing... "something". Once in game, no impact of any performance. Even deployed on iOS, we wouldn't see any difference. However, having to wait up to 2 mins everytime you press play? That was killing our production. Our data was loaded in an EditorWindow made to edit that specific data.

    With no EditorWindow;
    Code (csharp):
    1.  
    2. Mono: successfully reloaded assembly
    3. - Completed reload, in  0.914 seconds
    4. System memory in use before: 48.2 MB.
    5. Unloading 149 Unused Serialized files (Serialized files now loaded: 0 / Dirty serialized files: 0)
    6. System memory in use after: 34.8 MB.
    7.  
    8. Unloading 200 unused Assets to reduce memory usage. Loaded Objects now: 2195.
    9. Total: 15.206539 ms (FindLiveObjects: 0.143984 ms CreateObjectMapping: 0.028978 ms MarkObjects: 2.562143 ms  DeleteObjects: 1.711516 ms)
    10.  
    Completed reload under 1 sec.

    When the data structure is loaded in the EditorWindow;
    Code (csharp):
    1.  
    2. Mono: successfully reloaded assembly
    3. - Completed reload, in 77.812 seconds
    4. System memory in use before: 48.3 MB.
    5. Unloading 150 Unused Serialized files (Serialized files now loaded: 0 / Dirty serialized files: 0)
    6. System memory in use after: 34.9 MB.
    7.  
    8. Unloading 200 unused Assets to reduce memory usage. Loaded Objects now: 2214.
    9. Total: 1564.175171 ms (FindLiveObjects: 0.121949 ms CreateObjectMapping: 0.027468 ms MarkObjects: 1551.331177 ms  DeleteObjects: 1.980167 ms)
    10.  
    Just adding [NonSerialized] on 3 private fields fixed the reload time issue. Frankly, I think there's a problem in Unity's editor serialization.
     
  41. GregMeach

    GregMeach

    Joined:
    Dec 5, 2012
    Posts:
    249
    Looks like the same applies to:
    Code (csharp):
    1. protected
    fields. However I don't know if they were also thought to be excluded from serialization.

    Regardless; on the asset that was giving me 12 of those errors after adding:
    Code (csharp):
    1. [System.NonSerialized]
    in front of them I see zero errors in the console....

    Now to find my missing behavior...
     
  42. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,649
    They are? What circumstances?
     
  43. LightStriker

    LightStriker

    Joined:
    Aug 3, 2013
    Posts:
    2,717
    Probably when flagged with [SerializeField]... and in the Editor in the case we found out here. Serialized, but not saved on disk. Weird stuff.
     
  44. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    Here's what I see: Path --> List<Node> --> Path --> List<Node>

    Because your Path class has a List<Node> field and each Node in that list has a Path field and each of those Path fields have List<Node> and so on. Even if they are null, they are likely what's causing your depth warnings Lightstriker.
     
  45. LightStriker

    LightStriker

    Joined:
    Aug 3, 2013
    Posts:
    2,717
    Sorry, but "Path" is a MonoBehaviour, and is treated as reference, not a structure of data.

    You can easily test that, make two MonoBehaviour that target each other. No loop.

    The problem is not on Path or Node, but in Handle. Flagging [NonSerialized] on "private Node node;" in the Handle fixes the issue.

    To make a comparison... When you serialize a hierarchy interconnected of classes in .NET XML/JSon, you usually ends up with a mess as each reference is viewed as a separated, unique container; http://stackoverflow.com/questions/...tion-storing-reference-instead-of-object-copy

    In .NET binary serialization, each object is serialized separately, and each reference targets an ID to retrieve that object instance in deserialization.

    Unity does half the job. Every object deriving from UnityEngine.Object are handled as reference. Every object deriving from System.Object are handled as data container.
     
    Last edited: May 28, 2014
  46. Grespon

    Grespon

    Joined:
    Apr 13, 2012
    Posts:
    388
    Well, my project was running fine before the update to 4.5. Both on windows and mac. Is it crashing only for me? Anyone?
     
  47. HP

    HP

    Joined:
    Nov 20, 2012
    Posts:
    80
    My prject have the same issues and also crashes on pressing run. But after looking into unity log files (at C:\Users\...\AppData\Local\Unity\Editor\Editor.log) I found out it was substance (procedural materials). After removing the materials and remove references on all GameObjects the project is running again.
    I hope this helps someone with the same problem.

    But the error messages with serialization limits are still there:

    "Serialization depth limit exceeded at '::animation_curve_class'. There may be an object composition cycle in one or more of your serialized classes.

    (Filename: c:\buildagent\work\aeedb04a1292f85a\runtime\mono\serializationbackend_directmemoryaccess\ShouldTransferField.cpp Line: 96)

    Serialization depth limit exceeded at '::color_range_class'. There may be an object composition cycle in one or more of your serialized classes.

    (Filename: c:\buildagent\work\aeedb04a1292f85a\runtime\mono\serializationbackend_directmemoryaccess\ShouldTransferField.cpp Line: 96)

    Serialization depth limit exceeded at '::value_class'. There may be an object composition cycle in one or more of your serialized classes.

    (Filename: c:\buildagent\work\aeedb04a1292f85a\runtime\mono\serializationbackend_directmemoryaccess\ShouldTransferField.cpp Line: 96)

    Serialization depth limit exceeded at '::precolor_range_class'. There may be an object composition cycle in one or more of your serialized classes.
    ..."
     
  48. tswalk

    tswalk

    Joined:
    Jul 27, 2013
    Posts:
    1,109
    seeing as how I'm right now working on developing some managers to use Serializable and serialized fields... this makes me a bit concerned to upgrade yet.

    is this definitely a confirmed bug, or just implementation issues and/or workaround gone stray that are now apparent due to 4.5?
     
  49. LightStriker

    LightStriker

    Joined:
    Aug 3, 2013
    Posts:
    2,717
    It does not corrupt data, crash, or affect your deployed game.

    Right now, it's an error-as-warning that have been added when the serialization goes beyond a specific depth.

    However, it also highlighted an issue in the deserialization of Unity (Editor) were non-serializable private/protected field are still consumed by the serialization process, if they are not explicitly flagged with the NonSerialize attribute. If this private/protected field happened to create a dependency loop, Unity would throw the error multiple times - in my case, over 7000 per play.

    Just to be clear, the serialization itself didn't change since 4.3.4 (except for struct support).

    The fix is to find the private/protected entry point of a potential loop and manually flag it with the NonSerialize attribute.
     
  50. Grespon

    Grespon

    Joined:
    Apr 13, 2012
    Posts:
    388
    Yeah.. I realized I was wrong.. but its weird: it's not crashing, it's pausing !!