Rhino 8 SR11 + GH SubD/Mesh bug or feature?

Grasshopper
, ,
1

Hi,

This morning, I updated to the newly released SR11, and unfortunately, it’s causing all of my Grasshopper (GH) files that use SubD to crash. The issue seems to stem from this major change:

Up until SR10, when connecting a basic SubD component to a mesh component in GH, the output was the control mesh of the SubD, which made a lot of sense given the close relationship between a control mesh and SubD geometry. It was like using the “_SubDDisplayToggle” command, which I found extremely helpful for manipulating and creating SubDs in GH. However, after updating to SR11, the output is completely different. It now resembles the result of running the “_mesh” command with some arbitrary high settings. While this output may have some logic, I’m not sure how useful it is for GH + SubD workflows.

Ultimately, I just want to understand if this change is intended to be permanent—essentially a “feature” moving forward—which would mean everyone affected will need to find workarounds for this issue and update numerous GH files. Or is this just a bug that will be fixed in future versions, so we just need to skip SR11 for now?

Also this was working in the same way even before R8 , so in R7 was exactly the same as R8 SR10 and older, meaning that this has the potential to be a big issue for anyone who upgrades from R7 to R8 today as well.

Note: If anyone is affected by this change and needs a quick fix, you can uninstall SR11 and reinstall SR10 (I have the installation file, though I’m unsure if sharing it here would be allowed, as I don’t want to get banned).

Off-topic: It’s a bit ironic that this is happening on 9/11 with SR11.

Subd_mesh subdivide
Subd_mesh subdivide3150×1203 462 KB

Subd_mesh subdivide SR10
Subd_mesh subdivide SR102716×1239 294 KB

SR11 SubD test.3dm (1.6 MB)
SR11 SubD test.gh (4.1 KB)
Subd_mesh subdivide og
Subd_mesh subdivide og1656×967 154 KB

1 Like
2

Same question.

1 Like
4

yeah we both have the same question. But I’m confused with the reply from McNeel staff in this other thread, they seem to be addressing a completely different issue that other person borught up and is not your original question.

I just want an straight answer to the question if this change is a bug or a feature (permanent) to know how to move forward, because this can involve a ton of work for many users like you and I.

5

The issue is related. In the linked topic, I tried to get an overview how the subdivision is handled.

As @Trav explains, this is probably going to stay…

6

I’m not 100% sure its going to stay but we’re investigating why it changed.

1 Like
7

well, that explains why I was so confused.

This is going to be a nightmare for many people trying to get some work done in the upcoming weeks.

8

Hi Nicolas -

At this point, we don’t know why this was changed and if this can be reversed.
If users need to get the control polygon from a SubD object today, I’d recommend using the SubDPoly component, which does exactly what what it’s meant to do.
-wim

1 Like
9

let’s hope for more info about this, and hope for the best because I guess my coment is not about designing a new GH definition today, for sure if you don’t get the usual expected output you simply look for a different component like the one you mention that is dedicated to the exact porpouse and it totally makes sense, my coment is about the definitions that are already done and rely on the original output that has been there for I don’t know how long (years?) and are currently being use for production in commercial applications, definitions that worked like a charm and were perfectly fine and stable before SR11, and some are massive spagetti monsters, and the nightmare starts when is not about a direct replacement of the component “X” for another “Y” is about finding when the “mesh” container was used as an alternative for "SubDPoly"which is a bit different, plus the fact that in many cases you can’t even test if the definition is already stable after finding a couple of those, because it will simply crash completely and GH1 can’t be stopped, it’s a hell of a re-procesing.

10

After speaking with the developer, the change was intentionally done in order to solve several other outstanding issues where getting a control polygon back when requesting the mesh was not ideal and unexpected. The SubD Control Polygon component should be used instead for this purpose.

Additionally, we are going to make the change that was suggested by @martinsiegrist to the SubD to Mesh component and make Level 0 return the control polygon as well. To me this seems like a great addition.

https://mcneel.myjetbrains.com/youtrack/issue/RH-65870

2 Likes
11

Thank you!

1 Like
12

Thanks a lot, for the quick turnaround with the precise info.

2 Likes
13

