Box edit issue

I m using box edit a lot, both for quick edits and verification.
In V6, I often find that I select an object and the values in box edit are wrong, I escape and re-select until I get the correct readings, but it defeats the purpose.

Also, on another occasion, I modify the X value and other values change as well.
I know you will request of example or photo or video but its a little hard to reproduce.
Has anybody else noticed this behavior? I have tested in different workstations.

I have had the issue where selecting an object with box edit isn’t giving me the correct dimensions. It happens to me in both Rhino 5 and 6.
In this simple case it happened when I had multiple objects selected then went to just having 1 single object selected. But as you can see from the image the bounding box shows my previous selection. This happens sometimes even when I hit escape in between to deselect everything. Both on my work computer (R5) and home computer (R6).

There’s something going on there, yes. I’ll check and report…

I can confirm.
It happens that BoxEdit gives me incorrect reading or remembers the last output.
I have to deselect once or twice, apply changes still double checking manually.

Hi Wim, All,

Ok, you all brace yourselves, go and get your coffee first, because my morning rants starts here…

Boxedit continues to not work properly, and it seems like every time a user brings it up we get the same answer: " we are looking into it"








I’m starting to think that no one in McNeel cares at all about this tool.

Let me re-iterate what BoxEdit should do:

  • You select something
  • Boxedit immediately gives you size and position of its bounding box
  • You can numerically edit the site, position, rotation of that box.
  • You can also enter dimensional values for size in alternative units
  • XYZ size, position and rotation values have a stepover/increment field with a default value. You can use the up and down values or change that step over numerically and then use it
  • Input fields are also output fields, so you can numerically or via increment steps overwrite them
  • The BoxEdit has a reference pivot point
  • The values are based or Cplane or World orientation
  • The values are based as a cumulative selection of multiple objects, or per-object (“transform objects individually”)
  • All the values above like step over, orientation, and all the other ones must be discretely/individually remembered for future transformations.
  • Values must always be true. Unlike this:

BoxEdit has ONE JOB, and a very easy one.

I said it before and I’ll say it again: BoxEdit performance, reliability, behavior and experience is an absolute shitshow and I find it really depressing that no one at McNeel gives a damn about it.

This is extremely easy to fix if you just would have a basic level of care for a tool that’s extremely important for many of us, and a tool that if it does not do its ONE JOB the consequences can be extremely costly (metal CNC is expensive, especially tooling releases, like many multiplies of the cost of a seat of rhino or an operators month salary, this is serious stuff). We can’t have a model edited numerically end up with wrong dimensions. This is the whole point of CAD guys. This HAS to work. Every god damn single time.

What you all have shown at McNeel with the continued tragedy of what a shitty job this basic tools does is one thing: You don’t care enough about your own work, or ours. That needs to change.

It only takes probably a few hours, or a day or two tops, of a single developer + designer with basic level of craftsmanship and care to fix this simple tool completely.

3 questions:

  1. What are you going to do to fix this shitshow of a tool?
  2. Who is going to do it?
  3. When will it get done?

As you can imagine seeing developers working on new stuff when some of the most fundamental and basic tools of a shipping product are getting zero proper attention is really frustrating. Maybe this tool got lots of distracted, careless, bug-fix pothole-patching attention, but this has gotten so far zero proper attention IMO, and the results are undeniable about it.

I think it’s cool to play with new nerd tools, etc. But come on McNeel team, check all the basic boxes first. Including Boxedit. Stop shipping crap. This tools (and a few others, but I’ll stop here for today) is total crap. This is not you. You can do better. You must do better.

I’d like to hear an answer about this, and why do you have a working culture that even lets you get to this.

/end of Rant.

Gustavo

4 Likes

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.
-wim

Thanks for looking into to this @wim.
I know McNeel cares. And am confident we’ll see improvements to this issue as well as others that may come up along the long path of adaptation and new features.

I want to thank everybody for checking and reporting back on this.
Many times I want to report an issue but I get reluctant cause I dont want to sound like crying wolf.

I m sure Mcneel will put some weight on it now.
Keep up the good work!

1 Like

Second post in Gustojunk’s list was mine, five SRs ago: I was happy with the fix that McNeel subsequently applied.

Jeremy

Seriously, I could not use rhino without BoxEdit, I would be an angry homer. Back when I first started with rhino 2009? I was struggling to use till I installed BoxEdit.
BE is a significantly important tool, especially for highly technical designs where absolute accuracy & ease of placement/moving/resizing is required.

When boxedit is getting some maintenance attention a wish-list item I would like is an additional button “Apply to duplicate” I think this is more ergonomic than the checkbox “copy objects” because don’t have to scroll down to check it then scroll back up & often I forget it is checked which is a bugger with a group of items. or maybe move the “copy objects” CheckBox close to the apply button.

cheers