Surfaces in blocks print differently than on their own?

1 Like

Hm - in my dumb test I do not see this- 2 detail is in shaded mode, one box is a block the other exploded -

There must be more to it…

-Pascal

Here ya go. It actually rasterizes it. Just not the same as non-instance surface.

RhinoPDF.pdf (205.6 KB)

PDF test.3dm (87.1 KB)

What it looks like to me at the moment is that the surface in the block obeys Print Color (Black) and the one that is not in a block uses display color. Your pdf shows both the same however, no cyan. My print matches the preview…

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

As far as I can see this is fixed in V7.

-Pascal

1 Like

This is how our Shaded is printed:

RhinoPDF.pdf (197.5 KB)

Shaded.ini (12.6 KB)

Yeah, sorry for the confusion - I turned the bottom surface back into block to see if it changes anything.

I did another test and whether you print from the model space vs paper space or detail view, itdoesn’t matter.

Display Color is the only one that prints them properly.
Even Black and White is inconsistent, block vs surface.

Can this be fixed in R6 are we shit out of luck again?

I’m afraid it is unlikely to be fixed in V6.

-Pascal

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!!! :rage::face_with_symbols_over_mouth:

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”?

Wim

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.

2 Likes

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.

3 Likes

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.

Hi Wim,

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.

Hi @JoergH

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:

  1. 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.
  2. 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.
  3. 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.