Some PSB have to be marked Read Write to use with Addressables?

HI, we have this strange problem we discovered when grouping our PSB assets (imported as UI / Sprite with Multiple checked) into Addressables. Some but not all PSB’s started throwing an error:

Texture is not readable, the texture memory can not be accessed from scripts. You can make the texture readable in the Texture Import Settings.

We are not doing anything with the textures except referencing the sprite images within the PSBs.

The thing is we have several PSB files, and not all of them cause the error, and I cannot see what the difference between them is in the import settings.

It does not seem to be related to the file size of the PSB because I have some very large ones that have no problem, and some smaller ones that have the problem.

As we have some very very large PSBs, we are not keen to have to mark these as Read/Write and cause any memory issues in our build.

Any ideas on what could be going on here?

Hello @Gordon_G ,
I would love to take a closer look. Could you file a bug report and let me know the ID of the bug?
Thanks!

Hey, I would love to do this at this point in time but I just don’t have time at the moment because we are in the process of getting our app out. It’s going to take me too long to get a project folder in there that could be tested, and we have a very complex project that I would have to pull apart to get just the scene loads where this seems to be happening.

Once we get past our first release (should be by then end of the month) I can get a sample project folder into a bug report.

But it sounds like there is nothing overt that you know of that would cause this to happen - nothing in the import settings or anywhere else?

I’d like to know what conditions could cause the error, because again we are not trying to access the pixels or anything in the child sprites of the PSB. If it were that Addressable references to sprites within a PSB is an issue, you’d think it would happen with every PSB.

Should I leave this thread open and update it when I have a chance in the future?

We do not have anything in the PSD Importer/2D flow that should give you this error. The best guess I have is that you might have some 3rd party tool that requires read & write enabled. Does the error give you any stack trace?

Unfortunately, I can’t really give you any more advice apart from this without getting access to the project/a repro project, so do let me know when you have the time to send a report, and I’ll take a closer look.

Hey Ted, sorry for the delayed reply - way too busy! We’re not using any third party tool with these graphics - all I am doing in referencing the individual sprites within the imported PSB.

Again, we have some PSBs that do not cause this and I cannot see any difference in the import settings. It does not seem to depend on size as we have some PSBs that are are over 20MB that do not cause the error.

Here is a stack trace from a 2MB file - maybe it will help. In the meantime I’m doing some more digging.:

Sprite outline generation failed - could not read texture pixel data. Did you forget to make the texture readable?
#0 GetStacktrace(int)
#1 DebugStringToFile(DebugStringToFileData const&)
#2 GenerateSpriteOutline(PPtr, float, RectT const&, Vector2f const&, float, unsigned char, bool, unsigned int, int, bool, dynamic_array<dynamic_array<Vector2f, 0ul>, 0ul>, SharedMeshData, RectT, Vector4f)
#3 Sprite::GenerateOutline(float, unsigned char, bool, dynamic_array<dynamic_array<Vector2f, 0ul>, 0ul>&, int) const
#4 Polygon2D::GenerateFrom(Sprite*, Vector2f const&, float, unsigned char, bool)
#5 PolygonCollider2D::SmartReset()
#6 AddComponentUnchecked(GameObject&, Unity::Type const*, ScriptingClassPtr, MonoScript*, core::basic_string<char, core::StringStorageDefault >, AwakeFromLoadQueue)
#7 AddComponent(GameObject&, Unity::Type const*, ScriptingClassPtr, core::basic_string<char, core::StringStorageDefault >, AwakeFromLoadQueue, char const*, dynamic_array<Unity::Component*, 0ul>)
#8 MonoAddComponentWithType(GameObject&, ScriptingSystemTypeObjectPtr)
#9 GameObject_CUSTOM_Internal_AddComponentWithType(ScriptingBackendNativeObjectPtrOpaque
, ScriptingBackendNativeObjectPtrOpaque*)
#10 (Mono JIT Code) (wrapper managed-to-native) UnityEngine.GameObject:Internal_AddComponentWithType (UnityEngine.GameObject,System.Type)
#11 mono_jit_runtime_invoke
#12 do_runtime_invoke
#13 mono_runtime_invoke
#14 scripting_method_invoke(ScriptingMethodPtr, ScriptingObjectPtr, ScriptingArguments&, ScriptingExceptionPtr*, bool)
#15 ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool)
#16 MonoBehaviour::InvokeMethodOrCoroutineChecked(ScriptingMethodPtr, ScriptingObjectPtr, ScriptingExceptionPtr*)
#17 MonoBehaviour::InvokeMethodOrCoroutineChecked(ScriptingMethodPtr, ScriptingObjectPtr)
#18 MonoBehaviour::smile:elayedStartCall(Object*, void*)
#19 DelayedCallManager::Update(int)
#20 InitPlayerLoopCallbacks()::EarlyUpdateScriptRunDelayedStartupFrameRegistrator::Forward()
#21 ExecutePlayerLoop(NativePlayerLoopSystem*)
#22 ExecutePlayerLoop(NativePlayerLoopSystem*)
#23 PlayerLoop()
#24 EditorPlayerLoop::Execute()
#25 PlayerLoopController::UpdateScene(bool)
#26 PlayerLoopController::UpdateSceneIfNeeded()
#27 Application::TickTimer()
#28 -[EditorApplication TickTimer]
#29 __NSFireTimer
#30 CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION
#31 __CFRunLoopDoTimer
#32 __CFRunLoopDoTimers
#33 __CFRunLoopRun
#34 CFRunLoopRunSpecific
#35 RunCurrentEventLoopInMode
#36 ReceiveNextEventCommon
#37 _BlockUntilNextEventMatchingListInModeWithFilter
#38 _DPSNextEvent
#39 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
#40 -[NSApplication run]
#41 NSApplicationMain
#42 EditorMain(int, char const**)
#43 main
#44 ???
#45 ???

Thanks for sharing @Gordon_G .
We have not been able to reproduce anything similar here, so we would still need some kind of repro project to take a closer look at what is going on. Best of luck with your project, and let us know when you have the time to share a repro.