Problem with dimension lines after latest update

Rhino 6.11 was the last version that didn’t behave like Rhino 5 - link in PM

Any changes to factory-default toolbars will be lost in an uninstall. These should be saved with a new name. Preferences and options survive an uninstall but it’s always a good idea to keep a backup (using the OptionsExport command). How are your macros defined?

1 Like

Hi Djhg,
Sorry again for the issue. We sided with the Rhino 5 behavior since users that upgraded to v6 were complaining about the line, while orphaning users like you that adopted the newer Rhino 6 (sr0 to sr11) behavior. Obviously, Rhino can not make everyone happy until this control is offered.

Control for the Dimension Line When Arrows Are Placed on Outside in Rhino 7 is on the tracker item RH-50656. I will let you know more when it has implemented, and I hope it will be sooner.

When this is available, you can download and install the WIP of Rhino 7 to have control over the line.

But for now, try and download Rhino 6 sr11 from here.
Let me know if it works for you.
You will probably need to uninstall Rhino if you have sr12 installed.

And if you worried about loosing anything your have customized, reference @wim’s suggestions above.

Sincerely,
Mary Ann Fugier

As per the Rhino video tutorial for creating mx and my for mirroring across those axes. Will they survive an install?

This is an important issue. It’s a basic requirement for any dimensioning for it NOT to work only as it has for recent months. No line between hash marks for any dimension less than 6’? How could this possibly be an advantage? No professional in the construction industry, in my long experience, would require that. Until it’s fixed, those of us requiring typical architectural construction technical drawing standards are labouring with an out of date version. Please provide a fix.

The fix is already in Rhino 7 wip. Any user that has Rhino 6, can download and use the Serengetti (work in progress) release of the next version of Rhino.

As I explained earlier in this thread, this was a regression from Rhino 5 and many users were telling us that it was not working for them. These Rhino 5 users were updating to Rhino 6 and were expecting the same behavior as Rhino 5. It took a few releases for this to be addressed, but it was eventually rolled back to work like it did in Rhino 5.

The only sensibly option moving forward was to make Rhino offer the control of the dimension line between the arrow/tick. The user needed the power to decide in the documents, even having one file do the line and another not.

I believe the Rhino 7 SR0 2019-5-28 wip contains the control you are looking for. I just tested the fix on Friday. You can run Rhino 6 and Rhino 7 WIP side-by-side without issue. (if it is not in the public build, it will be there soon.)

You should be able to combine these three setting in the Annotation style under Text and Arrows to get any behavior that you are looking for.

If not, let us know:

  • what you are doing
  • what happens
  • and what you expected to happen.
  • Send a file that we can work with as well.

Sincerely,
Mary Ann Fugier
McNeel Technical Support and Training
Seattle, WA

Well the problem is when you upgrade to a different main version, you expect some changes. You do not expect such changes (making things worse for a lot of people and screwing up projects you’re working on) in service updates.

Unfortunately the company I’m working for won’t upgrade to Rhino 7 anytime soon (running the free WIP version is only a temporary solution) so I’m either stuck with an outdated Rhino 6 or having to draw the missing lines myself which is of course not ideal for obvious reasons.

Thankyou Mary, I understood that from earlier in this thread.

Applauding your desire to serve the user base, and with all respect to the challenge of parsing the abundance of input you must receive (I can’t imagine): I’d like to as gently as possible - but assertively and confidently - suggest that your team may need a more broadly experienced set of technical drafting minds determining which input to follow than was involved with implementing that decision. No professional environment I have been in would accept the gap-laden dimensioning in the drawing I posted above, but R6 couldn’t do it any other way.

From what I see in your recent note above, a component of the issue may still be unaddressed: that of autmoating the behaviour of a dimension based on the threshold distance below which the arrows or text switch to the outside of a dimension.

If the text doesn’t fit between the hashmarks, it’s essentail for professional dimensioning that the text place itself automatically a) intially only as far beyond a hashmarks as required to clear it, and that it b) stay where a user places it if the user overrides that by dragging. Neither a) nor b) is the case with Rhino. Please see this post: Dimension Text Placement when outside Dimension Line

I haven’t been able to reproduce b). When a) gets implemented (RH-53019), please report cases where moving dimension text doesn’t stick.
-w

1 Like

All of them. It will stay for a session, but usually: close and open a project and they go back to the default (too far) distance.

Hi @djhg,
Please send a file and a procedure to duplicate the issue.
Again, this is a good check list for bug submission:

Thanks for your help.
Sincerely,
Mary Ann Fugier
McNeel Technical Support and Training
Seattle, WA

Is that post for this thread, Mary?
It’s already been reported as a bug by the Rhino team
I contacted phone help moment ago about this issue though, and it’s urgent to discover how to handle it, thanks.:

I would like to post that because the issue originally posted on this thread won’t be fixed until R7, I remain on SR11, putting up with a host of bugs, some of the most serious of which are these:

I need to reiterate - in line with the discourse on that post about prioritizing fixes, that having to manually add dimensions less than 6’ is unfeasible when my projects have scores - one has hundreds - of such dimensions. Architecture or Interior design or set design is of a scale where the issue isn’t acceptable.

If this won’t be fixed, can you suggest a workaround? If I change units to inches should the issue then only be present with dimensions less than 6 inches? ( I can test it and see, but i’m not confident that the presence of yet another bug won’t obstruct the effectiveness of such experimentation.)

