The horror the horror of exporting to pdf and illustrator

Thanks @Trav, and just want to make sure that your YT only list the one issue in my second video.

There’s other major problems on my first video too:

  • dimensions, arrows and text not exporting unless exploded

  • exploding them causes flipping/mirroring

  • line quality on export gets destroyed

Thanks,

G

Hey Gustavo -

In your second video at 2:07 you show that the dimension text ends up correctly in the PDF file. Arrows also show up in the export preview dialog in Rhino. The bug is that the dimension text should also show up - RH-62040

That is expected behavior for annotations. You need to uncheck Text reads forward when viewed from behind if you need to make sure that annotations are facing the “correct” way.

image

Is it possible that these parts consist of arcs? If so, I think we have this one on the list as RH-44145. If you think that it might be something else, please provide a sample file.

Thanks,
-wim

hi Wim,

Yeah, owe need to export exactly what we see in our viewport: texts, arrows, dimension, texts, all. You miss one thing and we got nothing. And this is not rocket science this is basic basic 30-years old 2D computer stuff.

Thanks for the mirroring/flipping suggestion but that does not solve my problem. I want to have that option enable, I never want to be reading text flipped. And also I never want to explode text flipped. I also never want to export anything flipped. In fact I’m only dealing with exploding because your exports don’t work. We should be fixing that first.

But I see the problem here, in this case these two text items are showing in the opposite site of these volumes, and the front view text and the rear view text are being flipped from each other to always look correctly on a given view:

So If I explode, then either the front view or the rear view will be flipped, and out of since with the viewport specific appearance, correct? well… I exploded from the back view, so of course I want to see it correctly form the back view, not the front. Unchecking that option will not help me there, in fact I will be seeing it flipped before and after exploding. I think this should work on a WYSIWYG basis. and should pay attention to what viewport /view is active

BTW If I explode here, this is what I get:

This is ridiculous. File here before exploding: front-rear_text_gf_201218.3dm (186.4 KB)

I said this before and I’ll say it again: you guys continue shipping and selling software that is provenly untested, and I should not be the one providing you these examples and explanations. These are all things that should be solve internally, and the software we use should just work.

I see this situation getting increasingly worse, also combined with this other problem that you are all getting into new spaces (like SubD) without enough focus. So now you are doing the double whammy: shipping untested old tools + shipping new tools that barely had much thought, let alone competitive landscape awareness.

Is this the way forward for McNeel now? because it really sucks IMO.

Gustavo

1 Like

For me it started with the Mac version. McNeel just can keep up - never seen 33 SR before Rhino 6. I see why many software companies move to the cloud versions - one code for all platforms. And now they have to deal with M1.

A high number of service releases is a result of improvements in our development processes. We want to get quality updates and fixes to users as fast as possible so we developed a delivery cadence. Approximately every four to five weeks we deliver a new service release with stabilizing candidates for that service release published every week leading up to a new service release. Service releases contain bug fixes, new SDK features, and sometimes new critical features that users need. When a major version of Rhino gets to be about 3 years old you can expect the service release to be somewhere in the 30s. We are already on SR1 of Rhino 7 with SR2 available as a release candidate because we are following this cadence of delivery.

Sorry you’re running into bugs. I just had one added to my list from this thread for missing text in the preview. I’ll try to take a look at it this week and will hopefully have something fixed shortly.

1 Like

Just one sample - BoxEdit. It was broken many times during Rhino 6 Sr’s. Now is broken again - R7 Boxedit bad change from R6 - Rhino / Rhino for Windows - McNeel Forum.
Rhino 4 was rock solid.

Yes. I wrote about this 2 years ago:

It’s obvious at this point this is absolutely unimportant to McNeel. I gave up even reporting how broken BoxEdit is on and off. My only comment was last week about a feature request: working with any selectable SubOjbect. But what’s the point do adding features to a room that continues to be broken?

No need to apologize for that Steve. Running into bugs here and there is normal. Shipping us untested software so you offload to our businesses the work that should be handled by your business is what frustrates me.

