If the Fillsrf command in Rhino 9 has not yet been incorporated into the RhinoCommon C# API, it is important to contact the McNeel development team for assistance. This command is a vital tool for creating surface fillings in Rhino, and its absence in the API may restrict developers from leveraging this functionality in their custom applications or plugins.
@menno - is this something you can help with?
The idea is to expose it in the RhinoCommon API once we have enough experience with that API ourselves. This is all rather new (the command was announced yesterday and is still under active development), and I’m excited to see you have a need that is filled by the command.
I’m also interested to learn about applications that you may have for this in your plug-in - maybe it is something that Rhino itself can provide going forward.
Hello @menno,
I am working on a script for a plugin that creates stairs from plan lines, and I needFillSrf (Patch > a surface for the ramp of these stairs).
(The Patch command fails to create this surface.)
Can you share an example 3dm file that you’d like to use FillSrf for in this application? FYI FillSrf will come to Grasshopper as a component in the near future.
Dear @Menno,
I’d like to express my gratitude for your contributions, especially for adding features such as FillSrf (Patch Continue) in Grasshopper. I also hope that this functionality will soon be available in the C# API for direct use.
Additionally, I’d like to propose a new component in Grasshopper that can seamlessly patch curves into surfaces, much like the use of the Patch command in Rhino. This could be implemented in C# with the following configuration:
pManager[0].Optional = true;
pManager[1].Optional = true;
pManager[2].Optional = true;
For brep, brep edges ,and brepcountinuetils....
By specifying optional Brep inputs, users can work more flexibly, relying only on curves without needing to fill all inputs. This change could make the process more efficient and user-friendly within Grasshopper.
Thank you once again for your hard work and dedication to the community!
Best regards,
1 Like
Thank you for your ideas on how to make the GH component more flexible and user-friendly to work with. I have logged this here.
“Thank you for your response, @Menno. I would like to suggest making the text or number of the edge more visible for better clarity.”
1 Like
You can right-click on the component and select a size of the text (or switch it off). Is that helpful?
Yes, in the screenshot above, the Large Number option is selected but the numbers interfere with the vectors of the display and are not clear. If the distance of the numbers with the vectors of the show will be better.
Ok, I’ll see that that gets tuned up to make it better. For that I made a YT issue.
1 Like
I’m currently looking at this (see below) - the edge number is on a “tether” attached to the mid of the edge. Also, red text on green selected geometry works great, but green text on red unselected geometry not so much, so I’ve changed the text color when the geometry is not selected to black.
Lastly, the arrows do not show on the edges as their direction is not important in this component.
This is going into the next WIP, which will be available next week.
1 Like