No center point output anymore by volume GH component with open breps in Rhino6, any work around?

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:

Rhino6 gives an error with open breps and provides no data at all:

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.

Best regards, Wei Pien

@DavidRutten might be able to tell about this decision.

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?

Might also be worth a shot to check the document’s tolerance. Rhino 6 by default has a smaller tolerance than Rhino 5.

Disabling the parallel option make no difference:(

For testing I increased both absolute and angle tolerances a hundred fold, but the result is the same.

Not always the same, of course, but this gives a pseudo-center point?


There’s not much more that can be done without you posting some geometry to work and troubleshoot with.

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.

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