koobas.hobune.stream
Setting isReadable for a procedurally created texture asset
Hello all.
I'm having trouble discovering how to set the isReadable flag when creating a procedural asset.(mesh or texture)
In the following code, TextureImporter is null.
AssetDatabase.CreateAsset(nodeDb.Texture.GetTexture(), Config.TexturesDirectory + "/Texture" + nodeDb.NodeIndex + ".asset");
TextureImporter texImporter = AssetImporter.GetAtPath(Config.TexturesDirectory + "/Texture" + nodeDb.NodeIndex + ".asset") as TextureImporter;
If I can't get TextureImporter, how do I do this? An object is returned but is of (undocumented) type NativeFormatImporter which has an almost completely bare interface.
I built an application that extracts images from a database, compresses them(native to iOS) and saves them directly to the assets directory. When I load them onto the device it appears I'm using way(~2x) too much texture memory - like a copy in memory and for VRAM (yes I understand that VRAM is shared on iOS devices).
This is totally defeating my entire memory saving strategy and really quite bad for me. I just assumed I'd be able to retrieve a TextureImporter.
Perhaps something (hacky) could be done with NativeTexture pointers???
Can anyone please help? It appears a few have been frustrated when building procedural assets. Why not have the read/write flag in Texture? Please?
Any help much appreciated.
Scott
Just to put my issue into perspective, I am displaying geometry data containing roughly 1 million triangles and texture data of approx 16k x 16k (compressed PVRTC). Performance is not an issue but memory definitely is!
The target platform is an iPad 2. I really really can't afford 2 copies! :(
Scott
I am of course running in "Editor" mode. I'm using the editor as a build environment - extracting and converting meshes/textures from a database to native assets. So I;ve created the most optimal size and performance characteristics for the assets but they take double the memory they should. :( If there were only one copy, memory usage should vary between 50-200$$anonymous$$b just for the in-memory texture/mesh assets. Clearly doubling that is bordering on disastrous when working on the iPad 2.
The tool has been built and delivered to he client. I've only recently discovered these issues but wasn't concerned knowing about the isReadable setting for the TextureImporter. I hadn't considered not getting a TextureImporter interface to my native texture.
This is when I miss coding in C++.
Just for the record I have filed a bug report with Unity about this. Did I accidentally set a flag? (Only you see this)
I have a test scene with just textures (53$$anonymous$$b) and meshes(31$$anonymous$$b) - the usage numbers are from the iPad.
With nothing(no assets) loaded the baseline consumption for the app is ~30$$anonymous$$b.
I would expect total memory usage to be ~114$$anonymous$$b. The real total is 160$$anonymous$$b. A measly 46$$anonymous$$b overshoot.
The textures are compressed and they are native assets (because I created them procedurally). Being compressed means that I cannot read them(with ReadPixels) and also means there should NOT be a second copy in memory.
This is a big overspend for me as my project's raison detre was to reduce memory consumption.
Any help would be warmly received.
Scott
I know this is a very old topic, but I think I've discovered a solution.
I'm not sure when it was added, but in the current version of Unity (5.4), Texture2D.Apply now takes a second argument, "makeNoLongerReadable". With this set, the copy of the texture in system memory will be released.
Now, you can do this on procedural Texture2Ds, Texture3Ds, and Texture2DArrays.
myTexture.Apply(true,true); // will generate mip-maps and free copy
