In our project we have a custom ScriptedImporter which reads .pyxel files and creates sprites. I’m not going to go into any details at this moment but eventually the code TextureGenerator.GenerateTexture(…) to create the actual sprites.
This has been working really well up until now. For some unknown reason all sprites in our project have been grayed out and are now largely transparent. Almost as if some internal texture format has changed. I’ve been fiddling around with this a few hours but can’t seem to make it work.
It seems like the importer is only considering the red channel in my input pixels. The more red there is the more white and opaque the pixel becomes. As if the color is:
(R,G,B, A) = (r_input, r_input, r_input, r_input) instead of (r_input, g_input, b_input, a_input).
The sprite is obv built from textures generated while importing the .pyxel file. I save those textures to disk for debug purposes and they look fine. It’s just the sprite that gets messed up.
Do note that the pixels from the color texture is actually copied to the sprite as it is generated. I have checked to make sure these pixels are correct and they are. There is something happening during the actual sprite construction that is really off.
Are there any known changes to this or anything else that can be related?
0a12 still works great. Deleting library and reimporting everything does not help.
Hello @johan_olofsson ,
Could you file a bug report for this issue? Then we can take a closer look to see what is failing.
Once you have, do post the case number, so we can follow up easily with you.
Thanks!
Hi @johan_olofsson
I believe there have been recent changes to TextureGenerationSettings that is a potential cause of the issue. Please try setting the following properties for textureGenerationSettings in the Importer script :
textureGenerationSettings.textureImporterSettings.swizzleR = TextureImporterSwizzle.R;
textureGenerationSettings.textureImporterSettings.swizzleG = TextureImporterSwizzle.G;
textureGenerationSettings.textureImporterSettings.swizzleB = TextureImporterSwizzle.B;
textureGenerationSettings.textureImporterSettings.swizzleA = TextureImporterSwizzle.A;
Please let us know if this helps.
2 Likes
Ah, yes that fixes the issue! Thank you very much!
I actually managed to mitigate the issue by calling SetPixels(theExpectedPixels); after generating the sprite but it felt like a hack. This is much better!
1 Like
Hmm, it seems a13 is full of surprises 
Apart from importing .pyxel files to create sprites we also import .pdd files for certain types of layers. A .pdd file is simply a .psd (Photoshop) file with a different extension. (afaik Unity does not support multiple importers for the same extension?) Anyway the way we built this importer was to create a new ScriptedImporter and inherit from the built in PSDImporter. We override OnImportAsset and perform the following:
- Manipulate some settings in the textureimporter settings etc using reflection.
- Call the base OnImportAsset()
- Access the created GameObject using GetObjects() and traverse its hierarchy to access the sprites created for each layer in the file.
- Create our own assets based on those by looking at the size/position of each sprite and accessing the data in the textures they reference.
Now as of a13 those sprites are broken. They exist with the correct name etc. However they are of size 0 and the texture seem have no data.
I’ve tried to remove all manipulation from step 1 above just to make sure nothing is broken by me but in step 3 the sprites are still invalid.
Any suggestions?
Perhaps you know this one as well @Venkify ?
Thx!
Hi @johan_olofsson
Would you able to send us a project before the update so that we can take a look?
Hi @Leo-Yaik , thx for your answer. Unfortunately I can not send you the entire project. I can however create and send a simplified importer which will demonstrate the issue or screen share to show you live?
Having a small repro case would be great as well that would allow us to easily reproduce the issue.
Yes, I’ll set that up. Should I upload it here or send it somewhere?
You can drop me a PM with a link to download if you are not comfortable sharing it in a public forum.
Ok, here is a zip with 2 projects. The one for a12 successfully manages to import the asdf.pdd by simply inheriting the PSDImporter. In a13 the results is messed up. The size issue might have been a mistake from my side. In the real example I previous worked on some layers were empty and prob got size=(0,0) due to that so ignore that for now.
This issue now is quite similar to the original issue in this thread which was solved by setting the swizzle. I do this in the a13 version, but it makes no difference.
I have removed all custom logic we normally use to simplify the examples as much as possible.
7642348–952315–PddImporterTests.zip (730 KB)
Hi @johan_olofsson
We have put out a new PSDImporter package (7.0.0-pre.3) that should resolve this issue.
And thanks to your sample project, we realized our fix wasn’t proper. We will be making another fix on this issue to allow user’s swizzle options to take effect.
Oh ok cool, glad I could help! 
When can I expect a working PSDImporter?
Btw, it’s quite annoying to have to hack things like this using reflection. I do the same with Light2D, URP Renderer and lots of other Unity classes where things I need to modify are not exposed. I realize unity don’t want to expose details that they might want to change over time since they then have to be backwards compatible. But a middle ground would be to let f.e. the PSDImporter implement an interface “IPSDImporterInternals” that exposes all of this and which is 100% explicitly implemented (i.e. not visible to either outside consumers nor inheritors).
As an inheritor who then would like to access the internals, I could simply cast ‘this’ to IPSDImporterInternals and gain access to all that I need without having to through reflection. And of course, it needs to be obvious that using “internals”-interfaces is risky due to them being potential subject for breaking changes over time.
PSDImporter 7.0.0-pre.3 should be available for download via PackageManager (you might need to turn on show Preview Packages) if it’s blocking you for now. As for allowing users to set custom swizzle mode, we will try to get it out in the next version (pre.4).
For exposing APIs, the reason you mentioned is dead on, that is one of the reasons why we are careful and selective in exposing APIs. In 7.0.0-pre.3, we have also exposed certain common settings APIs that users have been requesting.
As API goes, we would like to make sure that when an API is introduced, it is truly robust and useful, thus any feedback and request sharing the use cases and needs for certain API will help us craft better APIs.
Ok, it works really well with the pre.3 release. Still using reflection obviously.
I get that about the APIs and I typically wrap reflection hacks in extensions to keep my sanity as intact as possible
Thanks for all the help!
1 Like