Warning to all my friends: BEWARE Optimise Mesh Data!!

I just spent several days trying to figure out why I kept getting an error when combining a specific mesh, only in build. It was SO strange, since it was only due to that mesh, and doing certain things would "fix" it, but in an incredibly strange manner.

Turns out I stupidly enabled "Optimize Mesh Data" (Strip Unused Mesh Components) in the player settings without knowing what exactly it does.

Edit: turns out its on by default, so it wasn't stupidity

Soo yeah if you're having strange issues with meshes, try this simple trick! And don't randomly enable features without knowing what they do. :^)

I'll go back to banging my head against the wall.

Good luck :3

Related note, it'd be cool to have the option to choose what components are stripped, sort of like how you can choose what vertices are compressed.

 

Thanks for the warning, but uh, isn't it common sense? Do we need to be told that pressing things without knowing what they do cause problems? Honestly?

BRB someone said I had to type in format c:/

 

Kinda meant to be an ironic post lmao

 

I also had a problem with "Optimize Mesh Data" that took quite a few hours to figure out. I was loading Normal Maps at runtime, and they wouldn't show in the build because that feature was enabled.

 

Isn’t it enabled by default?

 

Irony.


I do not think that word means what you think it means!

Regardless, thanks for the heads up.

 

Scary part is Windows 10 just asks if you're positive you want to format. I wasn't crazy enough to hit Y to see what would happen on my main system. If I had a VM with snapshots handy I would totally have tried it.

 

meanie

 

We are getting a bit derailed.

I just checked. The checkbox is on by default. So I don't think the OP "stupidly" enabled it. It was always enabled.

It used to be very safe to leave on, but (semi)recently they changed its behaviour and it has been known to obliterate more data than it should (I have filed at least one bug report on this).

 

I knew it. When I saw in alerts that Ony had quoted my post, I KNEW I was gonna get told off. I dunno how, just knew.

 

hah! <3

 

Interesting to hear this wasn't my fault lol

 

We just encountered this issue ourselves! We have meshes for the 'characters' in our game that contain special 'skinning' data in UV0, UV1, UV2, etc. (Skinning as in 'ingame cosmetics' ). We have different shaders for different skins that make use of the various different UV channels for different effects.

The character mesh is assigned to the character prefabs mesh filter. The mesh renderer on the character prefab has a default material that only uses UV0. At runtime, we swap out the material to different ones that use UV1, UV2, etc. It works fine in the editor, but when the game is built these additional channels are stripped out since Unity thinks that the mesh will only be rendered with a shader that uses UV0.

It seems like this assumption is fine in most cases, we'd love to keep Optimize Mesh Data turned on, but there is no way to tell it to exclude meshes from the Optimization process so we have no choice but to turn it off for the entire project, just because of a handful of meshes that need to retain their UV channels.

The alternative way is to have a scene that contains every character mesh withe very possible material assigned to each of the meshes, and to include this scene with the build so that Unity wont strip out the channels, but that doesn't seem worth the effort for us. (size between optimisation on and off was about 2mbs for us, so not worth this hassle to save 2mb)

 

Same issue with me. Spent an hour to find that this was the cause of incorrect half4 texcoord3 UV mapping on Android (using 4 UV channels in custom CG shader).... when turned off, everything works. It didn't exclude UVs, just some coords were incorrect.

 

Have you tried to disable it for the entire project and write an AssetPostprocessor that removes unneeded mesh data, following whatever rules are needed in your project, instead?

That way "optimize mesh data" would work even inside the editor and you have per asset control.

 

thanks a lot, It saves my day

 

Million Thanks! Take me loooong time to figure it out before I saw this post.

 

fixed my mesh color problem, there were zero colors on my mesh on build.

 

I think mesh optimization should be disabled by default. Messing with mesh data without our knowing is kinda frustrating!

 

But 'optimize mesh data' sounds so harmless and downright optimal - who wouldn't press it? Unity needs a 'do not press this button' button.

 

Yeah so lets press things we think are harmless. I mean why is it optional?

Why would something 100% benign be optional?

 

It's enabled by default, so none of this is even relevant.

 

I don't know if it was something I changed, but it used to work pretty well many years ago. (like it was a no brainer to have it on).

At some point it started obliterating more data than it should. I haven't bothered to turn it on again since.

It would be nice if there was a way it could tell you what kinds of things it is going to get rid of.

Or, maybe Unity could not remove any data at all, and could just produce a list that says : "Hey I think these are going to be unused, maybe you should take a look".

 

Yeah its like saying why be nice when you can be sarcastic and rude! Its more quirky this way so lets just be sarcastic instead of trying to be helpful right?

For those of us not looking to get a cheap rise... Recluse has a good point. All the tooltip of that checkbox says is "Remove unused mesh components". I wouldn't call anyone wrong to assume this means removing things like MeshFilter and MeshRenderer from GOs.

The tooltip is terrible, if its stripping/compressing UV data it should say that :/

 

Not looking for a rise, in fact I couldn't think of anything more inefficient. The fact remains if something is optional, then it means you should think about it and read up on it.

