koobas.hobune.stream
How do serialized Texture2D fields store and manage Texture2D data pulled from a dll ?
I am asking this question to find out exactly how a serialized texture2D field store and manage data ? more so if the texture2D data that populates the texture2D field comes from a dll resource.
I ask this because my correctly serialized class and Texture field loses data after assembly reload except for entering and exit of play mode . This was not the case before I moved my textures to a dll.
In my dll I have a class which accesses the executing assembly, calls GetManifestResourceStream (path to texture image), passes it to a stream. converts that stream to a byte array . then passes the byte array into the LoadImage() method of a new Texture2D which when returned gives us out texture . See Code and detail here
In truth i'm not sure which from to focus on ,should I find out more about how texture data generated and pulled from a dll is handled by the Unity serialization system or should I just focus on my code because a bug may be there or something.
But anyway , the code gives me the texture image which I have used many times but for some reason any texture it passes to a Texture field will not persist through an assembly reload .
The data only seemed to persist because I pulled handled my code like this :
We mark up out class to serialize correctly [System.Serializable] public class SomeClass{.......
[SerializeField]
private Texture2D myTexture ;
void OnEnable() { myTexture = (function to get resource image from dll) this made me believe that myTexture was persistin through assembly reloads }
instead of
void OnEnable() { if(myTexture == null) myTexture = (function to get resource image from dll) this made me realise that myTexture was in fact not persisting through reloads }
Same problem with a list of texture2Ds
@Bunny83 you seem to have seen the code before here
I'm not sure what is going on . I thought that Once the data is passed into the serialized Texture2D field that unitys setialization system would hold on on the c++ side and pass it back the the appropriate field after an assembly reload but it kind of seems like the data doesn't even make it to the c++ side even though the field itself is serialized . If i were to use Resources.Load to assign a Txsture2D then i would have no problem so I know that the serialization system is doing its work in that regard.
I am in deep confusion .
Any help would be appreciated .
Also , is there a more efficient way to pull and pass image data from a dll to a Texture2D field now ? since this method is 5 years old.
Serialized assets can only reference other assets in your project. Since you don't store your Textures as assets they don't have a GUID as there is no instance until you create your Texture manually from your DLL ressource. So you can't somehow directly reference something that doesn't exist in the project until you actually load it from your DLL.
On assembly reload, playmode change and other "events" Unity will completely reload the scripting environment and recreate everything from serialized data. When you create a Texture2D dynamically at runtime or edittime it's lost after the reload since it's not stored in the project as asset that could be referenced.
Since Texture2D is derived from UnityEngine.Object, it's a class that need to be serialized on it's own as seperate asset in your project. Basically Unity can only "truly" serialize classes derived from UnityEngine.Object. Those are always serialized on their own. Prefabs can bundle "some" assets into one but mainly GameObjects and Components. Other classes like Materials, Meshes, Textures, AudioClips, ScriptableObjects... need to be stored seperately. Usually if you create such an instance manually without storing it as asset or Destroying it, when you save the scene you should get a debug log that informs you about a leaked object as nobody is referencing it anymore.
Custom classes marked with the Serializable attribute actually aren't serialized as "class". Only the actual fields of your class are stored as child properties of the referencing MonoBehaviour or ScriptableObject. Try using "force text serialization" and just look at a scene or prefab with a MonoBehaviour that has a serialized custom class field. In the Yaml you will see that the fields of your custom class are simply part of the MonoBehaviour object.
References to other "true" assets (things derived from UnityEngine.Object) will just have a "reference tag" with a fileID and in most cases a GUID which identifies the asset inside this project.
Why do you store the image data in a DLL in the first place? Is it just to have it shipped automatically with the code? Are they used for some editor GUI stuff? If so you might want to load the images once and then use the AssetDatabase to actually store your images as asset into the project and have your editor scripts load the images from the assets first, Only load the images from your DLL when the assets don't exist.
wow, absolutely awesome answer. you hid all the right points as usual.
"Is it just to have it shipped automatically with the code" yes :) "Are they used for some editor GUI stuff" yes :)
"When you create a Texture2D dynamically at runtime or edittime it's lost after the reload since it's not stored in the project as asset that could be referenced." I was co$$anonymous$$g to that same conclusion once I saw that I was losing the references to my see$$anonymous$$gly serialized Texture2D data , then I looked at Resources.Load and was wondering why Resources.Load works. I had no idea that having the texture resources sit or not sit in the project would make such a difference.
I have done quite a bit of work with AsetDatabase I think that it will work really well.
I have learnt some new stuff. thanks a lot !!
I found an easier way to convert the stream to a byte array. Generate my AssetDatabase, storing my textures but I just having a small problem now . I don't have a $$anonymous$$m or anything so i cant ask around. Because of the nature of the problem I would need to share entire blocks of my code that I am using in my API.
So i'm wondering if I could send you my codes and you could help me figure out what the problem is ?
Well, i can have a look, but i can't promise much depending on "how large" your problem is ^^. You can send me a P$$anonymous$$ in the forum. I usually check those only once every few days, but i can keep an eye open ^^. I'll send you a P$$anonymous$$.
