[Design] Graph only as ScriptableObject

[Driiade]

For the instance, Graph are only scriptable object. Which I think is a weird design for CPU usage where you Instantiate / clone this class. For example Instantiating scriptable object create useless callback with Unity (OnAfterDeserialize for example). Maybe we can cut off the extra CPU usage by having same behaviour in a class which is not a scriptable ? The problem is that the runtime class is the same as the serialization and is not fully data oriented like you may expect for a scriptableObject.

Maybe we can improve this by having data separated from runtime ? and so Graph data in a scriptable, and antoher class which is the runtime instance ?

[Gavalakis]

Hello again,

Changing the whole framework to work outside of ScriptableObject will be a big endavour since the whole project is built on this all this years. I do understand that instantiating a scriptable object comes at a cost, but A) We instantiate unity objects all the time in a project. It is really not that costly and B) Instantiating any object (unity or not) comes at a close anyways 🙂
The OnAfterDeserialize callback is not useless at all, because it is utilized by the graph to deserialize itself. Whether or not that data were to be deserialized in the graph itself or in another object, such deserialization would still need o take place regardless of where that will take place.

Thus, the culprit here is the deserialization, rather than the fact that graph is a scriptable object. Deserialization is always costly, but I have really taken a great deal of effort to optimize and alter the the core framework code in use (FullSerializer) to be as fast as I can possible make it be. Furthermore, instantiation and deserialization cost of graphs can be further reduced by loading the graphs asynchronously (in a separate thread). This option for example can be enabled by setting the GraphOwner -> First Activation -> to “Async”. Just in case you didn’t know of this option 😉

Let me know what you think.
Thanks!

Join us on Discord: https://discord.gg/97q2Rjh

[Driiade]

Haha it s just that I pool my graph and used graph.Clone which lead to OnAfterDeserialization and deserializing all the json again. Now I fixed it by creating a new Graph and giving it the right parameter from the original graph…

 

Long story short, it s just that cloning a graph seems to lead to another deserialization from json which I think we can cut by copying the instance of the original graph. I don t want to cut scriptable object for graph, but copy of original graph doesn t really need to be scriptable object, it s what I’m saying.

 

And yes I know for async, I use it a alot for pooling AI during loading screen 🙂

[Author]

Posts