- Home /
Problem with materials after creating Asset Bundle
I have a script that creates asset bundles. I pulled it from http://unity3d.com/support/documentation/ScriptReference/BuildPipeline.BuildAssetBundle.html?from=AssetBundle and used it in its entirety.
When I load the asset bundle at runtime and instantiate a prefab via GameObject.Instantiate(), the material associated with the prefab has all of the transparent areas replaced with yellow and the rest of the material is a pseudo-negative image. However, the textures are loaded just fine. It's only the materials that are affected.
I am using the EZGUI and SpriteManager2 plugins. This may or may not be a factor. Before including these prefabs in the asset bundle, they worked perfectly. What could be causing the yellow negatives in the materials?
I haven't seen that particular problem, but you might be right to suspect those plugins. It may be helpful to try and reproduce the problem using the simplest setup possible -- won't necessarily solve the problem, but could help narrow it down.
We figured out that any texture that is imported as a non-compressed texture such as Automatic True Color or Automatic 16-bit, when it is attached to a material on a prefab that is included in the asset bundle, it comes out looking as described above. The transparency areas are all yellow and the rest of the image is a negative image.
Is there any way we can use non-compressed textures attached to materials, attached to prefabs in an asset bundle?
Also, FYI, our asset bundles are targeting iPhonePlayer.
Any update to this? I also have similar issues but in my case the loaded texture from an asset bundle is purple-ish and semi transparent.
No new updates. We have since moved away from the asset bundles, because of that issue.
Answer by ncoder · May 29, 2012 at 10:57 PM
This might or might not help you:
We do this after loading a bundle:
var materials = bundleEntry.bundle.LoadAll(typeof(Material));
foreach(Material m in materials)
{
var shaderName = m.shader.name;
var newShader = Shader.Find(shaderName);
if(newShader != null)
{
m.shader = newShader;
}
else
{
Debug.LogWarning("unable to refresh shader: "+ shaderName + " in material " + m.name);
}
}
We also make sure that all our shaders are under a "Resources" folder, so that they are available at runtime regardless of usage.
This seems to be required only on Windows and iOS (possibly other platforms), but not on MacOS. There was some speculation that this is because shaders are considered "code", and not included in the bundle.
Note: This method is not perfect, since modifying assets in an asset bundles causes other errors. I'm investigating a good fix to this last one right now. It might work fine for your uses, though.
Asset bundles have many undocumented gotchas. good luck.
works well for most shaders, but those with rendermode set to transparent or fade suddenly get a different z-buffering behaviour ;(
Answer by Evil-Dog · Apr 30, 2012 at 01:30 PM
I was having a somewhat similar problem that you have seen in my comment, maybe this "solution" is not related at all to your problem but here it is. My issue was simply that I was using assetbundles of the wrong type. Basically I was targeting Android but when testing on PC, textures from the android bundles would show up as corrupted, in my case, purplish and semi transparent. But on the android device it was fine. To see the stuff well on PC, I needed to make PC asset bundles. That's determined by the target you pass as parameter in BuildPipeline.BuildAssetBundles. So not a real issue, just a misunderstanding of the asset bundles on my part. Hopefully, your problem was the same thing.
No I'm strictly building for pc in both cases (bundles and main game) and my problem was solved by refreshing the shaders, however, this fix actually breaks transparent shaders that were working before the fix. $$anonymous$$y intermediate fix is to include some data in the assetbundle telling the main game exactly which materials to refresh and which to leave alone :(
I have the same problem with the unity 2019.3.12f. What is exactly your intermediate fix ?