So even though we spent a lot of money to upgrade to R6 from R5, and are now finding bugs and display issues with R6, when we bring up these issues we are then FORCED to fork out MORE MONEY to see those bugs FIXED in the next (R7) version. Then, when bugs in R7 are found, we are then expected to BUY UP to R8 to fix the bugs from R7. At no point will there be a clean and stable version. Sounds like a racket to me!!!
Hi - while I understand that this might be frustrating, please understand that there have been 15 Service Releases with bug fixes for Rhino 6 at this point. For Rhino 5, there were only 14 SR’s. At some point in the development cycle, we need to move focus to the next version. I’m afraid that we have passed that point for Rhino 6.
We give everyone access to the WIP of the next version to make sure that this works mostly as expected by the time SR 0 is released. We urge everyone to thoroughly run SR 0 in production workflows so that issues can be address during the lifespan of a major version.
At this point I’m only asking if devs could at least suggest a sensible workaround. We are working to fix it on our end meanwhile, but any outside help would be greatly appreciated.
I also remember R5 being hotfixed years after release date. Not 1 year and not even 2 years…
So what you are saying is that after 1 year from release of R6, you are up to 15 SR’s and that if going by the time span between previous major releases, there will be no more SR’s in the next 4 years until R7 SR 0 is released. You are essentially saying that in roughly just 1 year from release, R6 is reaching the end of the “lifespan of a major version”?
Rhino 5 more or less worked from the start. I don’t recall anywhere near the problems in 5 as I have experienced in 6. Every time I go to use 6, I come across some issue and revert back to 5. From the inability to open a step file in 6 that will open in 5 to exporting blocks. RH-52486, RH-52537, and RH, 52538. I’ve gotten to the point not to bother most of the time to report a bug as it seems the response is I’ll add it to the pile of problems that never ends.
Quite honestly why would I buy Rhino 7 if I can’t get Rhino 6 to work? Rhino 7 would need to do a lot more other then be a working version of Rhino 6, to make up for Rhino 6’s shortcomings before I would buy Rhino 7.
I guess it depends on what you mean by “end of the lifespan”. For most of our customers, they rely on stable, reliable products that aren’t changing every week. So once we hit SR6 or so, we hit the “beginning of usable lifespan” for the version. At that point, many of our customers are happy to continue using Rhino uninterrupted, and uncharged for years.
Those who want new things are encouraged and invited to download the latest WIP and try out the new stuff. We tend to break things during the WIP, which means it’s not always the best idea to use the WIP in production. That said, it’s also the best way to get new tools fast.
As for timing, there’s a lot more going on. I’ll see if I can help make it clearer.
- A year and a four months after Rhino 6 for Windows was released, Rhino is at 6.15.
- We’re actively working to release Rhino 6 for Mac “soon”, though we don’t have an official ship date.
- When Rhino 6 for Mac releases, it will be the first time that we are able to compile and release Rhino for both platforms at the same time. Rhino 6 SR1 for Mac will actually be 6.17 or 6.18 (wherever we’re at with Windows at that point).
- We’re also actively working on the Rhino WIP to bring new features for V7. Details are here.
You’re absolutely right to quote our release schedule as being every four or five years (if you ignore the work we’re doing to support both Windows and Mac). The reality is, we’ve had a major release every ~3 years for the last several releases. Rhino 6 for Windows in early 2018, Rhino 5 for Mac in mid 2015, Rhino 5 for Windows in late 2012.
I say this because I hope that, now that we’ll be shipping Windows and Mac products simultaneously, we might be able to release both more frequently. Only time will tell if that intention becomes a reality - but I will say it has been an intention for about 6 years.
And, we don’t tend to release software on a timeline - we release it when we think it’s ready. There’s a lot of cool stuff coming in Rhino 7… and we want to get it right.
The only and I mean really THE ONLY reason we purchased R6 was display performance. That’s it. Unfortunately, we work in the area that Rhino isn’t largely used in: architecture & pointcloud. So, you couldn’t get many free WIP testers to test everything in R6 WIP to fix. I get it. So, even a year after the release there’s still bunch of broken things in R6 that worked fine in R5 ON RELEASE DATE.
We’re not even asking to add options or tiny features or change how things work. We’re asking to fix what worked in R5 and it’s mostly trivial stuff in my estimation. Especially when everyone tells us that “It’s fixed in R7 WIP. use that”. We didn’t buy R7. You’re welcome to replace our R6 licenses with R7 and we’ll be gladly using R7 WIP.
Right now R6 is for us is like a brand new car that we just bought that leaks oil, a window doesn’t roll down, missing plastics here and there and it wouldn’t go into reverse. And you’re telling us that you fixed all these problems in the 2020 model and we should buy and use that.
Those of us who post on this forum for “bugs” and “crashes” arent looking for “new features” or cool cutting edge tools, we just want the issues we bring up taken seriously. I understand that every issue doesnt effect a massive number of users and the issues that effect greater numbers of users get dealt with on a priority basis but when our issues are dealt with a response of essentially just buy the new version when it comes out, it doesnt feel that those concerns are being taken seriously. I dont know how much of the core framework from V5 was used in V6 but when display and print properties work fine in V5 and not in V6, that doesnt seem like a “broken” “new tool”, but rather a fundamental element that needs stability.
We arent looking for the “new tools” to break in the WIP, we upgraded the licenses for our entire department to V6 a year and 4 months after release and still find a product that after 15 SR’s is still not a stable enough product to use in wide production. So we have a few individuals testing V6 in our workflows and when issues arise we post them to the forum to be met with a brush-off that the “issue is fixed in the WIP” “Go use that”, which we have no intentions of doing.
I think that @Asterisk can find a workaround for this. I would draw 2d Details just old style curves and hatches, there is no real need for surfaces, not even for blocks for just a few 2details.
On the other hand I believe that Architects and Facade Planners are becoming a more and more important customer base. Sometimes I have the feeling, that all architectural students are playing with grasshopper. But “real” workshop drawings, tight deadlines when the facades or interior architectural grills or sunshade systems have to be manufactured “made to measure” just in time short before the new airport or 5star Hotel is going to be opened is a complete different story. You just don’t have time to fiddle around with bugs.
For now I am still on V5, still waiting for V6 to become stable enough to be used in the above setting. It’s ok that the developement takes time, I would not even buy a new Mercedes from the first years of production. The “Modellpflege” Facelift models that are made after 3 or 4 years of production have always been much better.
So no, I’m not angry with Rhino developers, all great guys that even talk and listen to us in this forum, and give us so great support when we need it.
But Wim, I think that the most important things: pdf, dxf, stp, blocks and data exchange have to have the highest priority. If something that fundamental is not working stable V6 does not make any sense. These things just can’t wait until V7.
One of the criteria for a V6 bug fix is if it’s a regression from Rhino 5.
I know you’ve posted some of the problems here on Discourse - do you happen to know what the YouTrack links for them are? I see RH-52539 - what are the others?
I can’t promise that we’ll fix anything - sometimes the fixes are too difficult or require too many changes to warrant being done in a service release. To continue with your metaphor, it’d be like blowing your head gasket in order to fix your oil leak. It’s just not worth it - even if the oil leak is annoying.
Rhino 7 WIP licenses are Rhino 6 licenses. You can use both, at the same time, on your computer - using the license you already have.
Of course, just like everybody else wants their issues taken seriously. We’re a finite crew, and we just can’t fix everything, so we have to prioritize. At this moment, there are 4,200 issues we’ve resolved in Rhino 6 over the last 16 months.
That’s precisely why our licenses never expire. We’d hate to be in a position where we kept asking you for money, but never gave you anything in return. When the new version does what you need, you can upgrade. Until then, please keep using Rhino 5.
Also, it’d be interesting to know what YouTrack issues (not just descriptions of the problems again) you know about that are preventing you from upgrading.
Let me add more to this…
It’s important when you report bugs that you say “This worked in Rhino 5” - because that’s a flag for us. Also, when you see us say “Thanks, that’s reported as …” click on the link, and see if it’s marked as “Regression” instead of “Bug”. Those two things help us prioritize better.
As you might have noticed, there’s no shortage of bug reports on this forum. Prioritization is hard.
Prioritization is hard.
I believe that.
But even V1 was a tool not only to produce nice pictures, but production data.
PDF is important: We need to get plans to the shop floor, but more important we need to get plan approvals from architects and structural engineers and we need to document according to building laws like EN 1090. 95% of all plans are only sent by e-mail, very seldom we use our HP 500 large format printer.
And lots of CNC Maschines need dxf and stp, they just can’t use any arctic mode or improved render modes or the like. So I believe these things need to get priority.
I have to admit that I don’t spend a ton of time on Discourse, and I don’t have a memory of everything that you’ve posted here on Discourse.
Here’s what’s really helpful for us:
- Bug reports with very specific, reproducible steps. (Compare “PDF is important” to “When I open this 3DM file, and export the Top view to PDF at 11x17, the three curves highlighted in the attached image show up black - they should be red”). Please highlight what looks wrong - we can’t tell your design intent from the 3dm, because we’re not in your head. Just saying “this PDF is wrong” doesn’t help us narrow in on the problem.
- Information about when you saw the bug appear. Did it work in Rhino 5? Did it work in Rhino 6.12? We don’t take the time to go through every bug report and determine its birthday. But for you - you probably noticed it when it first became important to you, and it matters when you communicate that.
- Information about how much this bug matters to you. For us, prioritization is different when a bug is “a curious thing that I just noticed” versus “I can’t get my work done at all” versus “it takes me an hour to work around this, but I only have to do that a couple times a year.” Your emotional state is interesting, but some people are very emotional about every bug - that still makes prioritization hard.
The more specific you can be, the more likely that will be.
I know that many bugs reported are either not really critical, or a simple workaround can be found, or it’s a video card problem or something like that. But there are also still some more critical issues
As you said yourself: there are still many bugs reported. Like this one.from Holo. PDF draw order bug still O.k. we maybe found a workaround.
I’m just saying, that I think it is wrong to say we are at R15, we completely stop repairing bugs, and let the people wait for V7 to be released. If something is affecting pdf communication or data exchange it needs a bit higher priority I believe.
Otherwise Rhino can get a reputation of not beiing suitable for “real” production. That could hurt Mc Neel as a company as well as many users that are producing data for production.
Every bug I’ve reported here is a regression from R5. Every single thing is working in R5 as intended and not in R6. I’m only going to post these 3 that are critical to our workflows:
Obviously this one RH-52539 as we’re branching into using blocks more and more. Including 3D geometry.
This RH-52277 is just a productivity & habit issue. It feels wrong to force 26 people here relearn to use Ctrl+“other than V” to paste and move.
And this one has been logged and I guess deleted? RH-52583
Thank you for considering!
I completely gave up on text masking. There’s too many issues with it in R6 and non existent command/method support.
The issue here is - we don’t want to come to work one day and R7 WIP license is expired and we have to scramble to either make things work for buggy R6 or shell out for TWENTY SIX seats of R7 just to fix the bugs. If you’re saying that we can use R7 WIP 'till the end of days, this talk shouldn’t even be happening and I should be installing 26 seats of R7 WIP right now.
The gray items in R6 pic are blocks.
Note the text in detail marker is jacked up (justification broken?) in R6. But we can survive without it being fixed.
These are your words “As you might have noticed, there’s no shortage of bug reports on this forum. Prioritization is hard”.
If that is the case why was Rhino 6 even released then. About the only things that that comes to mind that 6 does way better then 5 is rendering and video. Granted I don’t use 6 that much because I need to get work done and don’t have time to fool around with annoying little problems, nor do the 4 members of my group who have Rhino 5.
This just is really irratating
Thank you for helping us prioritize. This is very helpful.
We’re investigating this one now. It’s likely to be fixed by @stevebaer, as it’s already fixed in V7. He’s also on vacation at the moment.
This isn’t a regression from V5 - it worked that way in V5, too, at least according to comments in that bug. I understand that it’s annoying.
It’s not deleted, it was just visible to our developers only. It appears that there is already a fix in 6.15 for it? I’m having a hard time interpreting @lowell’s comments - can you please try with a 6.15 build?
No, but by the same token, we are willing to make much more significant changes in the WIP than we are in service releases. So if you report bugs in the WIP, and ask for big changes, they’re more likely to happen here. If you wait until 7.15 to start logging bugs, we’ll be back where we are today - stuck in a pretty stable product that we’re not willing to do major surgery on. Of course it’s up to you how much you want to engage.
Are the gray items more evidence of RH-52539?
Can you send a V5 3dm file that reads incorrectly into V6 with the detail marker justification problem? If possible, please send a small file that only reproduces that problem.
Because the features we did add, and the fixes we did make, were worthwhile to other customers to buy. Again, if Rhino 6 doesn’t work for you, please don’t upgrade. We don’t want your money for something that doesn’t make your life better. We also offer a 100% money-back guarantee - if you’re dissatisfied with your purchase of Rhino 6, please return it to your reseller - no questions asked.
And, we’ve tried to make Rhino affordable enough that you can upgrade for a few things and still feel like you got some value. In this case, maybe that’s not true - only you can decide whether it was worth buying. Careful: if you bought at a discount when Rhino 6 first came out, that offer is now gone. If you return today and upgrade later, you’ll pay full price.
Please provide a specific reproducible bug to back your claim that export isn’t working (you claim to PDF, DXF, or STP). We can’t fix abstract reports of undesirable behavior.
If you want a bug fixed, please take the time to report it with a 3dm file, screen shots, and clear, reproducible steps to follow.
RH-52583 is not fixed in 6.15. It’s marked Awaiting Dependency. It is fixed in an unmerged branch of 7.x to the point of being testable internally via a test command, but requires an interface change in the DimStyle and Leader properties dialogs to be completely done. That’s why it’s in 7.x instead of 6.x.
The dependency is that there was a change needed in v6 file reading of DimStyles that didn’t show up until the fix for RH-52583 that would have caused some leaders to not be editable in 6.x. That bug is fixed in 6.15 and when a SR containing that fix is out, I’ll either fix the dialog stuff or ask Alain to do it and commit the fix for RH-52583 in 7.x