Material property management

[al2me6]

A complete overhaul of how dynamic shader properties are handled for parts. Rewrites how vanilla uses (read: attempts to use, largely incorrectly) MaterialPropertyBlocks, and also provides an API for other mods to apply their own MPB-based changed without overwriting the vanilla features.

In brief, vanilla uses a single part-level MPB to implement the following:

• Making unattached parts semitransparent in the editor, directly implemented in Part;
• Coloring overheating parts orange in flight, implemented in MaterialColorUpdater (which, astoundingly, accidentally instantiates all of a part's materials due to calling Renderer.material instead of sharedMaterial);
• Implementing the "rim highlight" effect when hovering/highlighting a part. This is a Fresnel-like effect that tints the part mesh at grazing angles, separate from the glow effect that surrounds the entire part (which is implemented by HighlightingSystem, independent of the part's mesh);
• Implementing the glow effect on certain asteroids and comets;
• And implementing arbitrary changes made by any ModuleColorChangers. How this works given that the MPB is never reset is unclear to me.

This PR Harmony-patches all of the above usages to become consumers of the new API.

Custom properties are specified using instances of the Props class, which offers an MPB-like API. In addition, there is a Priority field, which determines precedence when multiple Props set the same property on the same renderer.

There is a singleton class MaterialPropertyManager.Instance, which can be used to Register a Props class to be applied to a particular renderer. This only needs to be done once per renderer, and a single instance of Props can be registered for any number of renderers. Any subsequent changes made to that Props instance will be transparently applied to its registered renderers, in LateUpdate. Reusing a single Props for multiple renderers is encouraged, since all renderers sharing the same set of Props will share the same underlying MPB.

Multiple Props registered against the same renderer will be combined, with conflicts resolved by order of highest Priority. Properties set by vanilla code, as listed above, have priority int.MinValue + 1, except for those set by MCC, which have priority 0.

[al2me6]

@gotmachine: I've been working on this for a while. Do you think it better belongs here, or in KSPCF? It does touch/fix stock issues, but I feel like the approach is too invasive/not enough of a 1:1 replacement for KSPCF.

[gotmachine]

Well TBH I think Shabby as a whole could be part of KSPCF. Both mods have broadly similar goals and are touching similar stuff in the same way.

As for this specific PR, you're likely better informed than me to make that call. I'm not opposed to radical modifications to the stock implementations, as long as stock end user facing stuff is untouched and that the modding ecosystem fallout is assessed and either inexistant or manageable from our side.

[al2me6]

Yeah that's fair re. Shabby/KSPCF overlapping. In this particular instance my main hesitation is that any mod which directly writes to Part.mpb will break. I am aware of two mods that do this: LazyPainter, for highlighting parts of the mesh that can be recolored, and KAS, for highlighting pipes.

Mods applying their own MPBs to the part hierarchy will also break, but I am not as concerned about this, because it's rather difficult to do that correctly and this is intended to address that. Technicolor will be the first external consumer of this API.

This seems to be a bit too much breakage for my liking, but if you think differently we can move it.

But in either case, I would appreciate a code review from you if you have time, particularly around Harmony patching and garbage management.

[JonnyOThan]

Shabby's scope has certainly expanded, and some of the newer stuff does seem like a better fit in KSPCF. Can those new parts be cleanly removed from the rest of Shabby (Shader.Find replacement) ?

But ultimately inertia will probably win out here and we continue down the current path; that's fine too.

[al2me6]

Can those new parts be cleanly removed from the rest of Shabby (Shader.Find replacement) ?

Yes, MaterialReplacement is independent of shader loading. However I put it here instead of in KSPCF because it seems useless without external shaders to replace.

[al2me6]

Note: the material duplication patch should be moved to KSPCF before merging.