Keep Rhino 5, or upgrade to Rhino 6?

Just to remember that it is possible to add old component in GH1.0 using #

https://global.discourse-cdn.com/mcneel/uploads/default/optimized/3X/2/b/2b8c31fa0bfdf95977e715ff3b6f858947efbf72_1_282x250.png

I agree a 100% with you.

I’m using R5 now since it came out and I have to agree that GH is absolutely incompatible with GH in R6.

I upgraded thinking that I can use the complex design program I created with GH in R5 now with R6. It is impossible.

They are too many components that behave completely different as Joseph has commented before, like for example: the boundary component give you the expected output but changes the endpoints of the curves used.

I worked now for 5 weeks trying to replace or repair the components that behave differently and it has become a never-ending story.

I’m very disappointed, maybe for other people the money I spend to upgrade R5, the new computer I purchased to run the more complex R6 naively thinking that every think will run faster and better with my program (more than 100.000 components) and the time invested to make it work, don’t mean nothing.

But for me the conclusion is, if you have something running as complex as I have don’t upgrade or be aware that you have to start from zero because THEY ARE NOT COMPATIBLE.

And don’t get me wrong I’m not saying that R6 is bad, but if someone would have hinted to me the grade of incompatibility; I never would have spent the money.

I agree with Joseph this should have been explained clearly at the time when the Upgrade was released.

@franciscok I’m sorry to hear that. Little worse than wasting a bunch of effort (and money, and time) on a frustrating project that didn’t work.

The problem is we don’t actually know the degree of incompatibility. Grasshopper relies for almost all of its geometric computations on the Rhino core, and a Rhino programmer may at some point decide to rewrite a core algorithm to improve speed or memory footprint or fix some bug and this rewrite changes the output in ways that do not matter when using the algorithm from a Rhino command. However they might matter to people whose grasshopper files depend on the old algorithm.

I’m not saying this is unavoidable or not our fault, it’s clearly both of those things and we need to get better at protecting this kind of compatibility as well as just pure SDK-breakage.

I would expect a relatively low failure rate, but even a low rate multiplied by one-hundred-thousand components ends up being a big number I guess.

The experience you had is the exact opposite of the one we’re supposed to give our customers, and Grasshopper sits right in the middle of it, for which I can only apologise. I wish there’s something useful I could do, but that will take time and lots of cross-company talk and work. This is unlikely to fix your particular problem. Best we can hope for is make this less common in the future.

2 Likes

Dear David,

I really, really appreciate your words and since in my live I have worked on so many big projects I know and understand that we are not always able to keep control of everything and therefor things happen.

I just needed to release my frustration. I’m over it and have decided to keep things as they are in R5 and new projects I will be working in R6.

Let me use this occasion to applaud your work and let me tell you that the Idea behind is phenomenal and your work is certainly not appreciated enough. I’m not the person that ask many questions, I’m more the type that fights on his own, but I certainly have followed over the years more than ones your explanations and appreciated your advice in the forums.

Thanks again,

Francisco

Hi @DavidRutten I took this report, that seems this incompatibility continues in Rhino 6 Windows and in the new Rhino 6 for Mac has a different behaviour too, why?
cc @dan

Rhino 5 correct behaviour


Rhino 6

Rhino 6 MAC

CURVE_bug.gh (10.3 KB)

3 Likes

I had the same situation here, seems R6 changed something about how curves are constructed.

Thanks @ThomasE for the test case, I’ll have to dig deep to see which functions are involved and why they disagree on point order. This does very much seem like a regression rather than just a change.

1 Like

Hi @DavidRutten and @dan This issue related to vertices order continuous on RHINO 7.

Rhino 7 WINDOWS

Rhino 7 MAC


CURVE_bug.gh (10.3 KB)

Hello @DavidRutten, @dan
Was this bug related to the point order already reported?

1 Like

I did find a bug logged for this:

RH-47765 Brep edge order is different. Possibly not a bug.

2 Likes

thank you @dan
Going deeper into this, it happens when you pass a Brep to a curve parameter, the vertices order goes back by 1. This issue started in Rhino 6 and continue in Rhino 7.


CURVE_bug_te.gh (14.3 KB)

1 Like

Does this continue in Rhino 8? could someone could test my file?

1 Like

here it is on v8 (8.0.23304.9001, 2023-10-31)

2 Likes

Thank you for the test! What a shame that this problem continues in Rhino 8.

This image is from Rhino5 (this is the expected behavior)

CURVE_bug_te.gh (14.3 KB)
What’s wrong with forced conversion to curve? @dale could you log it as an issue please?

What’s the point? Looks like you’ve been chasing this anomaly for nearly five years so work-arounds are called for. One thing about R8 bothers me more than anything else, through I’ve hardly touched R8 so far. The Area component is not compatible with R7 :exclamation: No idea what changed but it doesn’t seem too hard to modify R7 to recognize an R8 Area component and substitute the R7 equivalent on the fly. This one little thing, in a commonly used component that has existed forever, baffles me because it is a road block that could “easily” be avoided.

Can you provide an example?

Thanks,

– Dale

Hi @ThomasE,

There is a lot going on there - can you prune this down to just what does not work as expected?

Thanks,

– Dale

A post was split to a new topic: Gh 8 file not opening in GH 7