Why wouldn't you?

https://docs.unity3d.com/ScriptReference/PlayerSettings-stripUnusedMeshComponents.html

I agree that the docs could also include this information on the manual part not just the scripting part. Any google does present it as a top hit, but that's not good enough, and Unity should do more documentation. On the player page you can report a docs issue and give it one star.

Again, not looking for a rise. But low tolerance for not looking up things, since I only got this far by always looking up things.

 

As joshcamas pointed out, it's enabled by default, not by game devs stupidly 'pressing things they think are harmless'.

As it is not '100% benign' it should probably be disabled by default, so devs can read up about it before they switch it on.

 

I agree but I'm wrong to just jump on them if it's only documented on the scripting side and not the manual side of things (although they probably were still naughty and didn't read up)

 

That's not useful at all. I have given one stars, confirmed with actual developers, raised normal bugs, raised doc bugs, some doc pages are just impervious to change.

It's best to accept that there is a chance the info you read on the docs is false, and move on with your life.

 

Adding to the original topic:

I don't know why "optimise mesh data" is not a per model import option and is instead a project wide option.

We currently have it off in our project, because out of the thousands of meshes in our game, it really messes up 1, so our only option is to turn "optimise mesh data" for ALL meshes. That's a bummer, isn't it? Surely we could have it on for 99,99% of our meshes and be able to turn it off for one mesh.

But I'm just wasting energy typing these. Even if someone from Unity takes a look, agrees, and cares, we are years away from something being done about it: This is the way Unity moves this day, and this is the way software development is done by software companies the size of Unity. And high profile hires are not going to work on petty stuff like these they'd rather work on new and shiny features.

I might as well talk to a wall, or piss in the wind.

 

There is nothing naughty about not reading up on every toggle or enum in sight. Coders are, among other things, bridges: we make systems talk to each other. We expect those systems to be robust and handle themselves. We wouldn't get anything done otherwise.

But let me back up a bit: I am all for Optimize Mesh Data and removing unused UV's, normals, and whatever it is it's doing. Less is more in optimization-land and I believe that the toggle should stay the way it is. However, some of my meshes need their normals not to be stripped. Since this is part of a package I'm working on, I can't just turn the toggle off: others will be using this, and others will indeed expect it to handle itself.

I want to get back to the simple question: is there anything like IOnPostProcessMeshStripping or any option to exclude stripping the normals of specific meshes, particularly ones that are part of a component? Right now I am recalculating the normals if necessary, but needless to say I would like to optimize this if I can so it doesn't need to happen at runtime but rather on build.

 

I'm in a similar situation as @AcidArrow . Just one mesh that is acting up and getting its vertex colors stripped (sadly it's an important one).
I would also love to WHY - because its shader is clearly using those colors. My super wild guess is that in my case asset bundles might be culprit (as they usually are).

I totally agree that this optimization should be possible to be at least overridden on a per asset basis OR made 100% bullet proof.

 

Which frankly is impossible if you ever intend on changing the materials/shaders on any of your meshes at runtime. Like using Reflection and having your code stripped because the compiler isn't aware the code is in use. You can hint to the compiler that the code will be used with a [Preserve] attribute, so it only makes sense that we should be able to opt-out of this option on a per-mesh basis - hinting to Unity that the mesh data is going to be used.

 

@Prodigga Sure, in my case I'm not doing even that though .
The ability to preserve components from stripping would be great of course.

 

I had this happen to my project, took me 3 days to find this thread...

 

Yeah, it's an annoying issue. Hence I think it should be disabled by default. :/

 

I am having this issue with insane build times that literally have my pc at 99% load with smoke coming out of the back and the smoke detector in my house ringing. The incredible power of Unity! I cannot compile my project at all. I didn't change anything shader-related. This issue seems to just have randomly appeared out of nowhere after implementing some render textures.

 

Just a thought, a workaround to avoid Optimize Mesh is to pack your mesh into asset bundle/addressable.

 

Holy S***!

Just been caught out by this myself and I've been developing with Unity for over a decade! Wasted a good 6 hours trying to track down why my custom PostProcessStack effect not working on Android, but worked fine in Editor and Win 10 builds!

The effect in question relied on using mesh vertex colors to populate a custom depthNormalsTexture for doing edge detection, but the output was a combination of the input vertex color, depth and normals. So while the effect failed on Android it did it in weird ways due to the interplay between shader generated data and the vertex colors. Of course since the vertex colors are only used for the effect no meshes in the scene used a shader that required the vertex colors and Unity ended up stripping them from the build.

Even now it feels like pure luck that i stumbled on this thread, with my gut feeling to double check what this setting did paying off when I could have so easily have dismissed it.

The shear stupidity of this setting, its name and its tooltip is mind-boggling! From its name 'Optimize Mesh Data' I figured it was just a global level setting for the model Importers 'Optimize Mesh' setting and as such i'd never touched it in a decade of working with Unity. The tooltip states 'Removes unused Mesh Components', well that doesn't apply to me I thought as I figured it removed mesh filters or something since they are components.