One odd thing about this change is that it only breaks existing definitions, making many files incompatible with SR11 and newer versions, without any straightforward way to diagnose or troubleshoot the issue. In most cases, the system will simply crash due to the increased mesh density and the drastic change in output. It won’t highlight a component in red/orange that you can easily replace or troubleshoot.

I’m also struggling to understand the major benefit of this new output, given the arbitrary subdivision/mesh density. You could argue that if you want a mesh from a smooth SubD, there’s already a dedicated component for that: “MeshSubD,” which gives you more control over the density of the subdivision. following the same logic of the dedicated “SubDPoly”

I’m not necessarily challenging the new logic/output, as I’m sure there are valid reasons behind it that I might not fully understand. However, I’m more concerned about the consequences of the change and the actual benefits moving forward.

I just hope this post helps people who are having major issues with their existing files and are unable to troubleshoot them properly. Knowing that SR10 is still needed to even run the definition in the first place should help, so they can then make the necessary changes.

2 Likes
14

That will not solve my problem.

Many of my definitions have meshing logic like this:
Subd objects->Mesh Container->Weaverbird’s Catmull–Clark subdivision(at least level 2).
If Mesh Container returns many times subdivided mesh, the definition will be unexpectedly heavy, 6 or 7 times subdivided mesh will easily crash computers.

15

Mesh Container needs to be exchanged for SubD Control Polygon.

1 Like
16

I think the Mesh Container should return the mesh form of the SubD, like the Tab button in Rhino. The fact that the Mesh Container returns a subdivided mesh is logically baseless from the user’s point of view and, therefore, unpredictable. This hurts the usability of past definitions and also the intuitive aspect of Grasshopper usage.

17

The Mesh Container for All object types should return something similar to the Mesh command in Rhino not the control polygon. That is why the change was made. It was a bug. The SubD Control Polygon component was specifically built to serve the purpose you’re describing and should be used.

2 Likes
18

Things like this were returning not the expected result because of the conversion from from SubD to mesh in v7. See ‘Quad Remesh’ here for instance.

image
image1920×1117 153 KB

Prior to this change ‘ShrikWrap’ and any component that is able to work with meshes but assumes the input mesh is the “surface” mesh, which is the common assumption, were “failing”.

image
image1920×1138 187 KB

This change enables SubD to be used with these components in a more straightforward way.

19

I think you have a valid point of view there, that is a good logic, but at the end you are talking about an “assumption”, literally a point of view, an opinion, and the problem is that here we are talking about 2 (or more) equally valid “assumptions” .

for example: you talk about this being more “straightfoward” but in your examples you are literally connecting a SubD container to components that expect a mesh as input (it doesn’t gets any more confusing for a new user), so for me it makes a lot of sense that I have to convert that SubD into a Mesh before, and I want to do it in a controlled and predictable way, therefore I should use the “MeshSubD” component and that was the logic before SR11, I also consider the default mesh conversion chosen for SR11 way too dense, unpredictable and randomly picked, which is the complete opposite to the control mesh/polygon , we all know how a control mesh/polygon of a SubD looks like so switching between “mesh/smooth” is totally natural for us at this point, so having GH behave like it’s been doing until SR10 was completely fine and natural for me and at no point I consider a bug that a mesh of a subd was the control polygon, totally predictable, like using the “SubDDisplayToggle”, I thought .

so we can argue all day on which logic is better which one makes more sense, which one is the “common assumption”, , the more traditional, and so on, and the whole debate can turn quite philosophical very quickly especially when you add to the mix the fact that a SubD is not a Mesh nor a Nurbs but is both at the same time, is almost like a geometry with an existential problem but it has some of the best things of both worlds.

so we are talking about a 3rd kind of geometries, and that can lead to even more questions, should we treat it always as a mesh in a way that “a Mesh of a SubD is always the control mesh / polygon” (SR10)?. always like a Nurbs/brep that ignores the control Polygon unless it is specifically extracted from it (SR11)? should every component that expects a mesh or a Brep fail when connected with a SubD, forcing a conversion to happen before that for both cases, leading to a whole new treatment specifically for SubD’s (this is a third safer logic)?.

