IGH_Goo.CastTo<GeometryBase> bug

Grasshopper Developer
, ,
11

@dale

I don’t have a problem I’m trying to solve anymore. I’m already using pattern matching like you suggested to avoid the CastTo operation as necessary. The problem is that the work around is necessary and is likely the cause unintuitive behavior inside of grasshopper before we even get to talking about custom code.

In Grasshopper if you get a brep via a Surface parameter node, it tells you that it’s a trimmed surface. The fact that passing in through that node will cause some nodes to treat it as a surface and others to treat it as a brep is a problem. As @magicteddy pointed out, the TriRemesh component exhibits the behavior. The same piece of geometry coming as a GH_Surface versus a GH_Brep results in a different result without there being any indication prior that that will happen:

  • Both GH_Surface and GH_Brep will display Trimmed Surface in a panel
  • Both GH_Surface and GH_Brep will display the trimmed surface as their preview geometry in the Rhino Viewport
  • Both GH_Surface and GH_Brep will losslessly convert back and forth between each other, and if you pass the surface through the brep node first it will behave as expected in components like the TriRemesh component.

Here’s the behavior again, with just the TriRemesh component, as you can see, the center object is losing the trimmed information when passed into the TriRemesh node, even though it’s preview geometry before the node clearly shows it as a trimmed surface.

TriRemeshWeirdness
TriRemeshWeirdness1946×820 182 KB

CastToExample.3dm (27.9 KB)
CastToExample.gh (11.6 KB)

Take it or leave it, but I personally feel like this behavior is a bug. At the very least components, like TriRemesh, that quietly ignore trimming information on a brep when it is passed in as a GH_Surface should raise a runtime message to alert users as to what has happened, why it happened, and how to avoid it if they don’t want it to happen. Additionally, GH_Surface doing double duty as a single surface brep and as an untrimmed surface makes mistakes like what happened here more likely: "Baking" Trimmed surfaces using Rhinocommon. Grasshopper users aren’t trained to think of surfaces as surfaces and trimmed surfaces as breps and instead think of them as the same geometry type which makes it all the more jarring when all of a sudden either the API, or a node decides that a surface is a surface and not a trimmed surface.

Best,
Cullen