Weird geometry problem - causing a hard time

[erik6 (erik)]

Hello,

I have this really weird thing going on with “mullion” geometry causing BadObjects after a couple of “MoveEdge” operations.

I have this closed curve shape, very clean and neat, with only a few control points:

I extrude this to a prolonged shape.

Let’s say 200 mm.

I make two rotated copies.

I then subtract the two verticals from the horizontal.

I delete everything but the middle part.

The middle part looks perfectly fine.

I now perform a MoveEdge (or MoveFace) like this, extending one side by 50 mm.

And I get this:

This is still a valid object, but it looks weird.

I then move it back 50 mm again.

Now it looks like this.

Still a valid object but now looking really weird.

Doing boolean opeations on this normally turns it into Bad Object.

Can someone explain what is going on? And if there is a workaround not producing these weird things?

The objects are used for windows and it is often necessary to adjust the width of a window frame, thus using MoveFace or MoveEdge to do that. Then centering those mullions to the new width. Unfortunately after a while the geometry becomes unusable.

Using History does not really work well here because of the intersections etc … Quickly becomes too complex.

A full example

Another question arises here as well:

When creating geometry using Sweep1, using Sweep shapes that are curved, MergeAllFaces does not remove the seam of original shape.

Is there a way of getting rid of it somehow?

Like here:

MergeAllFaces fixes all the planar faces, but leaves does arc-shapes.

Thanks
/Erik

Here is a version with the original 2D-curve profile.
mullion problem 01 260430.3dm (5.6 MB)

[erik6 (erik)]

mullion problem 260430.3dm (5.6 MB)

Here’s the file.

And SystemInfo:

Rhino 8 SR29 2026-3-4 (Rhino 8, 8.29.26063.11001, Git hash:master @ bbd126f84fcdaf7a974615b7c9f4f8667571c147)
License type: Commercial, build 2026-03-04
License details: Cloud Zoo

Windows 11 (10.0.26200 SR0.0) or greater (Physical RAM: 96GB)
.NET 8.0.14

Computer platform: DESKTOP

Standard graphics configuration.
Primary display and OpenGL: NVIDIA GeForce RTX 4090 (NVidia) Memory: 24GB, Driver date: 3-4-2026 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 595.79
> Accelerated graphics device with 4 adapter port(s)
- Secondary monitor attached to adapter port #0
- Windows Main Display attached to adapter port #1

Secondary graphics devices.
Intel(R) UHD Graphics 770 (Intel) Memory: 2GB, Driver date: 12-1-2025 (M-D-Y).
> Integrated graphics device with 4 adapter port(s)
- There are no monitors attached to this device!

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
GPU Tessellation is: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)

Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 3-4-2026
Driver Version: 32.0.15.9579
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 24564 MB

Rhino plugins that do not ship with Rhino

Rhino plugins that ship with Rhino
C:\Program Files\Rhino 8\Plug-ins\Commands.rhp “Commands” 8.29.26063.11001
C:\Program Files\Rhino 8\Plug-ins\WebBrowser.rhp “WebBrowser”
C:\Program Files\Rhino 8\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 8\Plug-ins\RhinoScript.rhp “RhinoScript”
C:\Program Files\Rhino 8\Plug-ins\RhinoBonusTools.rhp “Rhino Bonus Tools”
C:\Program Files\Rhino 8\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 8.29.26063.11001
C:\Program Files\Rhino 8\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 8.29.26063.11001
C:\Program Files\Rhino 8\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 8\Plug-ins\MeshCommands.rhp “MeshCommands” 8.29.26063.11001
C:\Program Files\Rhino 8\Plug-ins\RhinoCycles.rhp “RhinoCycles” 8.29.26063.11001
C:\Program Files\Rhino 8\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 8.29.26063.11001
C:\Program Files\Rhino 8\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 8\Plug-ins\Displacement.rhp “Displacement”
C:\Program Files\Rhino 8\Plug-ins\Calc.rhp “Calc”
C:\Program Files\Rhino 8\Plug-ins\SectionTools.rhp “SectionTools”

[Helvetosaur]

The simple answer is that MoveEdge and other similar “Solid” operations do not work reliably when they involve edges of non-planar surfaces.

[Normand (Jakob Normand)]

Hi @erik6
This has - to say it midly - been around for a while: Bug: direct editing fail. Post is from january 2015. Cylindrical faces in Rhino are totally hopeless when it comes to direct editing. No improvements in the WIP, unfortunately.
-Jakob

