We are investigating migration to Rhino6. In the past, we have released quite number of complex grasshopper definitions which our end-users have used and might want to pick up in the future. Using those unaltered definitions in Rhino6 yields an annoying error that blocks the big part of the definition:
Rhino5 gives a warning with open breps, but provides the center point anyways:
There is no way that the end-users are going to dig into the definitions and solve the problem them selves. So I was wondering what else can be done? Maybe a rhino/grasshopper setting that allow old behaviour or something.
Another option could be to submit a change request of the GH volume component for Rhino 6.
Looks like the only difference between R5 and R6(GH1.0)Volumeis “Parallel computing” option.
A little annoying, but why don’t you check to see what happens if you disable it?
Thanks @Joseph_Oster for a alternative solution, however, I’m looking for a solution without changing the definitions. End-users have use many “template” definitions that we released over the years. They changed the “settings” for their specific project and nothing more, therefore their knowledge regarding Grasshopper could remain limited. Asking them to apply the changes (we also have very extensive clusters) is too much. On the other hand, we as the developers preferably don’t want to get bothered every time this happens.
R, WP
Can’t you tell your clients to keep using Rhino 5 for those “old” definitions?
Maybe if they want an update, tell them that in order for those definitions to work for Rhino 6 some modifications are needed and thus a fee would be charged. Sounds logical to me, but clearly you are not after this kind of solution.
Thank you @ShynnSup for thinking with me on this. As I explained to Joseph_Oster, it’s not about editing the definition (because using first a boundingbox would have solved the problem for me), rather an external work around like your suggestion. I’m afraid that I really have to ask @DavidRutten about it. R, WP
