fix(FragmentsModels): don't cull against an uninitialised frustum before useCamera()

[arbirk]

Fixes #255.

The bug

ViewManager._updateCameraFrustumEvent stays a no-op until useCamera() runs, so
setup() ships a default THREE.Frustum. three.js builds that as six planes at
normal (1,0,0), constant 0 — i.e. six copies of the plane x = 0 — and
PlanesUtils.collides then rejects any item whose bounding box lies entirely at
x < 0.

Nothing reports it. The geometry stays in the index buffer, getLocalIds,
getItemsData, getMergedBox and getItemsGeometry all still list it, and the mesh
reports visible === true with a full drawRange. Culling is expressed by omitting
the index range from geometry.groups, which no data-side API observes. A model
centred on the origin silently loses half its geometry; ours lost a 1.87 m sliver off
one end and read as a compiler defect for days.

The fix

Per @agviegas preference in the issue — absence is the signal, no
cameraApplied boolean beside cameraFrustum to keep in sync across the worker
boundary:

1. refreshView sends no frustum at all until currentCamera !== null
   (view-manager.ts)
2. setupViewPlanes skips the copy when it's absent, leaving _virtualPlanes empty
   (virtual-tiles-controller.ts) — and an empty plane list means cull nothing,
   since PlanesUtils.collides returns true on an empty array
3. A one-time console.warn naming the model, because the whole failure mode is
   that nothing tells you

Two sites beyond the two discussed — both required

The two-site fix proposed in the issue isn't sufficient on its own. A null frustum has
to survive the full path, and it hits two more dereferences first:

ThreadViewRefresher.safeCopyFrustum — the worker-boundary rehydration calls
MultithreadingHelper.frustum(frustum), which does frustum.planes unguarded. Without
a guard here the null throws at the boundary, before any of the culling code runs.

VirtualTilesController.updateOrientationIfNeeded / getCurrentViewOrientation —
and note the ordering in setupView:

setupView(view: any) {
  ...
  this.updateOrientationIfNeeded();   // :215  dereferences the frustum FIRST
  this.updatePositionIfNeeded();
  this.setupViewPlanes();             // :217  the guard from step 2
}

[agviegas]

Thanks, this is a thorough piece of work. Verified it here: build is clean, your tests pass, and I checked the with-camera path separately since that was the regression risk. Indices drawn are identical to main both with the camera on the model and facing away, so culling still functions. Also confirmed visually in a viewer, main loses the negative-X half of small_test.frag and this branch renders it whole.

Good catch on the two extra dereference sites. Passing null on main throws at MultithreadingHelper.frustum before any culling code runs, so those guards are definitely required.

One thing before merging. The worker ships as a separate artifact and plenty of people pin or self-host its URL, so a main thread updated ahead of its worker is a real scenario. With this shape it doesn't degrade, it throws Cannot read properties of null (reading 'planes') on every frame. I hit it by accident pointing a local build at the published worker. Your original sketch guarded that with cameraApplied !== false, and asking for absence as the signal is what dropped it.

Could you make the worker side tolerate a missing frustum, so an old worker paired with a new main thread degrades to current behaviour rather than crashing?

[arbirk]

@agviegas I had to rely on my agents to help me with this one, as I am only a consumer of thatopen's libraries. This summarizes the fix against your comment:

You asked us to make the worker tolerate a missing frustum; we instead stopped the main thread sending one, because guarding the worker only helps new workers — the already-published worker in the pairing you hit can't be changed, so it would still crash. The main thread now sends a real frustum sized to the model's own bounds, which any worker old or new culls against normally and keeps everything, and we added the worker-side guards you asked for anyway as defence in depth.