C# Editor Flips Input Surfaces

Grasshopper Developer
1

Hello everyone,

I am developing some components in C#, and using the script editor for testing. I have encountered something that is giving me some problems, and I’m not sure if this is a bug in the C# editor (or Rhino Common for 6), or if there is some lack of understanding on my part and I should try something else.

When I input these surfaces into the C# editor, and use the “Surface” type hint, my surfaces become flipped. This is true when I try to perform operations on them, so I cannot obtain the proper Frames, and direction vectors that I want. So, any method I use, such as iSrf.FrameAt() is going to be wrong, since the normal is being flipped.When no type hint is provided, the surface is correct, however, not useful because I can’t call Surface methods.

Any reason for why this is happening? I am using the latest versions of Rhino 6 and Grasshopper 1.0

image
image1462×683 131 KB

c#_NeedlessSurfaceFlipping.gh (19.1 KB)

2

This is a result of the fact that what Grasshopper calls a “Surface” is in fact a Brep with a single face. The “Surface” data type does not support trims. The issue you’re seeing is that a BrepFace can have a different normal from the surface underlying it. What you generally see as the “surface normal” in GH is in fact the BrepFace normal. I believe you’ll have better luck treating your surfaces as Breps in the typehint - and then getting .Faces[0] (as long as you’re sure it only has a single face)

1 Like
3

Thanks for your response Andrew! Good to know regarding Breps, this leads me to a few more questions.

For this I am not concerned with trimming, and would prefer to use the Surface data type as an input. I am still not sure why, for instance: if my surface input is faced one direction, that when I output that same surface with no modification through the c# editor, the surface becomes flipped.

EDIT: Never mind, I think you answered this. Just for my clarity: Why would the Surface data type be handled with an underlying brep that has a different normal direction than the Surface? Is there an advantage to this?

I have found that it is not just with the c# editor either, it is true for other components that use the Surface data type as input, and output a surface. The Isotrim component also outputs the subdivisions as flipped. I am working on some dynamic subdivision components in VS and this is true for them as well.

Though, since I want to work with surface direction - and flipping - there has to be a Brep conversion in there.

So, I’m sure you have a solution for this, I noticed that in your Wombat SrfDirection component that you input a Surface data type parameter and output a brep. I tried to replicate this to learn from, however my surfaces are still flipped on the output. Otherwise, it functions the same. What I am finding is that if I input as a Surface type hint, and do something like:

private void RunScript(Surface iSrf, ref object A)
{
Brep brepSrf = iSrf.ToBrep();
Brep newSrf = brepSrf.Faces.ExtractFace(0);
newSrf.Faces.Flip(true);
A = newSrf;
}

the output Brep is still flipped because the input surface is flipped upon input. How else would this be handled? Setting flip to false, because surface input flipping is known to occur? I learned to set Flip to true when dealing with exploding breps and doing things with them, because ExtractFace() does strange things to the Normal directions. If the input data type hint is a brep, I don’t have an issue with the normal flipping. But I would rather it be a surface.

On the other hand, if I use Brep.Faces[0], the face is a tiny version of the original surface. Is there another method to call here that deals with this?

private void RunScript(Surface iSrf, ref object A)
{
Brep brepSrf = iSrf.ToBrep();
BrepFace newSrf = brepSrf.Faces[0];
A = newSrf;
}

Gives this result:

image
image.png1134×353 2.35 KB
c#_NeedlessSurfaceFlipping_V2.gh (23.9 KB)

1 Like
4

by the time you’ve passed the grasshopper surface (GH_Surface type) into a c# input with type Surface (from Rhinocommon) it’s already too late. You have to keep it as a Brep. In a compiled GHA, you can have the param type be “Surface” because the GH_Surface type wraps a Brep.

the “Tiny surface” you’re seeing is because a BrepFace type converts automatically to a plane when you pass it into grasshopper, and a plane auto-converts to a “tiny surface” when you pass it into a srf param. I think your approach with ExtractFace seems valid as a way to get the face as a single-face Brep.

It’s also useful to know that a BrepFace has a property “OrientationIsReversed” which indicates whether its normal is the inverse of that belonging to the underlying surface.

2 Likes
5

Haha, wow, silly mistake on my part, I didn’t notice that the BrepFace was output as a plane… Whoops.

And good to know, OrientationIsReversed is very useful for me here. I figured that compiling in VS might be a way to deal with this issue in order to have a Surface input parameter that then gets handled as a Brep. I will work with the brep type hint then when testing in the c# editor.

Thanks again, Andrew.

6

:+1: For reference, in Wombat, we do pManager.AddSurfaceParameter() in RegisterInputParams() but then get a Brep directly out in SolveInstance() with DA.GetData<Brep>()

4 Likes