Hi all. Sometime I check whether or not SubD rhinocommon method have been worked on or not. … seems not? I mainly use c# scripts inside gh (which hugely scare me how it’s clunky and slow, currently), but I plan to convert lots of my definitions to plain c# scripts to use as commands in Rhino. SubD.Vertices is still not a list to simply interact with, with index and such. Still that .First() and .Next() … (Even gh component “Point Deform” still can’t handle SubDs … :confused:) SubD vertices tags. Edge crease status, etc etc Topology? Custom face packing when doing ToNurbs()? Everything is far from accessible. How can we develop new methods for SubDs? There are any example that go deep?

@maje90 We are working on this currently and it will soon be better than it is now. This is work happening in Rhino 8. I went through the mesh example you posted above and realized there are a couple of pieces missing to make that work on a SubD (make all our iterators compatible with for each, add and delete components API); I’m adding them to the SDK ASAP. Apart from these missing things, I think you will find that the SubD code is very similar to the Mesh code. I’ll share examples when they work in the public SDK. I’m also looking at ways to create good examples of how to work with the SubD SDK, I realize that what feels commonplace to the SubD C++ devs might not be evident at all for someone coming from meshes in the .NET SDK. With that said, there is still a few places where I do not really understand what’s missing for you or why you think the current design doesn’t work. [image] Riccardo Majewski: With meshes I can use smoothing/pulling/projecting and “walking the topology” multithreaded , resulting in commands that compute real-time! In SubD you can do Parallel.ForEach(face in subd.Faces) {...}. Is that not walking the topology in a multi-threaded fashion? (And a lot more pleasant to write than the equivalent code on the indices of an array?) [image] Riccardo Majewski: With SubD , with .First and .Next and no topology … can we even compare the methods? For the part about using an iterator on the collection rather than indices in an array, please see @Nathan_Bossett’s answer. I do not understand what use case makes this impossible for you. What I am really curious about is this topology: what information are you trying to access here? The entire topology of a SubD is defined by its edges and faces (and vertex tags), and that information is already available in the SDK. Are you looking for an equivalent to Mesh.TopologyEdges? These things have no reason at all to exist in SubD, the only reason why they exist in meshes is that mesh edges are computed “in addition” to the mesh data coming from .OBJ files, where only vertices and faces are defined. (This is an awful design for mesh editors, as it makes it impossible to have stable indices for vertices and edges.) There are no TopologyEdges and TopologyVertices in SubD, just regular Faces, Edges, and Vertices, and that is all the topology of a SubD. [image] Riccardo Majewski: No ClosestPoint, no EvaluateAt (or something similar with facei+UVparameters), intersections, etc… None of these are available in Rhino either, or in the C++ SDK, unless you are looking for the versions based on the proxy Brep of the SubD. I’ll have a look again at using the proxy Brep from a SubD in the C# SDK but I think that’s working now. We’ve got plans of writing more core C++ methods to work with the SubD limit surface directly (evaluation, closest point, intersection with a curve at first and other things much later), but that will take time. Some of it will likely end up in Rhino 8, and the rest will be Rhino 9. These are things that AFAIK are not available in other SubD software so they did not feel urgent to us. As usual, examples of why these things are useful (and not easily replaced by the same operation on the proxy Brep) will help us 1. put the appropriate amount of urgency on writing these new methods, and 2. design them in a way that works best for users, right from the start. PS: [image] Nathan Bossett: such as direct control of points on the surface Doing that in the .NET SDK is and has been working for control points since 7.0, for edit points you could do whole SubD only in 7.0 and I just added the missing pieces this week to 8.0. I do not know why it is not working with the Grasshopper component but will try to sort that out soon.

[image] Pierre Cuvilliers: [image] Nathan_Bossett: such as direct control of points on the surface Doing that in the .NET SDK is and has been working for control points since 7.0, for edit points you could do whole SubD only in 7.0 and I just added the missing pieces this week to 8.0. I do not know why it is not working with the Grasshopper component but will try to sort that out soon. Fantastic! I look forward to giving it a try. Most of my process is, conceptually, fitting to points on curves and surfaces rather than using control points to move curves and surfaces.

