How automatic optimization on build works

This page is an explanation. If you want to upload right now, see VRChat.

In one line

Automatic optimization is on by default. There is nothing for you to do.

It makes the upload and build copy lighter, and returns your working materials to an editable state.

This applies unchanged to the MingToon copy the Setup Wizard makes. There is nothing to switch on at the end of the wizard, and what you upload is the copy, not the original.

Confirming it applied

1. Get the C# and shader errors in the Console to zero.
2. Check the environment conditions with StudioRaming > MingToon > Validate Project.
3. Check the candidate count, swap count and face normal bake count in the build log.
4. Open StudioRaming/MingToonOptimizeReport.txt next to the project folder.
5. On VRChat, check your own view, a mirror and the Photo Camera separately.

In a VRChat project, [MingToon] VRChat build hook compiled and registered. appears in the Console once per session.

Where to turn it on and off

All three are on the Automatic upload optimization card of the MingToon Manager's Optimize tab.

Item	Default	What it does
Optimize On Build / Upload (Applies To Everything)	On	Turns this whole feature on and off. It is not a per-character setting but one switch for the whole editor, so turning it off here turns it off for every other character's upload too
Allow Build/Shader/Mesh Hooks During Play (Opt-In)	Off	Runs the build, shader and mesh processing hooks in Play mode as well
Reviewed Texture Rewrites On Build (Opt-In)	Off	Additionally permits reviewed texture reprocessing

When you turn the first one off, the two opt-in toggles below it fold away on the card. Turn it on to get them back.

The Prepare for upload section of the Start tab only shows the current state of the same switch (On / Off) and has no toggle to change it. To change it, press Change in Optimize next to it.

You also choose a method per avatar. This avatar's build and upload optimization mode is on the top card of the Optimize tab.

Method	When
FastUpload (Recommended)	The default. It uses a shared shader to shorten upload time
Legacy GPU Precision	Only when you need the older per-material bake

The method for a manual bake (an upload preview) is separate. You choose it in the Look tab under Lightweight Shader Bake (Editor Only). → Manual Bake and Restore

What happens

1. It collects the MingToon materials referenced by shipping Renderers and AnimationClips.
2. It analyzes which features are actually used and which values are animated.
3. It creates a lightweight shader with fixed features folded to constants, or pulls one from the cache.
4. It swaps the materials' shaders to the lightweight ones for the duration of shipping.
5. It runs the platform-specific extra processing.
6. It returns everything to its original state when it finishes, fails, or a domain reload happens.

Generated shaders keep the same property contract as the editing shaders.

Values that only change during a build are not folded into constants. A successful build remembers the generated profile and source cache and reuses them on the next build of the same avatar. How much faster a warm build feels depends on the scene and shader-cache environment.

How different materials share shaders

FastUpload (Recommended) plans sharing for materials in the current build. It groups matching render states and required passes, then folds only values common to the group and safe from external access. Different colors, textures, and settings remain material data, preserving differences between avatars.

The plan belongs to one build. It does not automatically merge shaders from other avatars uploaded separately. GPU time, draw counts, and memory savings in a crowd of different avatars require separate measurements.

Extra processing on VRChat avatars

• It leaves the Depth Availability value alone. Auto ships as Auto.
• It bakes face normals into UV7 of the upload copy's Mesh.
• Renderers whose Face SDF uses UV7 keep the Live path for the same result.
• It applies the per-slot-kind texture resolution limits to the outputs it creates by merging or packing.
• It turns on the VRC Light Volumes variant automatically.
• It preflights mask input receipts before a manual bake or upload. An unprepared input skips only that mask optimization.
• It marks MingToon runtime components as IEditorOnly. Deletion is not guaranteed.

The face normal upload output uses a different path from the editing mesh bake. It does not overwrite the editing Mesh.

It does not touch animated values

The analyzer follows AnimationClips, Animator Controllers and nested fields on components. Features you will switch at run time need the inspector opt-in on so they are not folded to constants.

• Switch Depth Effects From FX
• Switch Shadow Projection From FX
• Use VRC Runtime Controls

An opt-in keeps the switching possible but also keeps the related code. Turn it on only for materials you will actually change.

The VRChat depth Auto contract

Auto reads the depth texture and Photo Camera state directly, per camera. The upload hook does not rewrite this value, so Auto ships as Auto.

An avatar that needs depth carries a depth light instead. The material values are not changed. → VRChat depth light

Mirror blocking is separate. Even with Force On, depth modules are off in mirrors. → How far depth effects are guaranteed

Texture resolution limits

Texture Resolution Limits (On Upload) is in the Reduce texture size section of the Optimize tab. The setting is shared by the whole Unity editor, not by one project. It is stored in the Editor preferences rather than a scene or prefab, so it applies equally to every character and to other Unity projects on the same PC.

You set a maximum resolution per slot kind, such as base, normal, matcap and mask. No limit keeps the output size as it is. The limit does not change the original textures' max size or compression import settings; it applies to the main, normal and mask outputs that are newly created by merging or packing. An original texture used as it is does not shrink with this setting. Automatic processing during build and upload applies only while Optimize On Build / Upload (Applies To Everything) above is on.

The texture rewrite opt-in

Reviewed Texture Rewrites On Build (Opt-In) is off by default. Turn it on to permit surface and normal flattening and reviewed mask repacking.

If you turned it on, compare before and after by eye

Reading, color space, mips and platform compression can change the pixels.

Mathematically lossless deduplication keeps applying even with this option off.

The constraints that follow

Recoverable failures are isolated and fatal ones stop the build

A recoverable error, such as analysis failing on one material, returns just that material to editing and leaves a warning. An error that makes result consistency impossible aborts the build.

Saving only applies to assets MingToon changed. It does not save unrelated assets along with them.

If the editor exited mid-build

Shader swaps and texture rewrites are recorded in a journal on disk. They are recovered automatically at the next domain reload, and if that still fails, check the per-item failures in the Console.

Discard a leftover recovery journal with the menu below.

StudioRaming > MingToon > Advanced > Discard Pending Generated Shader Recovery Journal

This command only discards recovery information

It does not revert generated shaders left by an aborted bake. The next bake creates them again.

When you do need a manual Bake

Situation	Automatic optimization	Manual Bake
VRChat upload	Sufficient	Not needed
WARUDO mod build	Sufficient	Not needed
Handing over baked material assets directly	Not possible	Needed
Comparing and approving results in the scene	Not possible	Needed

Entry points by platform

Platform	Entry point
VRChat avatar	VRC SDK build callback
WARUDO mod	UMod build processor
General Player	Unity build preprocess callback

VRChat work is split into stages. MingToon isolates input ownership on the build copy before MA (Modular Avatar), then physically prepares meshes and textures after MA has generated its output and before AAO (Avatar Optimizer). Animation dependencies and shaders are analyzed after the final transformations.

Not all preparation finishes before MA. Prepared output stays on the build copy and does not overwrite working meshes or materials.

Related pages

• Cleaning the generated shader cache: the Clean generated files section of the Optimize tab, or StudioRaming > MingToon > Advanced > Clean Build Optimization Output
• Making the copy with the wizard: Setup Wizard
• Fixed distribution assets: Manual Bake and Restore
• Platform checklists: VRChat · Warudo
• If you have errors: Troubleshooting