flutter3d_build_hooks 1.0.0-rc.2

What a package's build hook needs to compile its flutter3d materials into shader bundles, with no converters, servers or Flutter behind it.

1.0.0-rc.2

Since the 2026-10-14 upload, a plugin's material compiles in its namespace. compileMaterial(namespace:) names the stages <namespace>__<Name> so a plugin's lighting model finds them, and materialMemberName is the one naming scheme for generated material code. Nothing that went up on 2026-10-14 broke.

• A material lit by the standard model compiles with its debug twin. compileMaterial writes <name>Debug beside the material's stage, the same source with F3D_DEBUG_VIEWS, so the stage it draws every frame carries no debug view and a frame with one on still shows it.

• New: materialMemberName, the one naming scheme for generated material code. A uniform's accessor is named as the source declares it, with Value after a name Dart, the accessor or a typed uniform block already has; flutter3d_build's typed uniform blocks name their fields with it too. name, members, layout, stage and the rest of Dart's reserved words join the names that take Value.

• compileMaterial(namespace:) compiles a plugin's material in its namespace. The bare name the source writes (material Hair) is the stage <namespace>__Hair (materialStageIn), every stage and the source the bundle carries renamed to match, so the plugin's lighting model finds it; a name in another plugin's namespace is refused.

• A material over the binding budget does not build, on any backend. Each stage is counted from its GLSL before the sections are written, where only the WebGPU section counted, and only with glslang and naga installed.

• Breaking: a generated material accessor is over a MaterialParameters, the shape RenderMaterial.parameters has, and its defaults() answers one. A vec3 or vec4 uniform whose name says it is a colour says in its doc that the vector is the linear buffer the shader reads.

• A material build asks the backends' own compilers. MaterialCompilers.registry (and MaterialCompilers.locate(registry:)) holds a MaterialCompilerRegistry; compileMaterial hands each compiler the stages as GLSL, the engine's headers and the WebGPU stages it wrote, and puts its section in the bundle. A compiler whose section the build writes with a tool of its own (isSectionWrittenByBuild, Impeller's) and that refuses leaves the build's section; any other refusal fails the build. Without glslang and naga WebGPU's compiler is not asked, and the bundle goes without its section, as it does with no registry.

• Stages that disagree fail the build as a MaterialBuildException naming the source, where a StageAgreementException from a section writer used to escape as itself.

• A material's own blocks and textures are numbered after the engine's in its WebGPU section, in its slot table's order.

• Depends on flutter3d_foundation instead of the plugin API, for the exception family MaterialBuildException is of.

• New: the material compiler a build hook needs, on its own. compileMaterial, MaterialCompilers, MaterialBuildException and generateMaterialAccessors moved here from flutter3d_build, which still exports them under the same names. A package that compiles its own materials in its build hook, as flutter3d_effects does, depends on this and no longer resolves flutter3d_build's converters, MCP servers and dart_mcp into every game that depends on it.