IMaterialSource

Remarks

IMeshSource's counterpart, and the same protocol for the same reason. A material is loaded, compiled and — where a feature samples one — has textures of its own to fetch, none of which can happen inside the frame that first asks for it. So this asks rather than waits: false means "not yet", the entity keeps no RenderHandle, and next frame's reconciliation asks again.

An interface here rather than an AssetManager, because this assembly must not know what a bundle is. A renderer's business is a descriptor set; catalogs, addresses and claims belong to Vixen.Assets. Vixen.Engine.Renderer is where the two meet — see AssetMaterialSource.

⚠ What comes back is a shared Material, not a copy. Two entities naming one material get one object and therefore one descriptor set, one uniform block and one slot in Materials — which is what makes a level of a thousand crates cost one material rather than a thousand. An implementation that compiled per ask would be correct and would multiply the frame's per-material work by the instance count.

Methods (1)

• bool TryGet(AssetReference reference, out Material material)

  The material a reference names, if it is ready yet.

Used by (5)

• AssetMaterialSourceVixen.Engine.Renderer
• DeferredMaterialVixen.Rendering.Tests
• MeshExtractionSystemVixen.Rendering
• OneMaterialVixen.Rendering.Tests
• WorldRendererVixen.Engine.Renderer