ClipStyler is not aligned with Clipper

[HeyVico]

I am unable to find out why this happens but here is what i observe:

Here is your example on https://docs.thatopen.com/Tutorials/Components/Front/ClipStyler
It shows a Z-offset to the clip placed.

https://viewer.crais.io/ figured out a way do the reverse and align the clipstyler with the clip as seen here:

However here is the bug:
If the clip is angled, the black geometry it generates to simulate the fill does not align with the cut because the geometry is rendered from further inside the 3D model:

[agviegas]

Hey, thanks for the report. The misalignment is real and we have a clear plan. Quick walkthrough.

Why the fill misaligns at angled clips

The ClipStyler builds the section profile and shifts it 1cm along the clip plane's normal. That offset is there because if the fill sat exactly on the clip plane, three.js's global clipping discard would throw it away (any fragment dotted with the clip plane equals the plane constant and gets culled). The 1cm offset dodges that.

When the camera looks straight down the plane normal, that 1cm is purely a depth shift you can't see. When the camera looks along an oblique angle to the plane, the 1cm is a sideways shift on screen, so the fill no longer covers the cut. That's the angle-dependent artifact you saw, and why viewer.crais.io looks correct: they almost certainly aren't using global clipping.

The fix we're going with

Instead of moving the geometry, we're switching the Clipper to use three.js's per-material local clipping (material.clippingPlanes). Each fill / line material gets the list of clip planes minus the one its section represents, so the cut's own plane no longer discards it, and the section geometry sits exactly on the cut. Other clip planes (a section box's other walls, multiple clippers) still bound the fill correctly because they're still in its local list.

Net result: the fill stays exactly aligned with the cut at every camera angle, and there's no shader hack involved.

Backwards compatibility

This is going in behind a flag, default off. Today's behavior is preserved exactly:

const clipper = components.get(OBC.Clipper);

clipper.localClippingPlanes;        // false by default — same as today
clipper.localClippingPlanes = true; // opt in to the new path

Existing apps that depend on renderer.clippingPlanes being populated globally keep working unchanged. When the flag is flipped to true, the Clipper stops mirroring planes to the renderer global and instead assigns them per-material. The ClipStyler detects the flag and skips its world-space offset entirely.

Once the new path is well-validated across the docs and apps, we'll consider flipping the default in a future major and removing the legacy offset, but that's a separate decision and not part of this change.

Why we're not pursuing the shader-level offset workaround

We did prototype a vClipPosition offset injected via onBeforeCompile into the fill / line materials. It works for the visual artifact, but it has a downside that bites you later: the world position the GPU rasterizes is on the cut, but the world position the clipping shader sees is offset. That decoupling between visible position and clipping position is fine for one specific section, and starts being incorrect the moment you try to combine the fill with anything that asks "where is this fragment in the world?". Raycasting against fills, color picking, and depth-sample-based effects (postproduction passes that read scene depth) would all return positions that disagree with what the user sees on screen.

Per-material local clipping doesn't have any of that: the geometry's world position is its real world position, three.js just doesn't include the cut's own plane in the discard list for that one material. No shader manipulation, no offset, no decoupling.

Timing

Working on the Clipper change now.

[agviegas]

Fixed. New opt-in flag on the Clipper:

const clipper = components.get(OBC.Clipper);
clipper.localClippingPlanes = true; // set before creating any plane

When on:

• Clipper planes are flagged isLocal, so they stay out of renderer.three.clippingPlanes.
• Clipper auto-assigns the right material.clippingPlanes to every fragment material (shells and LOD lines).
• ClipStyler drops its 1 cm offset and gives each section's materials a clippingPlanes list excluding that section's own plane. The fill sits exactly on the cut at any angle, and other planes still bound it.

Default is false, so existing apps behave exactly as today. Available on the latest engine_components; the ClipStyler example has the flag on so you can see the difference.

Available in the upcoming patch. Let us know if you have any issues!