I’m there with you, still stuck with SR11, waiting for a miracle that I know won’t come. I would be more than happy if there was at least a global setting hidden somewhere in Advanced options that would allow me to change the behaviour to the pre-SR12 state. That wouldn’t affect any files, nor dimension styles. I don’t need control on individual dimension lines basis which is what’s implemented in V7 I assume. (And I will say it again - I consider changing something like this during a Service Update without an option to have it back a very unfortunate choice)

Hi Simon,
Is this the issue that you are referring to?

  • Rhino 6 sr0-sr11 the line would be drawn between the arrows if the text was placed on the outside.This was different then Rhino 5 and causing issue with compatibility for some customers who upgraded from Rhino 5 to Rhino 6.
  • Rhino 5 and Rhino 6 sr12-srx now have the same behavior. The arrows are not drawn between the extension lines when the text is forced on the out side.
  • Rhino 7 WIP give you control over whether the line is drawn or not between the extension lines. This is both in the Annotation style and can be have overrides set per dimension in the Object Properties.

This is not correct. Control is both in the Annotation style and can be have overrides set per dimension in the Object Properties.
To make it work like Rhino 6.11, uncheck this option under Arrow in the annotation style:

See the attached simple file in Rhino 7. I have create two simple Annoation styles: one that draws the line and one that does not:

You can install Rhino 7 side-by-side with Rhino 6. It would good to find out now in the WIP stage if it is working for you. Currently default file format that Rhino 7 WIP save is a Rhino 6 file.
image

So if we can get you using the Rhino 7 wip , you will not only have the control you need, but you will be up to date.

Let me know if I missed or made an incorrect assumption here.
If you are still having problems, please send:

  1. simple file and image that will sown us what is wrong
  2. procedure that will illustrate the issue for us here.

Sincerely,
Mary Ann Fugier
McNeel Technical Support and Training
Seattle, WA

Hi Mary,
yes, that’s exactly what I meant, sorry if I wasn’t clear.

What I was saying is that I do not necessarily need this level of control, a global switch not tied to annotation styles would be a sufficient dirty fix for Rhino 6 in my, and I assume most other peoples’ case. Of course having it implemented the way Rhino 7 does is the optimal way but I understand you do not want to make this change in Rhino 6 because it would introduce incompatibilities within different V6 versions and could screw up dim styles in existing files (but then again, the previous “bugfix” already did that).

By the way, I would still love to see an example where not having the dimension line between outside arrows while the text is set to be placed above the line is the required behaviour. All this time I have a suspicion this is only required when the text is in line with the dimension line and that that’s what some people complained about.

I will perhaps install Rhino 7 WIP if I have time for experimenting (which I usually don’t have at work) but as I said before, that’s not really a solution. I don’t know if and when my company switches to V7 (they would only do that if we can convince them it will make our work substantially easier, as was the case with V6 thanks to the upgraded rendered view and integrated raytracing for example) and until then I need to stay compatible with all my colleagues (if I save as Rhino 6, I assume the information about the dimension line setting is lost, even if I then open it in Rhino 7 or is it not?).

Hi Simon,
Thanks for the additional comments here.

The global switch back is complicated to make this late in the product life cycle and the behavior might be confusing to those that are used to the current behavior . However, we do understand some users that would welcome the global switch. The current plan is to push forward and make Rhino 7 WIP work well in all possible situations.

The way to do this is with an override on the dimension object. You will need to set the Arrow placement to the outside. The dimension line will not be drawn on the inside while the dimensions are on the outside. Since you would not want all the arrows on other dimensions to be on the outside, changing the style does make sense. (You may also make a style with this setting and set the one dimension to it.) See attached example file. Arrow example.3dm (118.9 KB)

True. The Fit Arrow setting will be restored in Rhino 6. But the line “Draw dimension line …” setting is lost when you open the model and save it in Rhino 6.

Let me know if this works for you.
Sincerely,
Mary Ann Fugier

Hi Mary,
thanks for the reply.

More confusing than changing the behavior between two service updates without warning and without a way to change it back? Especially if that switch would be turned off by default? Or even hidden in Advanced options? Ok, I get that you don’t want to add features (although I’d call it a bugfix) to Rhino 6 and want everyone to switch to Rhino 7 instead…

No, I think we misunderstand each other. I was trying to get to the core issue:

  1. As far as I know, this is how eg. Americans want it (Rhino 6 current behavior):
    dimensions01-correct

  2. This is NOT how they want it (Rhino 6 original behavior):
    dimensions01-wrong

  3. This is how eg. Europeans want it (Rhino 6 original behavior):
    dimensions02-correct

  4. This is NOT how they want it (Rhino 6 current behavior):
    dimensions02-wrong

Now, in my opinion, cases 2) and 4) is how nobody wants it. If I’m not right in this, I wanted to see a counter-example.

So what I was getting at is, whether the correct behavior for Rhino 6 shouldn’t really be that the visibility of the dimension line with outside arrows is conditioned by whether the text is set in line (-> not visible) or above the line (-> visible). That is my question.

Professionals in Architecture use number 3 whatever continent we’re on, unless we are dealing with tiny dimensions. To have it perform in any other way for any dimensions under 6’ is a serious limitation.

1 Like

I’m from America and #1 is not how we want it. :rofl:

Can you elaborate? Do you use the #3 option or some other combination? Or even something not shown here?