BoxEdit Bug


Its been quite some time since I am using Rhino 6 and it seems that this bug persists.
I am having a solid, all planar (not skewed or anything like that) and when selecting it … the BoxEdit feature shows totally different sizes than it actually are.
It is showing as having a 7006mm - in X field… although my solid’s longer edge is on Y
Still, measuring this edge with Length command it is actually 1994mm…
if I open a new session of Rhino and paste this solid in there, BoxEdit shows correct dimensions.
If I close the file and reopen, then it shows correct dimensions.

This is not the first time it happens and this was noticed on other stations as well.

Can this be looked upon? The thing is that although this feature worked flawlessly on Rhino5 it seems that in Rhino6 sometimes its faulty.

I am running Rhinoceros Version 6R14

Thank you,


BoxEdit continues to be a disaster. It should be a tool that works perfectly every time. The implications of having a tool to make you model something of the wrong size could be absolutely catastrophic from a project/financial/professional POV

We have mentioned it before many times. I even posted a summary of many previous here:

Still, no one cares apparently. Last week I also had a wrong readings with it in V7. I don’t even bother to report it anymore because it’s going to deaf ears. This is really sad.




This particular issue is now filed as RH-49108 .

@gustojunk, thanks for taking the time to report your findings - I’ll make sure to go through this.

This was the reply by @wim for the pervious thread regarding this issue.

Yes, I appreciate that @wim bugged one issue. What I don’t appreciate is that such a straight forward tool ships with so many issues, and they continue to exist. I find it unacceptable.

Another issue BTW: the tools seems to locate it pivot point to min,min,min location for X,YZ. Some other times to center,center,min. None of those situations are related to what what the last used pivot location (which should be the default).

1 Like

Why not public?

This can be done only by McNeel team @Fred_C

Hello - can you please export this object and post the file if it also shows the problem?


Hi Pascal,

As mentioned if the solid is placed in a different file, or the file itself is closed and reopened, the BoxEdit tool shows correct information. My thoughts are that that this issue is not related to the file or the modeled solid, but something that seems to happen randomly with the tool.

I checked some crazy idea that occurred to me and it seems to be useful information The values shown (x=7006, y=14, z=763) are the coordinates of a point in space which relates to a corner of the solid. So instead of showing the solid’s overall dimensions it seems that BoxEdit tool was giving a positioning point for the solid. It might be that from time to time it picks up coordinates of a positioning point instead of writing down overall sizes. I will mention that this solid was made some time ago and it belongs to a bigger file that has more than 2000 items in it. I can say that the values shown by the BoxEdit tool are not related to last command or a command that has been executed during the modeling session (like Move to that specific location or Rectangle used to define the solid item). Hope this helps.

Part is attached to this message.

BoxEdit.3dm (92.3 KB)

Thank you,


@ajarindia Thank you. I know that.

I see… that can’t be good - thanks for that detail.

Hmm but, @tiberiu_matala - looking back at your images, you’re showing a BoxEdit that is scrolled up so Size is not visible and the numbers there are for Position (label is out of view), and are as expected.


Then what you’re trying to say here. I didn’t get you.


The question was not directed to you, but you were alerted because I grabbed the link to the You Track item from your message to Gustavo. I’ve removed the link, but the question remains; Why is the referenced item not public. No response needed from you.

Thank you

Hmm… I think you are right on this one… and there is a big chance that I was mistaken, that within the BoxEdit panel I was looking at Position and not at the Size.
My sincere apologies Pascal, I definitely need to pay more attention.

Thank you


Hi RMA team,

Like I’ve been saying for years now: this tool is a clusterfuck. Also extremely slow with multiple objects.

boxedit_still_a_mess_gf_190724.3dm (2.7 MB)

Hi @gustojunk,

I’m sorry but I don’t think what you are describing is the disaster that your colourful language implies. It seems pretty clear that boxedit displays a zero to indicate that the selected items are different sizes. Would a list of those sizes be any more practical? What are you going to do with it? What if you have hundreds of items selected? How much bigger is the boxedit panel going to be to accommodate all the lists? - it already obscures a sizeable portion of the screen…

This is an editing tool. You can still set all your cylinders to be the same size by typing in X, Y & Z values once. You can still scale them. What are you missing out on?

I have reported bugs in Boxedit in the past. The Rhino team fixed them. I find it to be such a useful tool I keep the panel open all the time on my large monitor (but not on my laptop!). I’m intrigued that our experiences are so different.


I’ve reached colorful-level only in this tool, since it’s a disaster.

in Rhino V5 when the input varies it used to show this:

the triangle in front of the numeric values was a way to tell the user that something is up.

Totally inconsistent with other tools when they need to tell you that the values is not the same for multiple objects, for example if all these cylinders have several names, they use the term ‘(varies)’

The ‘Δ 0.000’ wasn’t as good or elegant as ‘(varies)’ but at least it was trying to tell you that something is up. By saying "0.000’ the tools whose job is telling you a dimension of something it’s actually lying to you.

this is a ‘0.000’ value:

Zero is a number, an a very important one. let me explain why:

if I have 3 surfaces and I want to make use they are flat/planar/and coplanar to world Z I can select them and see that:

Now I want to show you how this tool can lie. I will move 2 points of one of these surfaces up 3mm…

when I select the three planes (with ‘transform objects individually’) checked I’m still told that their z value is 0 mm, instead of (varies):

I’ll do the same but with those two points moved up only 0.05mm, instead of 3mm, and now Rhino will tell you with confidence that something that you check for planarity is planar, when in fact isn’t:

So I think clusterfuck is an understatement about the state of this tool. It’s:

The biggest clusterfuck of carelessness and clusterfuckness of all Rhino tools at the moment, and probably in Rhino’s history

…especially considering the impact this has for costly downstream engineering mistakes in production/prototyping/RP.

I want professional tools for professional work. This isn’t it. Not even close. And it’s unacceptable. I stand by it.


Not clearly indicating different values (instead only saying “0.000”) is outright misleading and thus a serious mistake and, yes, unacceptable.

I don’t think the developer is proud of this one.

1 Like

Actually, just reporting this bug would have been fine.



1 Like

Hi Gustavo,

I agree with you: Delta or ‘varies’ would be better.

Again I agree: this is not good. Now you have given an explanation (and not just an expletive!) I understand your issue. But now you know that you can’t rely on this you have a workaround until it gets fixed: Unclick ‘transform objects individually’ and check that the Z size is zero instead…

Your lucid exposition above was enlightening. So, if you have time, could you elaborate on this too, because in my limited experience I struggle to see how it would happen? Has it happened to you? What was the circumstance? When a problem was identified, did you do a root cause analysis? What was the conclusion? What lessons were learnt and what workflow changes resulted?