public sealed class ProjectMaterialBakerPuts a baked texture set into the project and says what assets it became.
Remarks
docs/plan/48 § D11's last paragraph. The bake writes, per texture set, one file per channel, one .vxmat naming them, and the provenance block — and it writes them through the asset database's scan-then-read-back sequence rather than minting an id.
⚠ A scan rather than an import, and the difference is what mints the identity. A file in Assets/ has no AssetId until the database has seen it and written a .meta beside it. So the bake writes, scans, and reads the GUID back — ProjectMeshBaker's dance, for its reason.
⚠ Two scans, and the second one is not a tidiness. The .vxmat names its maps by AssetId, and those ids do not exist until the maps have been scanned — so the material cannot be written in the same pass as the pixels it references. Writing it first with null references and patching them afterwards would leave a material on disk that resolves nothing for as long as the second pass takes, which is exactly the window a crash picks.
⚠ Re-baking overwrites and keeps every GUID, so every entity already pointing at the material picks up the new maps. That is what a person re-baking means, and a second set each time would leave a project full of ShipHull_2 while every mesh went on reading the first one.
⚠ Which is why the set is keyed on the source and not on the name. "The same graph again" and "another graph that happens to be called the same thing" produce identical file names, and keying on those made the correct behaviour above into a silent swap of one material's maps for another's, GUIDs and all — ProjectMeshMapBaker has the same fix for the same defect, filed as #681. ⚠ And the source is a folder as readily as an asset — see KeyOf, because the asset-only form of this guard could not be reached by the one caller that exists.
⚠ A file goes only when the bake can prove it wrote it. Both hazards this handles — a map whose extension changed and an output that is no longer produced — are answered by the digest in this material's own sidecar, never by the file's name. See Prune for what deleting on the name alone destroyed.
⚠ And a painted-over output stops the bake. § D4's digest exists so that a file whose bytes are no longer what the bake wrote is flagged rather than overwritten, because the most common reason for the mismatch is that somebody painted on it. See Painted; force is how a person says they meant it.
Fields and properties (3)
public string FolderWhere baked materials go, relative to the project's assets.
public IReadOnlyList<string> WrittenThe files the last bake wrote, as full paths.
public const string OverpaintHow an overpaint refusal ends, and the only IOException force answers.
Methods (4)
public ProjectMaterialBaker(EditorProject project, string folder = "Materials")Puts a baked texture set into the project and says what assets it became.
public MaterialBakeSet Write(string material, IReadOnlyList<MaterialMapImage> images, MaterialBakeRecord record, bool force = false)Writes a set's maps, its material and its provenance into the project.
public MaterialBakeSet WriteSplat(string material, MaterialMapImage image, int layers, MaterialBakeRecord record, bool force = false)Writes a splat map beside a layered material and binds it onto the feature.
public string? Unbindable(string material)Why WriteSplat could not bind a map onto this material, or null.
Used by (5)
- MaterialBakeAssetTestsVixen.Editor.Assets.Tests
- MaterialBakeRouteVixen.Editor.Texturing
- SplatBakeDeviceTestsVixen.Editor.Texturing.Tests
- TextureGraphRunnerVixen.Cli
- TextureRunnerVixen.Cli