ProjectMeshMapBaker

Remarks

Doc 48 § D12's last line, application side. IMeshMapBaker is the seam Vixen.Editor.Assets declares and this is the half that knows about the asset database — the same arrangement ProjectMeshBaker has for doc 24's block-out bake, and it is that file rather than a new idea, deliberately.

⚠ Ordinary files with ordinary sidecars, and § D12 says why in one sentence: an artist wants to look at the curvature map when a generator misbehaves. The same pixels written into Library/ would be a cache — invisible in the browser, unopenable, un-referenceable by a material, and gone on the next clean. What lands here is a PNG a double-click opens.

⚠ 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, and § D11 names it as the sequence a material bake must use too.

⚠ The sidecar is finished afterwards, and it has to be. AssetDatabase.Scan mints a sidecar with a GUID and deliberately no importer key — which importer claims a file is decided at import time, and a guess written there would be a fact the file asserts and nothing checks. But a mesh map is exactly a file whose bytes do not say what they mean: an id map that gets a mip chain and an object-space normal map read as a tangent-space one are both silent. So the settings and the usage are written into the sidecar the scan just made, keeping the GUID it minted.

⚠ Re-baking overwrites and keeps every GUID. Baking the same mesh twice is an artist raising the ray count, and a second set each time would leave the project full of Barrel_ao_3 while every generator went on reading the first one.

⚠ Except over a map somebody has painted on, which is the sentence the one above stopped one step short of — #716. Overwriting is right for a re-bake of untouched files and is exactly what must not happen to a file an artist has edited, and until DigestKey existed nothing here could tell the two apart. Painted is the check; force is how a person says they meant it.

⚠ The hash comes from Digest rather than being spelled again here, which reads as a mesh map borrowing a material's type and is the point: a sidecar digest that a person, a tool or the next bake may compare across the two bakes has to be one spelling — sha256: and lower-case hexadecimal — and a second private SHA-256 is how the day arrives when the two disagree about the prefix.

⚠ Which is why the set is keyed on the model and not on the name. "The same mesh" and "another model's mesh with the same name" produce identical file names, and the second one is Blender's default object name — so keying on the name made the correct behaviour above into a silent swap of one model's maps for another's, GUIDs and all. The model's id goes in the sidecar (ModelKey) and SetName is what reads it back.

Fields and properties (2)

• public string Folder

  Where baked maps go, relative to the project's assets.

• public IReadOnlyList<string> Written

  The files the last bake wrote, as full paths.

Methods (2)

• public ProjectMeshMapBaker(EditorProject project, string folder = "MeshMaps")

  Puts a mesh's baked maps into the project and says what assets they became.

• public MeshMapSet Write(AssetId model, string mesh, IReadOnlyList<MeshMapImage> images, IReadOnlyList<string> warnings, bool force = false)

  Puts maps that have already been baked into the project.

Used by (4)

• EditorApplicationVixen.Editor.App
• MeshMapAssetTestsVixen.Editor.App.Tests
• MeshMapGeneratorBindingTestsVixen.Editor.App.Tests
• MeshMapLibraryTestsVixen.Editor.App.Tests