a new node

[canwegoback]

Thank you for your work on the editor's source code. During the holidays, I read through the editor's source code and have a question. Now, I want to add a feature similar to SketchUp's block pull/push functionality to the code. However, most of the nodes in the current code are stretched and expanded on the xz plane. If stretching is to be done on the y-axis, it requires the use of a panel to set up (I'm not sure if my understanding is correct). In this case, the experience for the block pull/push feature will not be very good. Could you please give me some suggestions regarding this aspect (any suggestions would be greatly appreciated)? Thank you
Here are some examples

Create shape

QQ20260202-162612.mp4

push and pull

QQ20260202-162658.mp4

dig a hole

QQ20260202-162738.mp4

Translate/Scale/Rotate (low priority)

QQ20260202-162820.mp4

In the end, we can get such a building

[Aymericr]

@canwegoback thank you for this input, this should be on top of a our todos @wass08

[Aymericr]

Reviving this with an actual technical answer — it's been sitting on "on top of our todos" since February, which isn't useful to someone offering to build it. Thanks for reading the source that carefully; your framing of the problem is right, but the conclusion isn't, and the difference matters for how you'd implement it.

Your premise — "y-axis stretching requires a panel" — isn't true today. The registry has a declarative handle system in packages/core/src/registry/handles.ts, and LinearResizeHandle takes an explicit axis that accepts 'y'. Y-axis drag resize is already shipped on several node types — packages/nodes/src/slab/definition.ts:148, stair-segment/definition.ts:75, and four separate handles on dormer/definition.ts. So the primitive you'd want for push/pull exists and is in production use; it's the coverage that's uneven, not the capability.

Here's the slab's height handle, which is close to a minimal push/pull in structure:

// packages/nodes/src/slab/definition.ts:145
function slabRecessedDepthHandle(): HandleDescriptor<SlabNodeType> {
  return {
    kind: 'linear-resize',
    axis: 'y',
    anchor: 'min',                    // base stays fixed; drag the top
    min: MIN_SLAB_ELEVATION,
    max: (n, sceneApi) => slabElevationUpperBound(sceneApi.nodes(), n),
    currentValue: (n) => n.elevation ?? 0.05,
    magneticSnap: (n, newValue, sceneApi) => resolveStructuralElevationSnap(...),
    apply: (n, newValue) => applySlabTopChange(n, newValue),
    previewOverrides: (n, newValue, sceneApi) => slabChangePreviewOverrides(...),
    placement: { position: (n) => [cx, elevation + HEIGHT_HANDLE_OFFSET, cz] },
  }
}

Note what you get for free by declaring rather than implementing: anchor decides which face stays put, min/max clamp it, magneticSnap snaps to other structural elevations, previewOverrides drives the live preview during the drag, and commit fans the final write out to sibling nodes. The generic renderer in packages/editor/src/lib/direct-manipulation.ts handles the gesture. You don't write drag math.

Where your instinct is right: the three things in your videos are not one feature, and they get progressively less compatible with how Pascal is built.

1. Push/pull an existing face — the closest fit. For any node whose height is a scalar field, this is a linear-resize handle with axis: 'y', and it's mostly a matter of adding it where it's missing. Tractable, and a good first contribution.

2. Create shape → extrude — this needs a new node type, not a new tool. Pascal is a parametric BIM model, not a mesh modeller: nodes are typed (wall, slab, column, zone…) with semantic fields, and geometry is generated from those fields. An arbitrary drawn polygon extruded to a height is a genuinely new kind — something like a generic mass/solid node with a footprint polygon and a height. That's designable, but it's a schema addition and needs agreement before code. Worth noting zone already carries an arbitrary polygon footprint, so the footprint half has prior art.

3. Dig a hole / boolean subtraction — this is the one that fights the architecture. There's no CSG layer; holes today are semantic (a door is hosted by a wall and the wall's geometry builder subtracts the opening), not a generic mesh boolean. Adding real CSG would be a major architectural change, and I'd push back on it as a first project. If what you actually want is "an opening in a slab", note that slab already supports openings — stair and elevator holes are clipped out of generated slabs. So the specific useful cases may be reachable without general booleans.

Suggested path if you want to build this: start with (1) on a single node type where the handle is missing, as a small PR that proves out the ergonomics — including whether the drag needs a modifier to disambiguate from move, which is the real UX question here since Ctrl/Meta-drag is already direct-move. Then open a separate issue for the mass node in (2) with a proposed schema, and let's settle the field shape there before you write geometry. Leave (3) alone until (2) exists.

Read editor/wiki/architecture/ first — the node-registry and handle pages will save you rediscovering the above. Happy to review a draft PR early rather than after it's finished; on something this architectural, an early sketch is much cheaper to redirect.