[image] Pierre Cuvilliers: … unless you are looking for the versions based on the proxy Brep of the SubD. I’ll have a look again at using the proxy Brep from a SubD in the C# SDK but I think that’s working now. No, it’s not needed, thanks. The Brep proxy indeed can work but it’s slow… I’ve tried using “proxy” meshes, and refining them near the intersection event, but it’s not that much better. [image] Pierre Cuvilliers: examples of why these things are useful (and not easily replaced by the same operation on the proxy Brep) Speed. When I have SubD with 1500 faces it gets quite slow to compute the Brep each time. Also, ToBrep have the G1x or G1xx options, but they still create some “noise” near extraordinary vertex. I would pay the price of losing speed, if it at least worked on a fully-continue surface (like Tsplines)… [image] Pierre Cuvilliers: In SubD you can do Parallel.ForEach(face in subd.Faces) {...}. Is that not walking the topology in a multi-threaded fashion? (And a lot more pleasant to write than the equivalent code on the indices of an array?) I don’t know what to say, then. I do like rhinocommon Mesh topology methods. All the times I tried to code with SubD I ended up with a messed up geometry, edges or faces disappearing, invalid SubD. I tried many times, always gave up at the end. Even on Rhino: history on, extracting some edge curve, if you continue editing the subd, later you’ll find the extracted edges (updated by history) are completely different, in another place, scrambled up. Or sometime the SubD normals simply won’t uniformate. Only solution is to ExtractControlPolygon and do UnifyMeshNormals and back to SubD or to extract SubD faces 1 by 1 and then rejoin them 1 by 1… It never felt a 100% stable type of geometry. And I’m using it daily. But you tell me this SubD structure is better… ok! Now that you confirmed me that current SubD methods are as planned by you developers, I’ll have to try again and again until it make sense and code start to work. Maybe I’m wrong to expect SubD methods to be as mature as Mesh methods, that have 10+ years of tests and fixes behind them… :see_no_evil: [image] Pierre Cuvilliers: We are working on this currently and it will soon be better than it is now. This is work happening in Rhino 8. Super! [image] Pierre Cuvilliers: I’ll share examples when they work in the public SDK. I’m also looking at ways to create good examples of how to work with the SubD SDK, I realize that what feels commonplace to the SubD C++ devs might not be evident at all for someone coming from meshes in the .NET SDK. I’m really looking forward for that! Thank you for the great support! Thank you to all the McNeel staff spending time for my questions!

[image] Steve Baer: Simplified functions for SubD aren’t necessary at the moment to try and wrap up Rhino 8 for shipping, but they are something that we can focus on in service releases of Rhino. Make sense… that’s one more reason to promptly update the licence asap.

[image] Riccardo Majewski: All the times I tried to code with SubD I ended up with a messed up geometry, edges or faces disappearing, invalid SubD. I tried many times, always gave up at the end. It’s really hard for us to fix abstract problems. However, if you have code that messes up SubDs, can you post it here? That way we can have a conversation about real problems. We can perhaps find alternate syntax that works, or fix the bugs on our end.

Sure, I’ll remember to attach a copy here when it happens again. Thanks.

I’m not sure if this is the best place or it should be split off: SubDEdge and SubDFace don’t inherit from GeometryBase, either directly or via SubDComponent. The actual problems I’ve run into: That makes it inconvenient to pass a collection of things that otherwise act like model components: aside from the inheritance, they’re peers of Curve and Surface. Passing around collections of objects and then verifying each time they’re received and used that they’re actually GeometryBase, SubDEdge, and SubDFace types is inconvenient. I couldn’t find an equivalent of GeometryEquals Trying to get properties of faces and edges is more indirect- area, center, etc. This could be fixed for SubDFace as an additional function signature for Rhino.Geometry.AreaMassProperties Compute (related but not inheitance) support in Display.Draw… What are the plans, if any, for these areas?