This really should be called 'Strip Unused Vertex Streams' since that's what the data is actually called that it removes!

Now i've got to go back and restore all the various code changes and tweaks i've made after discovering this one single option was the culprit.

 

Glad I could help! It's quite crazy that this toggle is on by default.

 

@hippocoder awsome moder, snaps at users for not reading "awesome" unity documentation, when he should know better than users that unity documentation is missing ~60% of data, and when you reading it you can with same effectiveness use Tarot cards or read stars, since documentation always missing critical data, misleading or just lying GJ
Did that unpleasant person at least apologized? nope, why, just insult other users

 

@dsavickij I don’t see the point of you getting upset over some posts that happened 4 years ago, that no one involved is or was upset about.

 

I also enjoy how they’re being mad about some “missing Unity documentation” that is right here, along with a lot of other very well documented info.

 

You mean the documentation that was 'improved' on years after the initial post, and yet appears to have made it worse by missing out the important part on how specific vertex steams are remove, that being 'If your shaders on meshes do not use a specific vertex channel it will be removed'. Neither does it point out that you should consider post-process shader requirements or the many other ways this feature can trip you up or that this has nothing to do with the model importer 'Optimize Mesh' setting.

Its a useful setting but quite hidden in the myriad of settings and defaulting to on is just a booby trap waiting to explode in a developers face with no idea as to why models/materials/shaders look broken or just stop working altogether.

 

The docs were never the problem in this case.

I don't know how it determines which vertex streams are used and which are not, but it's definitely flawed (and we're not doing shader switching at runtime, we do use custom shaders though).

It's one of the many areas where I wish there was more transparency about what it is doing (and how it is determining what is used and what is not).

Or maybe have the mesh import settings show all of the streams and let me choose which ones I need and which ones I do not?

It's one of those cases where Untiy decides to solve it automagically for you, but it needs to work 100% of the time to be useful and this feature falls short.

 

Partly agree in that it was never just a documentation issue, although the lack of clear information and warnings means its a simple setting that has the potential to break you build in weird and wonderful ways without the developer having a clue.

Totally agree in that as a feature it needs a complete reworking. From my experience with it, I would like to see such functionality applied at the model/mesh level in the importer. It can even default to the old behaviour as long as there is sufficient warning given to its effects, though with a more fine grained option or being able to selectively choose which streams to ignore or include, perhaps makes it more discoverable ( a problem the current setting has as it gets lost in all the other Player Settings ).

However i'm not entirely sure my use case covers the issue or the usability of others, so it would be interesting to see what other solutions there are.

 

There definitely seems to be something not quite right with this feature...

I've got a shader that only uses UV3 if a certain shader_feature is enabled. That's set up on a mesh in a scene, the feature enabled on a material, and I'm not modifying the material at runtime. Displays fine in the editor, but UV3 data is missing in builds (confirmed via RenderDoc).

I changed the shader_feature to multi_compile, and that seems to have solved the problem, the UV3s were no longer being stripped.

But that's not a good solution, as it's a big shader with too many multi_compiles already. And I may need 3 multi_compiles (other features of the shader optionally use UV2 and/or vertex colours!) - which could mean increasing the compile time of that shader by 8x to resolve this issue...

(I'm currently using 2021.2.9f1, with URP, and the custom shader is derived from the standard URP lit shader. The project uses addressables, which may be complicating the situation...)

 

I think the solution here would be to have it be a per mesh option and that also it would tell you what it's going to strip and why.

 

Yeah, a way to control this stripping per-model manually would be good, for cases where the automatic optimisation can't predict that you're going to need the extra data (e.g. changing material at runtime). Or the cases where it seemingly doesn't work as it should...

It'd also be great if we could extend the asset import settings UIs (see thread here, doesn't quite work) - We have AssetPostprocessor scripts, but there doesn't seem to be a nice way to control which assets they run on (without relying on naming conventions, or settings stored elsewhere in separate objects)

 

The problem with the proposed solutions above is if the default is to strip as there is no feedback and the data is stripped based on the currently set material/shader, but only in builds, which can make the behaviour very unpredictable if you are unaware of it.

I like the idea of it being per mesh in general, but then I'd imagine the default would likely be the same as the current one, and you'd have data stripped. So again a developer can be left completely in the dark as to why the project has totally broken see my original post - I was assigning custom data to vertex colours and using that data in a shader to produce a custom postprocesseffect, which meant that with the data missing my effect failed in weird ways that was difficult to reason/debug.

I feel that perhaps having some form of logging of the asset processing during a build might be the only reasonable way for Unity to at least inform the developer that data has been stripped from the mesh and what data was stripped and why.

Then again Unity doesn't seem to even be aware of this issue, let alone willing to address it, just like many others.

 

God bless you, good man!
You saved me a lot of time. I have spend 2 days wondering why my baked light texture doesn't apply correctly to my mesh when i switch LightmapSettings.lightmaps manually at runtime. It is because UV2 was stripped out during building. I was really desperate. Thank you for you post.