It’s always super exciting to hear about all this future stuff like compute, and new architectures, and all that fancy stuff. But any hour of your teams’ work that’s going into that, prioritized over going into shipping software with a basic level of polish and functionally for those of us who have to work with your software, is really bad prioritization IMO.

Best,

Gustavo

I understand the frustration. But it’s not so simple to “test everything”. You don’t. And you don’t “fix that which isn’t broken”. Until you know it’s broken, that is.

If they now have improved the development process, it means that years ago (with all those old bugs that didn’t get fixed) now have a better chance of getting fixed. Due to adding tests as bugs occur / gets reported. I wouldn’t fix code which isn’t (known to be) broken either.

I wouldn’t try to write tests for “everything” either, simply because then you don’t get half the stuff out the door which now is shipped. And there’s this not so well known but very true saying out there regarding testing in general:

– When you say something is tested, it only means that you have tested that which you have have tested (implying: not the all the other stuff which you didn’t test).

And this is why testing is something that gradually grows as bugs are getting known/reported. You can’t and will never test everything. No one does.

Although I understand the frustration I also expect the improved development process to gradually make things better in the future. Sounds like good news, only, to me. Bugs won’t stop to pop up, but if the Same bugs stops to pop up, that will make the future brighter.

Have a nice weekend all of you!

// Rolf

Every feature added and every bug fixed in our bugtracking system goes through a process where it is tested on Windows and Mac before it is documented and announced. There are unintended consequences of fixes that may cause other bugs. There are times when a bug is very difficult to reproduce in the first place. There are times when the tester may not have the right information on what exactly to test. There are even times when we get it right.

I’m confident this process could be improved and over time we’ll figure out new ways to make these improvements.

Thanks for your input Rolf, you bring up some really good points, yet I would like to challenge the approach you listed about testing.

In our little company we have one rule: “we always check our work. And when we are done checking, before sending it to client, we checking again.”

Could we work in more things, more clients, more projects, more concepts if we didn’t spend so much time checking our work? Absolutely! Would it be more fun? Oh yeah! …checking your own work and documenting it thoroughly is boring AF. It limits our growth and it fact it makes many people who otherwise would be a good fit to our team not viable to be part of the team. Programmers are a very hot commodity and I’m sure of you put this burden on them many would just leave McNeel or never join to begin with. But there’s plenty of other people that can do this for them. QA is a thing.

There’s a level of care and craftsmanship in their work that I think it’s falling behind, or maybe as I have bigger quality issues to deal with in a production pipeline of people ‘checking their work’ I’m simply more aware of it.

I think if you are expecting your customer being the ones who constantly find out what you haven’t resolved, you are not giving them a very good service or a very good experience.

I know the bar is very low in the 3D software industry. In fact, I can’t even think of a better/viable alternative to Rhino. But some improvements in their process are overdo. For example you just can’t just keep shipping new builds where a Step/OBJ/PDF/DWG exporters/importers are broken. In any possible way. This is absolutely unacceptable. I think we need to agree on a basic level of respect to customers where the most mundane stuff that hundreds of thousands of users use every day can’t just simply be that carelessly broken.

I want them to take this 10X more seriously. And I think it’s perfectly reasonable.

G

2 Likes

