"ModelRenderer.Tint on flat-color vmats causes purple/black corruption"
You set a per-instance ModelRenderer.Tint for subtle brightness variety on props that use a flat-color vmat (white PNG + g_vColorTint + g_flModelTintAmount 1.0). Two defects appear:
- Hue rotation — a tiny independent per-channel jitter like
Color(1 +/- 0.05, 1 +/- 0.05, 1 +/- 0.05)turns green props purple/teal and grey props navy/maroon. - Random black instances — a uniform grey tint at any value off exactly white (above or below 1.0, e.g.
Color.White * 0.94) crushes a random subset of instances to solid black.
Flat-color props bake their intended color into g_vColorTint. The renderer's model-tint path multiplies g_vColorTint by ModelRenderer.Tint, and this compound multiplication amplifies small deviations in ways that a normal albedo texture would absorb. The tint math says +/-5% can't reach purple or black — and it literally can't for a standard albedo. The amplification is entirely in the flat-vmat model-tint path.
Set Tint = Color.White (the default) on every flat-color prop. Do not use Tint for per-instance variety on these materials.
For visual variety on a scatter of flat-color props, use scale jitter and yaw rotation jitter instead — these produce the "uniform specks, barely-perceptible variation" look without touching the color pipeline.
Isolation test: renderer.Tint = Color.White → every prop renders its true color; any non-white tint → scattered purple/black. Trust the isolation test over the arithmetic.
The g_vColorTint x ModelTint compound path is the same family as the MaterialOverride double-tint trap. In this case it bites even with the model's own material (no override) and even a near-white tint value.