Unity is now at 70 minutes to load, about 25% of the way done

First it kept telling me an object I was trying to instantiate was null (a mesh assigned to the skinned mesh renderer). But it wasn't null... ...and it was working 15 minutes ago. I checked the FBX, and lo and behold, the mesh for the skinned mesh renderer was "missing", (even though it was in the FBX file as a mesh, it just for some reason was not assigned to the skinned mesh renderer). I could not just replace it, as this was in the FBX file, and everything was gray. So I re-imported the FBX by turning on material import (which I never use) and Apply.... ...and it took 5 minutes to apply.

Weird, I think,

But now the mesh is in the skinned mesh renderer in the FBX file. IT worked. Then I removed the material import by setting it to none, and Apply.... ..again, five minutes to apply. Weird.

But hey, now my mesh is there assigned to the skinned mesh renderer in the FBX. Now, where was I? Oh yes... ....BZZZT. "The object (the mesh assigned to the skinned mesh renderer) you are trying to instantiate is null" I can see it in inspector the mesh is clearly there.

Ok, I thinks, must be a library corruption. Restart Unity....

...and I have deleted Library folder before, and let Unity rebuild it. Did not do that this time. It usually took less than an hour to rebuild.

But right now, I assume it is rebuilding the Library folder.... and it is at 80 minutes now, 25 - 30% finished. Probably be done in a few hours... ...and something tells me, I am still going to get the same error, because it has NEVER taken this long before.

Luckily I backed up the project a couple hours ago....

 

Hours ago? I hardly go 15 minutes without making a proper source control commit.

You ARE using source control, right??

Keep in mind how Unity connects assets into code and how your manipulation of those assets can break those connections.

Some info about Missing script warnings, GUIDs, renaming GUIDs, etc:

https://forum.unity.com/threads/problem-with-git-and-missing-scripts.1090876/#post-7024801
https://forum.unity.com/threads/scr...ead-after-loading-editor.998413/#post-6487297
https://forum.unity.com/threads/scr...ead-after-loading-editor.998413/#post-6488230

EVERYTHING in Unity is connected to the above GUID, which is stored ONLY in the metafile.

This applies to scripts, assets, sub-assets, EVERYTHING.

It is super-easy to inadvertently change it by renaming outside of Unity. Don't do that. Instead:

- close Visual Studio (important!)
- rename the file(s) in Unity
- in Unity do Assets -> Open C# Project to reopen Visual Studio
- now rename the actual classes, and MAKE SURE THE FILE NAMES DO NOT CHANGE!

If you are NOT using source control while you do this, renaming files is an EXTREMELY dangerous process. Use source control at all times so that you can trivially revert if you miss a critical step and damage your project.

 

Regularly delete the library (like once a week?) at a time of your choosing, it makes these issues appear less often.

 

I didn't rename anything outside of Unity.

 

Anytime you edit an asset (such as FBX) you expose yourself to the program renaming (or re-ordering or re-parenting) that asset internally. When meshes and materials magically go missing, this is very frequently the source cause.

Also, unless you configure the project properly to use visible meta files, you risk running into loss of data when you go deleting the Library folder.

I'm sorry you've had this issue. Please consider using proper industrial-grade enterprise-qualified source control in order to guard and protect your hard-earned work.

Personally I use git (completely outside of Unity) because it is free and there are tons of tutorials out there to help you set it up as well as free places to host your repo (BitBucket, Github, Gitlab, etc.).

You can also push git repositories to other drives: thumb drives, USB drives, network drives, etc., effectively putting a complete copy of the repository there.

As far as configuring Unity to play nice with git, keep this in mind:

https://forum.unity.com/threads/prefab-links-keep-getting-dumped-on-git-pull.646600/#post-7142306

Here's how I use git in one of my games, Jetpack Kurt:

https://forum.unity.com/threads/2-steps-backwards.965048/#post-6282497

Using fine-grained source control as you work to refine your engineering:

https://forum.unity.com/threads/whe...grammer-example-in-text.1048739/#post-6783740

Share/Sharing source code between projects:

https://forum.unity.com/threads/your-techniques-to-share-code-between-projects.575959/#post-3835837

Setting up an appropriate .gitignore file for Unity3D:

https://forum.unity.com/threads/removing-il2cpp_cache-from-project.1084607/#post-6997067

Generally setting Unity up (includes above .gitignore concepts):

https://thoughtbot.com/blog/how-to-git-with-unity

It is only simple economics that you must expend as much effort into backing it up as you feel the work is worth in the first place.

"Use source control or you will be really sad sooner or later." - StarManta on the Unity3D forum boards

 

Or the importer just fails. I don't think you're correct in your assessment of it being a naming issue here.

 

My guess would be I somehow got around a Unity failsafe, as accessing and instantiating new skinned mesh renderers is the most frustrating thing I have done so far in Unity. To instantiate a skinned mesh renderer mesh instance with new vertices and vertex colors, and not have it change the original skinned mesh renderer I am trying to copy, I have to do this:

Code (csharp):

1.  
2.             Mesh mesh0 = SMR0.sharedMesh;
3.             Mesh meshInstance0 = Instantiate(mesh0);
4.             meshInstance0.colors = vertexColorStream;
5.             meshInstance0.vertices = verts;
6.             SMR0.sharedMesh = meshInstance0;
7.             SMR = SMR0;
8.  

and doing this for a LOD group is an even more extensive three card monty game. I thought it must be some massive performance thing that skinnedmeshrenderers must use shared meshes, but come to find out, I see no performance issue at all, with new instantiated copy meshes assigned to the skinnedmeshrenderers.

However, I was trying to decouple further, by assigning SkinnedMeshRenderers in a base library file that I could call whatever skinned mesh renderer I wanted. I am guessing somehow I modified the FBX via script.

Anyways, not a huge deal. We'll see if it is back to stable once Unity is loaded. If not, I'll just reload a backed up version of the project. In the meantime, I'll just model in Blender for a while.

 

So, it looked like it stuck at 25%. I killed it via task manager. Nuked the library folder. Unity rebuilt it in about 30 minutes. Unity had to recompile all the shaders too, but back to normal.