Hi @Nathan_Bossett, Indeed, it seems like it would be easier to have SubDEdge inherit from GeometryBase, the same way that BrepEdge does. I’m going to have to think about this one a little bit more, right now I see 2 big potential pain points: I cannot break the SDK between versions (by removing existing methods for example), so any new inheritance chain to an existing class might be an issue. To make a SubDEdge inherit from a geometry type, I need to keep a reference to the parent SubD, because the shape of a SubDEdge depends on the position of other vertices around it that can only be accessed by looking them up in the parent SubD. In C++ the class ON_SubDComponentRef (which keeps a reference to the parent SubD) inherits from ON_Geometry, but ON_SubDComponentPtr (which is just a simple pointer to the component’s data, and is a part of an ON_SubDComponentRef) does not. These might be solved by making a new SubDComponentRef type or similar. I’ll try a few things and see what works best. [image] Nathan Bossett: support in Display.Draw Do you have an example here? FYI, The CRhinoSubDObject handles drawing a little bit differently than the other Rhino objects (via static and dynamic displays), and the .Net SubD has pointers to these display properties. They have not been made public in the .Net SDK and I’m not sure why.

[image] Pierre Cuvilliers: any new inheritance chain to an existing class might be an issue We may be fortunate in that regard in that both SubDEdge and SubDFace are subclasses of SubDComponent, and SubDComponent is a subclass of nothing. I’d like to think any implementations can switch ot the correct overrides as necessary, but I’m looking at it from the outside- with a little browse around OpenNurbs. [image] Pierre Cuvilliers: [image] Nathan_Bossett: support in Display.Draw Do you have an example here? I was specifically looking at the DisplayConduit and the way in the drawforeground event one can: e.Display.DrawCurve or e.Display.DrawSurface There are two functions to draw SubD’s, but nothing for either SubDEdge or SubDFace specifically. For the moment I’m faking SubDEdge by creating a line then drawing that and SubDFace by drawing the relevant SubDEdges as lines. The second (Faces) is the one that probably makes it obvious I’m faking it if one compares to what Rhino does. Related: Should I expect the Edges to be in order to form a polygon if traced in succession? Whether the answer is yes or no, it would be nice to include that information in the documentation.

Thanks for the explanation, I’ll make sure we write additional examples for drawing SubD components. [image] Nathan Bossett: Related: Should I expect the Edges to be in order to form a polygon if traced in succession? Whether the answer is yes or no, it would be nice to include that information in the documentation. Which edges are we talking about here, SubDEdges objects or you line display proxy? Can you point me to the documentation page that is lacking information?

[image] Pierre Cuvilliers: Which edges are we talking about here, SubDEdges objects or you line display proxy? Can you point me to the documentation page that is lacking information? The SubDEdges available on a SubDFace: SubDFace.EdgeAt method (rhino3d.com) I had initially hoped that they would be in an order to trace the bounding edges of a surface with a consistent surface normal direction if you followed them along in order: (0), (1), etc. That’s not a request for behavior, just something I thought it might be helpful to document either way as far as what to expect: no expectation about order or whether there’s a consistent order they get placed in.

Any progress in SubD methods?

Scripting

Topic		Replies	Views
BUG extracting edges from SubD Rhino Developer windows	8	618	May 14, 2024
Rhino 7 Subdivision Surface Project SubD	287	56102	May 10, 2020
Rhino SubD - new fixes and features in 9 Sep 2017 WIP SubD	46	14436	July 9, 2018
Exploring SubD in the Rhino 7 WIP / 9.17.19 Serengeti (Rhino BETA) subd	35	8059	February 26, 2020
Sub-D modelling issues and improvements SubD windows	51	3465	April 25, 2022

Any progress in SubD methods?

Related topics