I’m an ol’ QA consultant. (that’s where I got that “you tested only what you tested, nothing more”. :wink:

I won’t debate with you about the most critical functionality you depend on in your daily (as for me I mostly crunch terribly bad meshes from MRI & CT -scan, no quality check there no…). It’s ruining my old QA-mindset. :slight_smile:

But I also spent years on huge development projects (business systems though, not CAD), almost entirely without testing (as the chief designer I didn’t think I had the time…) but strangely enough, the huge system worked more or less flawlessly after 6+ yrs of development. But I had the whole system “in my head”. which meant I could predict silly behavior, both from users and from code. It still was a wonder how it worked so well. But, CAD software is different from business systems. I can’t imagine a single developer holding the entire codebase of Rhino “in their head” so that they can predict all consequences from changes and additions.

Anyway, software development is still a bit of black magic. Except for it doesn’t work better if you put a spell on it… :slight_smile:

Have a nice weekend!

// Rolf

I know you know this Rolf, but for others’ benefit:

There’s a heck of a lot of science that can be applied to it these days.

One piece of science involves making testing the primary focus of your effort rather than an adjunct to coding - as embodied in the culture known as test driven development (TDD). In that culture you write an automated test of behaviour that the software must pass, write basic code which may fail that test, extend the code until the test is passed, then add another test and extend the code until both tests are passed, then keep adding tests, extending and passing. If at any point you fail an older test you have to fix that. The idea of passing all the old tests as well as the new is known as regression testing. Your tests are the specification for the software. Anything not covered by a test is not part of the specification and that behaviour is not guaranteed. Your specification is a contract with the users of your software.

In this culture a piece of software cannot be released at any time when one or more test fails. Therefore a new release cannot break something that previously worked.

TDD dates back to the late 90’s (embodying much earlier concepts).

Jeremy

3 Likes

TDD is and sounds ideal. But, the basic problem remains - namely no matter what strategy or concept you are following - you are still testing only that which you are testing. That’s a brutal fact with consequences.

It takes time to “cover up” your tracks (bugs) with a test you didn’t predict was needed. It’s just an everyday reality in software development.

If the system can be grasped by a few persons, testing may be covering potential mishaps earlier, if it’s more complex, and structured testing applied only late in the product cycle, well, then you’re going to have bugs keep popping up, no matter the strategy.

Again, It’s only what you test which is tested. How you get to the point where the testing is extensive enough, that’s a different story altogether. And much different from case to case. :slight_smile:

// Rolf

I’m open to change. Any suggestions on how to improve our development processes are appreciated.

Here’s our process for fixing bugs and adding features. I’m going to strictly refer to requests made by users here on discourse. Features and bugs are gathered from many other sources, but for the sake of this conversation I’ll stick with discourse.

  1. A bug or feature as logged in youtrack with a link back to one or more discourse threads
  2. The YT issue is assigned to the most appropriate developer for the job.
  3. (Test #1) The developer fixes the issue and to their best ability
  4. The YT issue moves from open to a “Needs Testing” state and is assigned to someone in QA
  5. (Test #2 and #3) The tester tests the change on Windows and on Mac. If the issue looks fixed it is moved to a state of “Needs Doc” and assigned to someone on the documentation team. If the issue does not look fixed, the issue is sent back to the developer
  6. (sometimes Test #4) Sometimes the documenter will find something wrong and send the issue back to the developer.
  7. (sometimes Test #5) When an issue has a link in it that points back to discourse, those threads will get a comment from Brian when we release a new build that we believe the issue has been fixed. We can’t force the initial poster to test this fix, but we hope they do as it seems to probably be important and repeatable for the initial reporter.
2 Likes

We do employ TDD, but we could do a lot better. Our TDD tends to focus on things like geometry intersection routines and file IO. We definitely can do a lot better here for more cases in these areas, but I don’t know of good ways to set up TDD for user interface adjustment which would be for things like the boxedit UI.

1 Like

Hi Steve,

I want to write this as respectfully as possible. You know just about all Rhino users appreciate the hard work you and the rest of the development team do to bring us such a great CAD application. And I appreciate the opportunity to make suggestions about things that would help my work. But I am not a developer and I don’t want to be a developer. When something doesn’t work of course it should be reported to the development team, but eventually I just look for solutions to keep moving forwards and if that involves other software then bit by bit Rhino becomes less and less important to me.

One more point I want to make is that as a developer you may see a bug as a problem to solve. But for me one tiny mistake in a file I submit to a client or vendor can be truly catastrophic. So from my point of view Rhino is now releasing new features too quickly, maybe to try to capture market share, but in the end you are losing my confidence in the software.

6 Likes

Hi Steve,

I’ve been thinking more about this. I think we have enough historical data of things that continuously break in Rhino. Some break because of interdependencies with other tools your team is updating/changing/improving, some other ones break because externalities change (example: new versions of Illustrator/Acrobat/Solidworks move your cheese).

Speaking of cheese, last night I went to the supermarket. We sometimes go to Whole Foods for a few special things, but for everything else we go to MarketBasket. You might not know Market Basket, since it’s a Boston company, but they are a nice, humble, high-value, great people, no frills store. This is their website BTW, look how adorable:

As I was shopping there and thinking about this I thought something: Rhino is the software version of Market Basket, and on my way to check out I saw this, which made me laugh so hard:

That’s the way I feel you all treat us: You are always happy to clean our register belts, if we ask. And if we show you how to clean it. Ideally we should also bring some cleaner with us. And after you clean it we might have to explain to you why you cleaned it wrong. But if you payed more attention about cleaning we would never have to let you know that it got dirty, let alone tell you how to clean it.

I can see this ‘open development’ as you call it ( I prefer ‘free labor’ to me more clear about what it really means) making some sense for new stuff. but I don’t think it makes sense for regressions, especially for regressions that are constant, almost predictable.

You can very easily make a checklist, We’d be happy to help with ‘open development’, of all the things that constantly break: Material mapping, Step imports/exports, mesh data like mapping and vertex smoothing, BoxEdit, material editor, dimensions import/export, 2D linework to various formats (failing at lines and arcs in 2020, really???), we can go on and on…

These are all things that are important, these are the types of things that I mentioned the other day: I’d never ship work to a client without checking, twice. Yet for you guys, these are things that you git used to just expect us to be the ones asking you to clean the register belt. And just because it seems normal to you, let em assure you thing: it’s not normal, at all.

These things I can also guarantee you that cannot be checked with any automated process, and can also guarantee you that require people with at least mid-level modeling/drafting/design experience. So we are looking at probably 1-2 FTEs to do this work. They need to be heads down, passionate, modelers/designers/architects/operators types, very detailed oriented crafts people.

So the solution is obviously unavoidable: I think you need to hire more people, because there’s no other magic formula to be able to really check your work, twice, by capable humans, before you ship it to us. This is the way all mature businesses work.

I’m always grateful for all the work your team does, but I can also tell you, the burden you guys put on us is getting in the way of getting work done, growing our businesses, having reliable results and delivering data that we can trust is a bit too much. And that’s not acceptable.

Best Regards,

Gustavo

2 Likes

== NUANCED PRIDE ==

Hm. Let me add some nuances here, about “mature businesses” etc. I’m with you on the need for stable tools. Absolutely. So let me share a story about one of my experiences with problems like this.

People being old enough remember world famous company and person names like Borland (Turbo Pascal, Delphi, by Anders Hejlsberg which also is behind C#), CodeGear, later acquired by Embaracadero aso. Most people would regard them as being mature companies.

My personal experience related to this topic was that I once designed a “huge” software system (business system) in which I was the chief architect (as an external consultant) supported by a team of 5 other developers (client’s employees). It matters to mention that the whole project, from a blank paper to deploying the sharp full fledged system took about 6 years. We used a Model Driven ORM system called Bold Architecture (for Delphi). And the relevance of Bold is similar to what Rhino is for you - namely one of the main tools for doing daily work.

Problem was, no one had ever tried to make such complex data structures, with such tough requirements on performance as that which I was modeling (real-time instant calculations for user feedback of this and that). And the Bold (“Rhino”) framework broke down time after time. For years, Some numbers:

ELEVEN MONTHs WASTED(?)

Out of those six years I spent circa 11 months, full time, debugging the Bold Architecture (my main “Rhino” tool at the time) in order to be able to do all the modeling tricks (to the limits of OOP) which no one had ever tried to do before that crazy Swede tried to do it (fully legit OOP concepts though, but the platform just couldn’t handle it.

This also mean that the bugs or glitches in the platform again and again delayed vital “domains” of the system to be fully designed, which in turn meant that we had the system as a whole in a kind of “limbo” in which we could not test if the “whole” would actually work. This went on for years (including not being able to test the overall system).

11 month. Full time. For free.

STRONG RESULT

The result? After the system I designed was finished, also the tool, the Bold platform was, and is, the most competent and reliable application platform for Model Driven design of Win32 applications that exist. Also the last minor version of Delphi which supported this framework (called Delphi Architect) was bug fixed, and solved, by me and my team. For free. Borland/CodeGear (acquired by Embarcadero) got it all for free. Anyway,

the final result of this “giving away for nothing” activity was that we eventually had in our hands the best tool we could have ever dreamed of. It reached the level of “industrial strength”

And “industrial strength” is what I think you Gusto expect from a professional tool. I love the term “Industrial strength” because it sounds rock solid, and that exactly what I also mean. The system we built cost XX+ million dollar to develop, and it has never crashed (in a decade, from when it first started). Ever.

FOR ALL

And now the entire framework is open-sourced since a few weeks, by Embarcadero. But everyone who knows about this framework from before are waiting for an even better version to be uploaded, which is the version currently driving the business system I designed (it has all the fixes and optimizations which Embarcadero didn’t bother to fix).

Win32 / .NET

Now, don’t overlook that “BoldForDelphi” is a Win32 original version of the framework, but there’s a more modernized .NET version (not open source though) which by Borland/CodeGear was first dubbed “Eco” (developed by the original Swedish team behind the win32 Bold version) and now licensed to a Swedish company under the product name MDriven(.net). Based on the rock solid industrial strength Bold version.

ROCK SOLID PRIDE

As said, rock solid stuff, and why I bore you with repeating this is because, yes, I do feel proud of my contributions to increase the capability AND the quality of this framework to the level of “industrial strength”. For free.

Don’t get me wrong. Smarter guys than me did the development of Bold. I only was the nastiest (technically) “test bench” they had ever encountered. And this is relevant to testing in general - I was an outlier in terms of how I used the system (among many other designers). This relates to “You are testing only that which you are testing”. there’s no way that the framework developer would even know how to rig such nasty use cases as those I used in my design. This is an aspect must not be overlooked. (regressions of essentials is another matter…)

NOT ALONE

But I’m trying to comfort you @Gustojunk” to not feel so "used and abused”, or not to think you’re in such a unique position of being a “victim of the development process” of Rhino. Instead I really hope you continue “encourage” the McNeel team to improve both Rhino and the development process of Rhino. But again, no, you are not alone in your situation, and you are not in a much “worse” position than many other users of products developed by very (very) “mature companies” in the field of IT.

THANK YOU

Just so you don’t miss my main point; I want to openly thank you for your contributions to Rhino and it’s gradual improvement. I wish you would feel more proud than sorry for your efforts. And I think McNeel is appreciating your contributions as well, and also taking your advice seriously in trying harder to avoid regressions etc.

Sorry for the long post.

I wish you all a Merry Christmas and a Happy New Year,

// Rolf

Plug 1: Opensource win32 “battle tested” industrial strength MDA platform BoldForDelphi. This link is to Embarcadero’s sources, but for anyone interested I’d suggest waiting a month or two for the contributions to the sources from a dozen developers/companies who spent a decade+ to add enhancements and optimizations:

Plug 2: A modernized .NET version of the Boldish code base above (the term “bold” still shows up here and there in this architecture disclosing its origin). “MDriven Framework” is the .NET equivalent to Bold Architecture above:

A word about “slow heavy frameworks”: No. Not so. Or, it’s often very true, but not in this case. And it has its reasons, but the thing with this framework is that it enables a special kind of optimizations which you would never, ever, even think of trying to achieve by handcrafting your own framework. For anyone interested I can tell more about that part, but not now. :slight_smile:

Disclaimer: And no, I have no affiliation with any of the companies behind the links above, but I do know what this stuff is capable of.

6 Likes

I don’t know. We use different software packages at work which cost 10-50x the price of Rhino (often per year), and even there not all companies take customer’s troubles seriously, or even listen to them at all (although we just switched CAD vendors to one which might actually appearsto be different… fingers crossed we finally found that unicorn).

You often get what you pay for, and what you pay for Rhino is ridiculously little (evident by the fact that some plugins cost more than Rhino itself, which I don’t think I’ve ever seen anywhere else).

1 Like

Old manager wisdom: you only need to start to worry when customers STOP complaining.

1 Like