[erik6 (erik)]

Well,

could McNeel suggest a workaround ?

/Erik

[Lagom]

Maybe skip using Rhino’s bug-afflicted “solid modelling tools”, and try to do what you want to do with Rhino’s rather solid NURBS surface modelling tools instead? It’s easily done in Alias or Catia, and very likely in Rhino, too. Maybe upload the initial section in your OP?

[wim (Wim Dekeyser)]

Hej Erik -

@erik6

could McNeel suggest a workaround ?

A workflow using history and Boolean operations could possibly be used:

How to model a Camera in Rhino

[BooleanModeling] Background Recently, @sfp posted a question asking how to create a camera in Rhino and shared a demostration video of modeling in NX. This is a classic example of solid modeling. In fact, Rhino offers many solid modeling tools. But how can you dynamically adjust the shape during the design process? For the camera model mentioned above, prior to Rhino 8, this could only be achieved using Grasshopper, as discussed in a previous forum thread here…. [image] [image] [image] Th…

-wim

[Normand (Jakob Normand)]

Hi @erik6
I usually just extract, join and move the end caps and scale the center part into oversize and trim/join or CreateSolid - see vid for reference.

HTH, Jakob

[erik6 (erik)]

Completely doable, but quite cumbersome.

I wonder if this is a mathematically unsolvable problem? Or if it something else that stops McNeel from solving it so that we can work with a more natural workflow?

McNeel! Any answer to this ?

Thanks
/Erik

[erik6 (erik)]

I did upload a file with the original profile now.

[erik6 (erik)]

Wim,

yes it might be so, that it is possible to do it dynamically.

But the simplest solution is to get the Boolean Operations fully functional.

And the question remains: Is this a mathematically unsolvable problem or is it just something that is hard to fix? (because the geometry is described in a certain way in Rhino, which does not allow these operations to be exact …?)

Or just no one who wants to spend the necessary time fixing this ? (since 2015 …)

Still happy after all these years.
/Erik

[erik6 (erik)]

I will have to use the grouped separate surfaces solution for now. When the design has been finished, will join them to solids.

/Erik

[Piotr]

I’m not sure what are you complaining about but extending by Move Edge or Move CPs works fine.

It hesitates a bit, but perform clean solid.

[wim (Wim Dekeyser)]

Hej Erik -

@erik6

Or just no one who wants to spend the necessary time fixing this ? (since 2015 …)

This isn’t really about “fixing”. The foundations simply weren’t built to support this workflow. Over time, the code has been modified bit by bit to make certain things work. I imagine that a larger change needs to be made to allow solid editing.

As you can see in the link that I posted to, Jessesn’s reply was to Sam’s Help us improve direct modeling post. You might have missed that post, but it should clearly state the intent to make this better.

Sam has been working hard for months to make the surface-plane intesector code work better in more cases. We have been testing that completely new code and providing feedback internally for a while now and it’s getting in a shape where this will be used “in the wild” as well.

A necessary second step would be looking into surface-surface intersections.

All of this is a lot of work and not something that will automagically happen.
-wim

[erik6 (erik)]

Hello Jakob,

I exploded the geometry into surfaces. Two end caps plus the long part in the middle.

I then used Ctrl-Alt-Shift to pick the end cap surface (several joined surfaces) and the “edge” of the long part. And moved it used the gumball back and forth.

After the third move it looked like this:

There were no boolean operations involved. It warped itself into chaos.

So is this really a boolean problem ? Seems not.

/Erik

[erik6 (erik)]

Do it repeatedly for a while and it will give up. First operation normally works.

/Erik

[Helvetosaur]

@erik6

So is this really a boolean problem ?

No. It happens when pulling on surface edges somehow forces Rhino to recalculate the surface and more often than not because the surface gets warped in doing so. If you have isocurves on, you will generally see them getting multiplied and perhaps distorted.

[Piotr]

yeah, I can see it now

[erik6 (erik)]

But in that case, there is no real workaround using surfaces instead of solids.

Only solution then is to do extra long surfaces for the middle part (like Normad suggested), possibly in several parts and then trim those … It’s not really a very viable way of doing this.

[Lagom]

I thought Split and Refit would do the trick, obtaining natural edges that could be simply elongated, but it is tedious, working only on a per-surface basis : (