Read/Write enabled

Unity Engine
,
1 
        newTex2D.Apply(mipMap, lockReadWrite);
        byte[] bytes = newTex2D.EncodeToPNG();  
        File.WriteAllBytes(Application.dataPath + folderPath + newTexName + ".png", bytes);

everything works, except when lockReadWrite is set to true, it still shows as read write enabled in inspector, and I am still able to read write from it.

I am guessing perhaps it is because File.WriteAllBytes ignores the mipmap and readwrite settings as those are unity settings.

I tried

File.SetAttributes(Application.dataPath + folderPath + newTexName + ".png", FileAttributes.ReadOnly);

and it did indeed lock the file, but inspector still had readwrite enabled turned on. Turning it on/off in inspector did not change it, it was still locked.

  1. questions:
  1. How do I, with script, change the unity readwrite to readonly so it doesn’t take double memory and/or
  2. if I lock it via FileAttributes.Readonly, will Unity recognize that, and not use double memory? I consider this a hard lock, because the only way I found to unlock it was set FileAttributes to Normal, and I’d rather have Unity’s soft-lock, where it can be turned on and off in inspector.
2

Texture Read / Write means something completely different than Read / Write enabled on the filesystem.

They are completely unrelated.

3

I would prefer the texture read write, as opposed to the filesystem read write. But the texture read write does not seem to apply itself in unity when calling newTex2D.Apply(mipMap, lockReadWrite);

4

I don’t think you can even “lock” a texture the way you are contemplating.

It’s more to tell you that a texture was created as read/write-able, something that happens at import time.

I think all new()-ed up textures are R/W always, but I could be wrong on that.

5

Are we talking about runtime or editor? You can make it non-readable at runtime, but I don’t think that also changes the bool in the inspector since that is a texture importer editor thing.

Here is how you change the importer setting : Unity - Scripting API: TextureImporter.isReadable

FileAttributes is about the png you are writing out, which is a completely different thing than the Texture you have in memory.

6

It isn’t a huge deal, as this is just for a mini tool to add and mix color channels. But I am still wondering if I readwrite lock via file, but Unity still sees it as read/writable, if Unity will override the read/write lock in the graphics processor and still use double memory. My guess would be no, that a readwrite lock on the texture set from file will mean the graphics processor will not bother doubling memory for a write, and ignore unity saying it is red/writable, when it is not.

7

I still wonder if I pour hot water in my tea kettle if perhaps my car’s gas tank will fill up with gasoline.

But my tea kettle and my car are NOT RELATED IN ANY WAY so that doesn’t happen.

I don’t know how many more ways I can say that the read/write attributes of a file in a filesystem don’t mean anything whatsoever to do with the Unity texture read/write.

1 Like
8

So, to answer my question, are you telling me that, yes, if I write lock it via File, Unity will still use double texture memory, even though it can no longer write to it because it is File locked?

I have a feeling you actually don’t know.

To say they are not related in ANY way is not true, as in they are related at least in the fact they both achieve at least the same result that Unity can no longer write to the file. That is a relation. They both affect the car, where as a tea kettle would not affect the car.

Anyways, AcidArrow seems to have already answered my question, I have just not tested it yet, so I had not replied yet that that was the answer.

9

I did say the same thing though:

Attributes on the png file, have absolutely nothing to do with the imported texture in the library and whether or not that one will keep a second version of it in RAM so you can potentially make changes to it and re-upload it to GPU.