A very strange grasshopper related bug (it's witchcraft! - burn the witch!)

I baked an untrimmed surface then I did some stuff in grasshopper.

The visible manifestation of the bug.
The baked untrimmed surface disappeared.
I didn’t see it happen; I have grasshopper on one screen and the rhino window on another.
So I wondered: did I delete it? Is it on a hidden layer?

I tried baking it again and the rhino UI said that it was creating meshes which took a short, non-zero, time but nothing was visible. I tried two more times but nothing was visible.

I turned preview on on the node that contained the untrimmed surface; I could see the curves that I rotate to generate the untrimmed surface highlighted in green.

The containing node was using internalized data. I connected the node that generates the surface to the node but that didn’t fix the problem (that a Surface node appears to contain only the generating curves and not the surface that they generate).

I saved the rhino file and the grasshopper file with -eek appended to their names and restarted rhino.

When I loaded the -eek rhino file I saw the baked surface. When I loaded the -eek grasshopper file: the surface disappeared. Closing the grasshopper file restores the surface.

This behavior is utterly bizarre to me. How can grasshopper reach into the rhino document and alter something that had been baked into the document on the previous run of the program?

The cause of the bug ???
I had a C# script node that took a list of breps. I changed the source of the breps. They were coming from a brep node, I changed the source to the output of another node that produces a list of breps.

That’s roughly what I was doing but it took me a while to notice that something had gone wrong so I can’t say exactly what happened or what I did to cause the bug.

What I will do next.
I save my files to dropbox and it has a history mechanism.
The edits that I was making where mostly just changes to C# script node and I have the text of the changes in a text editor.
So I should be able to recover from this by opening the previous versions of the files and changing script node text to the latest versions.

What do you want to do?
I can probably fix this myself.

I imagine that you are busy with the rhino 7 beta.

The Rhino document is one that I use to generate geometry for importing into another file.

I use it to play about with ideas so I make LOTs of layers with half formed stuff in it. The grasshopper document is in a similar state, it is a spagetified morass of nodes. I also use custom C# nodes built in developer studio so there is a raft of dlls that would need to be included with the documents.

So do you want to look at this or would you rather wait until I see if I can recover from this?

My Rhino version
Version 6 SR29
(6.29.20238.11501, 08/25/2020)

There is one thing that I’m doing that feels pretty fishy.

The Window Spikes node is a C# script node.

OptionalShellSurf has a Surface type hint.
OptionalShellBrep has a Brep type hint.

The code inside does this:

if (OptionalShellBrep == null && OptionalShellSurf != null)
  OptionalShellBrep = OptionalShellSurf.ToBrep();

Then I do this:

  if (OptionalShellBrep != null)
    //optionalTrimmedWindows.Add(Brep.CreateBooleanIntersection(windowSpike, OptionalShellBrep, t, true)[0]);

I commented out the intersection because it was failing and no wonder given that the Brep appears to contain only a curve and not a surface.

I don’t know if this has anything to do with the problem but it is a recent change and I did feel dirty writing the code. :wink:

This is where the untrimmed surface comes from.

I enabled preview on the select node. If I select the node then I see this in the Rhino UI:

If the node is not select then I see nothing (the lines don’t change color to the unselected color, there is NOTHING visible).

If Grasshopper is closed then I see this.

I bet it’s the 6.66 radius, you’re cursed

OMG, you’re so right. You should never tempt Satan.

I’m doomed! :wink:

There may be something in the previewing which is short-circuiting the Rhino display of the surface. the surface is still there but is either never drawn or falls outside the clipping region.

That’s just a guess mind you, I’d need the file to try and reproduce it.

Is the brep valid? You can test using the What or possibly List commands in Rhino.

I managed to slim my files so there is very little going on but the bug is still present.

Rationalised_NewHole_3Grooves_component0014-eek-slim.gh (500.8 KB)

Build_000003-eek-slimmer.3dm (1.8 MB)

1 Like


Just open this grasshopper file in any rhino file with a surface in it and enable the “Window Spikes” node to see your geometry disappear.

it works with Breps as well so it probably effects everything.

Rationalised_NewHole_3Grooves_component0015-eek.gh (476.0 KB)

In the “Window Spikes” node…

If I comment out both of the scaling lines, or if I comment out the line that sets WindowCutrs then there is no problem.

// big.Transform(Transform.Scale(Plane.WorldXY, scaleX, 1, scaleZ));
// sml.Transform(Transform.Scale(Plane.WorldXY, scaleX, 1, scaleZ));


// WindowCutrs = windowCutrs;

what’s the problem with scaling a curve (or two)?

Maybe I can get away with just scaling a copy of the spike. But there is still a bug here or something that I don’t understand.

I see what I did wrong.

When I first wrote the node, the spikes had the world origin inside them.

I then switched the spike inputs to the list created by my IronMaiden node which had made a list of spikes that were all far from the origin. Good luck scaling that with respect to the world origin.