Hi McNeel Team,
Bugs with Disclaimer: this is a real horror movie. A non-comedy of errors. A mistaken identity of a rough WIP with any level of production software:
Thanks goodness I only needed this to make some Holiday custom pint glasses, not for something actually important.
Do you want me to count all the bugs that I caught here in 4 minutes? or can you do that yourselves?
Please let me know if you need the offended file.
Love,
Gustavo
Use RhinoPDF instead of the Adobe PDF printer driver especially if you are trying to output PDFs that you want to edit later in another app
Ok Steve, good to know. Thx. What about all the scaling output issues?
Iām jumping around all over the place right now. I only saw the first part of your video and could tell right away that Rhino PDF would probably give you easier to work with results.
Iāll need to rewatch the video to figure out the scaling issues you mention and get back to you.
Steve I looked at this some more. The scaling problem happens only in File>Export as pdf/ai. Itās not happening in File>Print (sing a PDF print driver). And the preview of a page size in that File>Export dialog is whatās broken, but the output does come out at the correct scale.
I made this other video showing you that:
Iāve create a YT for the issue here and will see whatās up.
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.
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
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.
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
Iām an olā QA consultant. (thatās where I got that āyou tested only what you tested, nothing moreā. 
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. 
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ā¦
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
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.
// Rolf
