Skip to content

Authored (raw) models: not classifiable + custom attributes lost on read-back #36

Description

@GeekGio182

Packages: @thatopen-platform/fragments-beta 3.5.6, components-beta 3.5.6, components-front-beta 3.5.8
Context: code-authored model built with the Editor, running inside the platform app scaffold (deferred renderer + worker). Two independent bugs, filed together per Antonio's suggestion. Both confirmed by ThatOpen as engine-side.

Shared repro
const bytes = FRAGS.EditUtils.newModel({ raw: true });
await core.load(bytes, { modelId: "authored", camera, raw: true });

const mat = editor.createMaterial("authored", lambertMat);
const lt = editor.createLocalTransform("authored", new THREE.Matrix4().identity());
const rep = editor.createShell("authored", boxGeometry);

await editor.createElements("authored", [{
attributes: {
_category: { value: "wall" },
params: { value: JSON.stringify({ height: 3, thickness: 0.2 }) },
},
globalTransform: new THREE.Matrix4(),
samples: [{ localTransform: lt, representation: rep, material: mat }],
}]);

await editor.save("authored");
await core.update(true);
Baseline after this: the model renders, FragmentsManager.raycast / Highlighter select it, and model.getItemsData returns its base attributes. So the model exists and is partly queryable on the main thread.

Bug 1 — authored model not classifiable
classifier.byCategory() throws:

Error: Fragments: Model not found: authored
(worker-side, in getModel). The authored model is in the main-thread model list but not in the worker's registry, so the worker throws while raycast / getItemsData still work.

The classification loop has no per-model error handling, so one unresolvable model kills the entire pass. In the scaffold this hits the clipper's classification retry: it fails, retries every ~250ms, never settles → console flood + wasted work.

Workaround (in use): exclude authored models from classification.

await classifier.byCategory({ modelIds: [/^(?!authored-).*/] });
Expected: either authored models are kept in sync with the worker registry, or the classification pass tolerates a model it cannot resolve (skip instead of throw).

Bug 2 — custom attributes not returned on read-back
attributes.params written via createElements is absent on read-back:

const data = await model.getItemsData([localId], {
attributesDefault: true,
attributes: ["params"],
});
// only default attributes come back — params is missing
Confirmed by ThatOpen that the write path is fine (params does reach the raw item data), so the loss is on read-back / persistence, not on write.

Impact: no way to persist a per-element parametric recipe on the element itself; forces an app-side localId → params map that dies on save/reload.

Expected: arbitrary custom key/values set on an authored element survive save/reload and are returned by getItemsData.

Environment
OS: Windows 11
Dev: npm run dev (esbuild), app running inside the platform iframe
Happy to trim this to a smaller standalone repo if useful.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions