Bonsai: emit one SVG class per metadata value, and per layer where cut - #9494

Stacked on #9493, and should land after #9044.

This branch carries #9493's commit as well, because the layer-aware half here calls get_cut_material, which #9493 introduces — review the two commits after it (68f47d88, aa737cec), or wait for #9493 to merge and this reduces to those two. The second of them follows #9044's Category precedence, so merging this before #9044 leaves the two halves briefly inconsistent for models that set Category on the set item.

The problem

A drawing's EPset_Drawing.Metadata queries become CSS classes on each cut group. A query can resolve to several values — mats.Category on a layered wall — and the whole list was stringified into one class. A three-layer wall carrying a single Category came out as:

matsCategory-NoneNoneBrick

That matches no meaningful selector, and it's unstable: add a layer and the class changes. Separately, a list holding only None — mats.Category on a beam whose material has no Category — produced matsCategory-None, because a one-element list of None is still truthy.

The change

One class per value, skipping None entries and anything left empty by canonicalisation, de-duplicated:

before  matsName-GMRedHollowClayBlocksAIRGAPBRICKMODULAR312x214x7124x223x8
        matsCategory-NoneNoneBrick
after   matsName-GMRedHollowClayBlocks  matsName-AIRGAP  matsName-BRICKMODULAR312x214x7124x223x8
        matsCategory-Brick

Single-material elements are unchanged, so the common case sees no churn. Beams with an uncategorised material now emit no matsCategory class instead of matsCategory-None.

Material queries resolve per layer where the cut is one material layer. Otherwise a slab's concrete layer is tagged with the gravel layer's classes too — true of the element, false of that cut — and once those classes match selectors, whichever rule sits later in the stylesheet paints it wrongly.

This was found live rather than by inspection. A footing merged with a slab's concrete layer rendered with the gravel pattern:

423  .matsCategory-Gravel   { fill: url(#gravel); }
447  .matsCategory-Concrete { fill: url(#concrete); }
459  .matsCategory-Gravel   { fill: url(#gravel); }   <- later, wins

because the merged group inherited matsCategory-Gravel from the slab element. After the change each layer group describes itself:

slab, concrete layer group : matsName-CONCRETETHICKEDENEDGE      matsCategory-Concrete
slab, vapour layer group   : matsName-10MILVAPORBARRIER…GRAVEL   matsCategory-Gravel
slab, whole-element group  : both names, both categories          (unchanged - no layer)

The whole-element cut group of a multi-material element still carries every value, which is right: that cut really does span them all.

Why per-layer here, when #9493 deliberately did not redirect material.*

Worth stating, since the two decisions look contradictory. In JoinCriteria the query runs against an element, and which layer is in play is invisible in the query text — so redirecting the word would hide something the author cannot see, which is why that PR introduced an explicit cut_material instead. Here the <g> is the layer: every other class on it (IfcMaterialLayer, layer-material-*) already describes the layer, so a class claiming otherwise is simply wrong about the element it is attached to.

If reviewers prefer symmetry, the alternative is to teach Metadata the cut_material. head too and leave mats.* alone — but then existing Metadata settings keep producing the mis-tagging until each user edits them.

Behaviour change worth flagging

This makes previously dead classes live. Any element with several materials only ever emitted the concatenated form, which matched nothing; those elements will now match single-value selectors already present in stylesheets. That is the point of the change, but it can alter existing drawings — in the test project, 43 elements begin matching a .matsCategory-* fill rule they never matched before.

Related

• material.Category doesn't seem to work in EPset_Drawing's Metadata parameter.  #3844 — Dion noted the same wart from the other end: "If you use mats.Name it will turn up as things like matsName-Testy1MaterialTesty2Material."

• util.selector: resolve mats.Category via the material set item #9044 — resolves mats.Category through the material set item, now with a fallback to the material's own Category (25b2b4aa, added after I reported a model where that data would otherwise be lost). The second commit here mirrors that precedence for layer groups, so the same query gives the same answer whether or not the cut happens to be a layer. Verified together against that model:

  poche wall (layer has Category, material does not)
    element mats.Category  -> ['Materials']
    layer group class      -> matsCategory-Materials
  brick wall (materials have Category, layers do not)
    element mats.Category  -> [None, None, 'Brick']
    brick layer group      -> matsCategory-Brick
  slab
    concrete layer group   -> matsCategory-Concrete
    vapour layer group     -> matsCategory-Gravel
  

• Bonsai: per element drawing appearance via assignable CSS classes #8800 — also extends get_svg_classes; no overlap with these lines.

🤖 Generated with Claude Code