A federated pick could be attributed to the wrong file. The model slot a
host sees — ElementRef::model_index, modelProgress's index — is a rank in
session_model_id order, and on web that id was minted at the END of the
sidecar read chain, after three network round trips. So the ranking was
the order the models' reads happened to finish in, not the order the host
added them. With ~40 similarly-sized models over HTTP, adjacent models
swapped and a click reported its neighbour's file; the host page then
asked for a GUID the file does not contain.
Mint the id at the top of loadSidecarMetadataWeb instead, which runs
synchronously from load_sidecar_from_source_c and therefore in the order
the host asked for its models. A load that fails partway just abandons
its id, and the ranks compact over the surviving models as before.
Positions are still positions, though: if one model fails to load, every
later index shifts down one and a host mapping index into its own list
silently drifts again. So also carry the source id — the handle the host
minted itself when it registered the file — through ElementRef into the
pick payload and getObjects rows, and document it as the way to attribute
an object to a file. ModelGpuData::web_source_id defaults to -1 now, since
0 is a real source id and cannot double as "none".
The test server grows a ?delay=<ms> knob so a test can force the losing
interleaving: georef-a is added first and served slowly, and its objects
must still come back as model 0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The desktop viewport draws an RGB triad in the bottom-left corner and a
second one at the orbit target while navigating; the web build drew
neither. Both lived in the Qt-coupled OverlayRenderer, which only
ViewportWindow drives — the web host no-ops the overlay hooks — so the
wasm build had no path to them at all.
Lift them into AxisIndicatorRenderer, a Qt-free renderer in
IfcViewerCore, and drive it from ViewportCore::render for desktop and
web alike. Same move SectionGizmoRenderer already made; the drawing code
is unchanged apart from swapping qDegreesToRadians for CameraMath's kPiF.
Pivot visibility moves to the core with it: it was a QTimer on
ViewportWindow, so the afterglow couldn't follow the gizmo across. It is
now a Stopwatch deadline next to the drawing, with render() requesting
frames until an armed afterglow expires. Hosts keep the same three
triggers (on for orbit/pan drags, off on release, 600 ms on wheel).
The web demo shell's log overlay sat exactly on top of the corner gizmo,
so it shifts right of the 110 px box.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- assert isinstance(res, list) was wrong because duplicate_task returns a tuple not a list
- removed overkill assertion anyway as the usecase is already typed.
- setting optional name or reuse planned schedule name
- usecase now returns created baseline work schedule
E.g. IfcAdvancedHouse:
```
/usr/bin/x86_64-linux-gnu-ld.bfd: CMakeFiles/IfcAdvancedHouse.dir/IfcAdvancedHouse.cpp.o: in function `main':
IfcAdvancedHouse.cpp:(.text.startup.main+0x137): undefined reference to `hierarchy_helper<Ifc4x3_add2>::addBuilding(Ifc4x3_add2::IfcSite, Ifc4x3_add2::IfcOwnerHistory)'
/usr/bin/x86_64-linux-gnu-ld.bfd: IfcAdvancedHouse.cpp:(.text.startup.main+0x7c7): undefined reference to `hierarchy_helper<Ifc4x3_add2>::getRepresentationContext(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/bin/x86_64-linux-gnu-ld.bfd: IfcAdvancedHouse.cpp:(.text.startup.main+0x931): undefined reference to `hierarchy_helper<Ifc4x3_add2>::getRepresentationContext(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
```
Noticed by addressing gcc warning gcc warning that attribute order is incorrect:
```
//src/ifcparse/hierarchy_helper.i:721:31: warning: attribute ignored in explicit instantiation ‘class hierarchy_helper<Ifc2x3>’ [-Wattributes]
721 | template IFC_SCHEMA_API class hierarchy_helper<IfcSchema>;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
//src/ifcparse/hierarchy_helper.i:721:31: note: no attribute can be applied to an explicit instantiation
```
Resolves the error below. This option was removed in clang 18.
```
.clang-tidy:4:1: error: unknown key 'AnalyzeTemporaryDtors'
AnalyzeTemporaryDtors: false
```
Because vert[0] can change based on kernel output, we now assert that 1)
origins are on a vert, any vert, and 2) both blender coords and map
coords are what we expect. I manually visually verified all tests
against Blender 5.1 + stable 0.8.5 to check that actual behaviour hasn't
changed, only tests need updating.
Assigning a material to an occurrence with a set material type has raised
"IfcMaterial cannot be assiged as a IfcMaterialLayerSetUsage" since the
default changed to assigning usages to occurrences. The type is upgraded to a
usage but the material is passed on unchanged, and material.assign_material
only accepts a material for a usage when that material is already the set,
whereas the Object Materials dropdown gives us a plain IfcMaterial. Pass
nothing in that case and let the API make the set, as it does when asked for
a usage with no material.
Look the set up past the usage afterwards, so the material the user picked is
added to it. get_material returns the usage, which is not a material set, so
neither branch of the repair below matched and the picked material was
dropped, leaving the set empty.
This is a stopgap and is commented as such: the real problem is that
assign_material builds sets with no items in them and ignores the material it
was given, which is not valid IFC and leaves callers patching up after it.
Also register "I evaluate expression" as a Then step. It has only ever been a
Given and a When, so the last line of the scenario covering this could never
run; it is the only Then of its kind in the suite.
test/bim goes from 16 failures to 15, with none introduced.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
create_boilerplate_ifc sets self.file and self.work_plan and returns
nothing, but create_ifc assigned its result back over self.file, so any
caller that did not supply a file got None and crashed on the next
create_entity. Call it for its side effects, as csv2ifc and csv4d2ifc
already do.
That alone only moved the failure along: the boilerplate builds a file and a
work plan but no IfcProject, and add_work_calendar looks for an IfcContext.
Create one, matching csv4d2ifc's copy of the same method, which has both
lines.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
msp2ifc parsed the XML and built the IFC itself, so a programme read
differently depending on whether it came out of MS Project or P6. It now
parses only, and hands the parsed programme to ScheduleIfcGenerator the way
p62ifc does. Calendars, statuses, task times and resources are therefore the
shared ones, and a reader no longer has to know which tool planned the
schedule.
Three things MS Project does differently needed handling rather than sharing.
It has no work breakdown structure: there is one flat task list and an
OutlineLevel column, and a task with anything indented under it is a summary
whose dates are rolled up rather than planned. Those become IfcTasks without
an IfcTaskTime, as a P6 WBS node does. Summaries and leaves also interleave,
and a planner expects a summary to stay where they put it, so the tree is
walked in export order instead of through create_tasks, which sorts nodes
ahead of activities. And a link may hang off a summary, which P6 cannot do,
so create_rel_sequences resolves both ends against summaries too --
IfcRelSequence relates two IfcProcesses and does not require a time on
either.
Calendar handling flattens what MS Project stores as differences against a
base calendar, since IfcWorkCalendar has no such notion, and reads holidays
from whichever of the two spellings the export uses rather than both.
Recurring exceptions are skipped, because the recurrence is not readable from
the export and guessing wrong silently moves every date computed from the
calendar.
In common.py the UDF and activity-code property set names become class
attributes. They keep their P6 names by default, but MS Project's extended
attributes are not P6 user-defined fields and now land in
MSP_ExtendedAttribute rather than under a name that says P6. IsMilestone
likewise prefers a source that states it outright -- MS Project has a
Milestone flag -- and falls back to the zero-duration test, which is all P6
gives us, so the other importers are unaffected.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Models now resolve to global coordinates, which alone would make things worse:
composed per-instance transforms are float32, and around six million metres
that quantises at roughly half a metre. So the first model to load also sets a
false origin, derived from where its geometry actually sits, unless a host has
set one itself.
WebFederation owns the concepts an .ifcfed carries — a federation unit, a false
origin, a per-model transform and display name — without the file format. The
desktop Federation class is a document model whose sources are local filesystem
paths, which mean nothing in a browser; a host page that wants .ifcfed can parse
the JSON and drive these calls.
Models are keyed by the JS source id rather than the session model id. The
source id exists the moment a File or URL is registered, whereas the session id
is minted inside the async range-read chain, so keying on it lets a transform be
set before the model has streamed and applied when it arrives — the model never
visibly jumps. loadSidecarMetadataWeb gained a completion callback to carry that
id back out, and addFile/addUrl now return the source id and fire onModelLoaded,
where before they were fire-and-forget with no handle and no completion signal.
The embedded sample bypasses the source registry, so it is bound separately;
otherwise the guess never runs for a page that only ever shows the sample.
georef-a and georef-b are the regression fixture: two boxes whose different map
conversions resolve to the same real-world point, so a viewer that applies them
draws one box's worth of scene and one that ignores them spans 707 m. They carry
two meshes each because reorderSidecarByMorton bails out below two and then
writes no chunk table, and a sidecar without one cannot stream over byte ranges.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
.ifcview has carried the model's CoordinateOperation since v11 and the
streaming reader has always parsed it, but applyCachedModel ignored it. The
matrix only ever reached the scene because BonsaiViewer pushes it after every
load via setModelCoordinateOperation. Nothing does that on web, so every model
rendered in its local coordinates and two federated models with differing map
conversions came out misaligned.
Seed the matrix and the unit scales from the sidecar, and recompose the model
afterwards. Seeding alone is not enough: the instance transforms in a sidecar
are baked with identity federation matrices, and applyCachedModel uploads them
as-is. The recompose also fixes a second case that had nothing to do with
georeferencing — a model loaded while a federated false origin was already in
force kept its unshifted transforms.
ModelGpuData gains the unit scales because composeModelTransformation needs
them to lift a transform's anchor point into metres, and on a sidecar-only load
there is no IFC to read them back from.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Andrej730