The horror the horror of exporting to pdf and illustrator

Serengeti (Rhino WIP)
17

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
18

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

19

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
20

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

21

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
22

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
23

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
24

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:

capture_gf_045252PM_201222
capture_gf_045252PM_2012221195×836 248 KB

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:

IMG_1057
IMG_10571154×866 351 KB

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
25

== 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
26

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
27

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

1 Like
28

I think @gustojunk has a very good point there. Tools that are the foundation of modelling has to be taken much more seriously.
Take a look at how Rhino handles filleting a corner on a box where something as simple as a 1,2 and 3 units radius edge meet:

image
image658×513 69 KB

This is far from production ready and has to be manually remodeled. The fastest way to get a quite good result is to fillet first the 3 unit edge, then the 2, then the 1 and then extract surfaces, blend edges, split surfaces and join and run sweep2.

image
image789×588 85.4 KB

If you use patch with default 10x10 settings you get a bad result too, so patch which is a tool to fix situations like this has not been updated for a decade or more and does not take tolerance into account, so you have to manually test many times to see if the result is satisfactory.

image
image1314×764 204 KB

And IMO filleting edges are one of the backbones of fast modelling, so those tools should have gotten yearly attention. Problem is that users learn not to rely on them, thus they stop complaining, and when they don’t complain they fall off the developers radar, which is a bad circle.

5 Likes
29

Already. Been. There.

I’m just saying that I don’t think we can expect much more at this price point but yeah, it does seem like McNeel is struggling a bit with several basic features… 2D export… fillets… blocks… can’t get much more foundational than that when it comes to CAD, I guess.

1 Like
30

Not being a wiseass, completely serious, which design software do you use that doesn’t have bugs? None that I’ve used over about 25 years in 3D CAD.

Kind of reminds me of the old racing saying, “fast, reliable, and cheap…choose two”

These are guys in an organization trying to make a good living while cost effectively producing a competitive product in an amazing tech space. High-performance, delivery to users, 100%-bug-free…choose two.

1 Like
31

Ironically the original long insulting rant didn’t get flagged but my comedically ironic summary of his message did, ahh well such is life within the human condition. My summary of Gusto’s post with the ironic sign off salutation:

I’ve been thinking about how you guys suck.

Yesterday I chose to go to a place that sucked, they reminded me of you the ways they suck and the ways you suck similarly, funny!

Anyway the point is you suck.

Best Regards.

32

Personally twice now I’ve bought Rhino for the awesome things that it can do, that are far more powerful than fillets, 2D export, and blocks. That’s why my metal tool box has many tools in it, so does my CAD toolbox, depending on what I’m trying to accomplish I go back and forth between Solidworks, Rhino, Blender, Illustrator, AutoCAD/Draftsight.

Ha I just had a funny vision of you screwing in a screw with the tip of your hand saw and heckling the engineers at ACME Hand Saw Corp. for stripping out your screw heads for so many years, what’s wrong with them?!

33

RH-61925 is fixed in the latest Rhino 7 Service Release Candidate

1 Like
34

RH-62591 is fixed in the latest Rhino 7 Service Release Candidate

35

yes exactly what happened to me. i relied on the fact that rhino was ok modelling far from origin but the gumball position was off (it should be in the center of bounding box but bounding box is calculated way off) so my whole model got messy and misaligned and i had to remake it leaving really uncertain feeling in me what i had omitted to fix. And there are tons of other things in rhino which makes me doubt everything because i cannot rely on basic things. Reminds me of company behind Scia FEA software which realeses new features too often but there are huge problems with calculation results and people use it to calculate structures thus lives depend on it. I remember when i used rhino to calculate area according to material use so i could tell client how much pain he should buy, Rhino failed also in this simple job.

36

RH-44145 is fixed in the latest WIP