Unity 4.6 Sprite reference is randomly changing

Hello everybody,
I have a strange issue.
I'm using AssetPostprocessor to reimport assets at certain conditions.
Before the post process, I'm resizing all image files in project.
During the post process, I'm modifying rects of all sprites to fit the new resized image.

This was working perfectly in 4.5.0 (did not updated Unity ti'll 4.6.0).
But now, every time I run my scripts, some of the sprite reference in the project (across all scenes and maybe even prefabs) get messed up and reference a different sprite then the one they are supposed to.

And not only that, it's also random... the renderes that get messed up are random and the new sprite they reference to is also random (from within the same atlas).

Here is a code snippet of what I'm doing with the sprites:

Code (CSharp):

1.                     var sprites = newTexImp.spritesheet;
2.                     for (var i = 0; i < sprites.Length; i++)
3.                     {
4.                         var rect = sprites[i].rect;
5.                         var newRect = new Rect(rect.xMin*asset.Value, rect.yMin*asset.Value, rect.width*asset.Value,
6.                             rect.height*asset.Value);
7.                         sprites[i].rect = newRect;
8.                     }
9.                     newTexImp.spritesheet = sprites;
10.                     newTexImp.spritePixelsToUnits = asset.Value;

Any help will be appreciated.

 

Your sprite references are hardcoded? Like for example you have a spriterenderer that will assing the sprite from the array of index 0. Because I have done a small utility for myself to write down to a text file all rects of an atlas and noticed a strange behaviour. Everytime I would change something in the atlas the complete order of sprites in it get randomized breaking any direct index reference.

I solved this by searching the sprite reference by name instead of index from the array using a List with a lambda operation.

 

My sprite references are not hard coded. they are just references made manually by dragging the sprite to the renderer component.

 

Any help on this? this is preventing me from upgrading to 4.6...

 

Update:
I found the actual issue (not what is causing it).
If I open the meta file for the atlas in good project and a bad project, the values under fileIDToRecycleName are mixed up.
Any ideas?

 

Update:
I found out that the original meta file does not contain fileIDToRecycleName.
Unity is adding it at some point (not sure why).
So what I did to solve it, was a script that runs on all sprite meta files and removes the fileIDToRecycleName section.
Now everything is back to normal.

 

Could you send us the project which used to work with 4.5?

 

sorry, but there is no way I can send you an example project, too many scripts are involved.
But I can describe what my scripts do in more detail:
What I'm doing is copying the entire project folder.
Then, I resize all image files in the project by half using Image.size (I think its called) a .net library not something of Unity.
After that is done I'm opening the new project (also via script) and during the asset post process, I'm changing all sprites and modifying their rect so it will fit the new reduced size.

 

Why don't you reduce the max texture size limit instead?

 

I actually can't recall why we decided to reduce the actual size as well (I am reducing the size limit).
But we had a reason for doing that.

 

Well then perhaps you could use OnPreprocessTexture to achieve the same goal without copying the entire project?

 

I can try, but I'm actually going on vacation tomorrow and won't have time to try it until I'm back (in 3 weeks).
I'll try reproducing it without copying and see what I come up with once I'm back.

BTW, can you share some information about the fileIDToRecycleName section in the meta and what is it used for?
Might help me figure out if I'm doing something wrong.

Thanks

 

It's used to keep the correct id of an asset after its name is changed or minor adjustments to its size in a multi-sprite case are done. Without a repro project I can't tell if it is misbehaving.

 

I'll try my best to get a repro project as soon as possible.

 

@TomasJ seems like this might be fixed in 4.6.1p5 (maybe earlier).
I recently triad my script with 4.6.1p5 and didn't see any issues.
If I'll stumble upon this again, I'll make a repro project and report back here.