and even if we find the perfect solution to the philosifical questions, the real problem is that we are talking about a commercial software that is used in very serious business today , and was working perfectly fine (in this regard) with a logic that wasn’t necessarily wrong but different and even if I agree that the new logic might be “better” and stronger, that won’t change the fact that the update that was pushed with SR11 is suddenly making for me in particular hundreds of files totally unusable unless they get updated with the new logic, and we are not talking about a change implemented between versions, let’s say R7 to R8. which to some degree can be more understandable and expected in a way that some files won’t work between versions?, and McNeel does a great job with legacy support that allows us to run old files that might only work with some specific versions, but as far as I am aware that legacy support is not extended to Service Releases, only to main versions working with the latest SR.

so as I see it from a very practical point of view this is an update that won’t fix a single existing definition, is doing the complete opposite breaking many definitions that were working perfectly fine until SR11, and is also not solving any major bug because all your examples here can run perfectly fine on SR10 (and older) by adding one single component after the SubD container, “MeshSubD”, a component that actually does a better job than the default mesh conversion that was just introduced, and this is exactly how all definitions have been designed for years now, and to make things worst broken definitions will be VERY difficult to troubleshoot because in many cases they will crash most PC’s almost instantly when you try to run /test them after a supoused fix, the output / input is still a mesh but a completely different one and that makes thing harder to detect and troubleshoot, is not a single 1:1 component replacement that you can tackle using the “find tool”.

Finally, please consider that reversing this change in the next SR12 is not going to break any definition, not even one created after SR11, instead it will bring back to life all old definitions that are currently broken, everything will still work. (I’m not 100%sure on this one).

At the end I’m just a user extremely frustrated because of the last update and you are the developer, so I have no other option than accept the change and hope for the best, but your message really leaves me with more questions than answers.

Note: is that a SubD edited with a cage? why ?

20

I would have to use the word convention instead of assumption.
The general convention all components follow when a piece of geometry is converted to Mesh is that it returns a mesh on the surface, not on the control polygon, see Breps, Surfaces or Extrusions in v8.

Let say you have a geometry component and you select a bunch of geometry from the model or to make it more real it comes from a filtering based on some criteria, and you want to use any component that takes a mesh after.
In this case with the previous behavior you have to filter you geometry set to know if it contains a SubD, and dispatch these SubDs using a different logic.

Here an example that works when the standard-common conversion from geometry to mesh is used.

image
image1920×979 132 KB

The previous conversion from SubD to mesh just forces the user to place a filtering logic in-between to make it work correctly.

Note: is that a SubD edited with a cage? why ?
It has the control points enabled, is not cage edited on any way.
I tried to show that the point is inside the control polygon of the subD but is not inside the SubD itself.

1 Like
21

I agree this is quite a strong logic and definitely a more conventional one, however it doesn’t necessarily makes the previous logic a “bug” that needs an urgent fix or a change, your example is a very particular case where having the SubD act like a regular Brep is beneficial, however I struggle to envision a workflow that involves working with so many different kind of geometries to be run in the same component, given the parametric nature of GH you tend to work a lot with a single type of geometry at a time to generate predictable data, and when you have to deal with multiple kinds is pretty normal to filter them, going back to this new example, if you add points and curves to this mix of Mesh/Brep/SubD, is not uncommon to filter them anyway to avoid having errors, and as you mention SubD’s can also be easily filtered, converted into a conventional mesh and replace them in the original list of elements, it’s that a workaround?, maybe?, I can also call it a “different workflow”, one that everyone has been using for years at this point if they want to achieve things like the one in your example, but it’s not something I would call a major bug, or something that can’t be explained under other logic, like “SubD’s are a different kind of geometry”. So I totally understand where the change is coming from, I wouldn’t be taking the time to type all this if this logic was there since Subd’s were first introduced, or if it really was fixing a dealbreaker bug.

So I guess my frustration comes more from the commercial / practical side of what this change means, and makes me wonder.

is the change really bringing to the table a major benefit, a fix that outweighs the damage it can make to existing definitions that currently work perfectly fine?

Is it really fixing a bug, or is just changing something that can be explained with a different logic?

does it really make sense to intentionally create a semi-incompatibility of existing files created with Rhino 8 that suddenly are now completely broken and crash almost any PC and somehow the easiest way to troubleshoot them is with Rhino 7 or even worst with a R8 SR10 that is no longer available for the general public?.

1 Like