Box edit issue

[Yianni]

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.

[ra_mull (Ryan)]

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

[wim (Wim Dekeyser)]

@Yianni

Has anybody else noticed this behavior?

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

[Piotr]

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.

[gustojunk (Gustavo Fontana)]

Hi Wim, All,

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

@wim

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

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 spent a lot of money on Rhino6, here's why it's useless - it's a BoxEdit flaw

I’ve had Rhino6 for months now. I thought it would be better. Instead, I find that I still do my day-to-day work in Rhino 5. The reason is just one little thing that makes Rhino6 functionally useless to me. It’s about BoxEdit. I use it a lot, to reposition and resize things. I probably use BoxEdit once every 30 seconds. It’s my main tool. BoxEdit makes me work fast. I should mention too, I use a black background. Ok, so in Rhino 5, you’d select an object, it would highlight yellow. Say in BoxE…

Issues with Boxedit (in 6.5.18128)

Could boxedit get some love? Lots of issues: It is usually slow to reflect an object selection or change of object selection, sometimes it does not reflect it at all. Having selected two objects in the model, boxedit recognises only one item selected and dimensions reflected the single object (sometimes). Model selection highlighting disappears, possibly with a Rhino-originated (not user-originated) shift of focus to boxedit (boxedit window open, undocked, before selection(s) made). 4.When bo…

Clumsy Boxedit

Hi all, I have a project, it has 58 objects, closed polysurfaces, many of them defined as block. In the right side panel I put Properties, Layers and Boxedit tabs, because I prefer parameter edit (size, position) rather than moving things with mouse pointer, its much more precise and quick. At least it should be. But its not quick, this is why I report this as an error, its extremly slow. I select and object with mouse, it becomes selected immediately (changes to yellow), but the parameters i…

Slow performance with Boxedit Rhino 6.3.18078.21401

First time in Rhino 6 and I am currently facing some performance issues with a fresh windows machine and rhino 6 installation. When I select a tool, the tool point lags behind the mouse cursor slightly and when I have the boxedit tab visible it takes sometimes before any object get selected. Things only get slightly better when the boxedit tab is not active. This is my first time on Rhino6 and with default settings. I have a nvidia gtx 950 with latest nvidia drivers and enabling or disabling…

BoxEdit not working right

In current SR4 RC1 - setting the scale increment to anything other than 1 doesn’t work, the up/down arrows in the scale boxes don’t do anything (uniform or individually). I can’t input anything other than 0, 1, 2 etc. into the scale box if I try from the keyboard… Totally useless.

BoxEdit not updating block instances

Hi, BoxEdit does not seem to update when working with block instances. Any ideas?

Boxedit forgets setting after rhino close

A small niggle with boxedit. The checkbox for ‘Select copied objects’ reverts to unselect after rhino is restarted. I mostly use the ‘Copy objects’ with this enabled, makes easy array placement by setting increment & repeating clik-Enter

Box Edit - buggy in Rhino 6 beta

Just reporting a few bugs in the Box Edit panel dialogue in Rhino 6 beta (6.0.17339.11131, 5/12/2017). 1). The “increment” dialogue has a bug: Rhino 5 did not have little up/down arrows to change the increment value for parameters size and position of an object, but Rhino 6 does. Unfortunately, if you use these increment up/down arrows, you get a change in increment value that increases in order of magnitude each click, e.g. if initial increment value = 2; 1st click up you get value of 20, 2nd …

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

[wim (Wim Dekeyser)]

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

[ra_mull (Ryan)]

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.

[Yianni]

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!

[jeremy5 (Jeremy)]

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

Jeremy

[tonigau]

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

[jimditto]

Still a problem. I’ve got a box shape that’s 1’x1’x0.5". It’s showing that it’s 1.5’x1.5’x0.5’. Meanwhile, it’s not letting me adjust the size or scale by any increments lower than 1/4" (I want to change it by 1/8", nothing crazy.) Anyone else still having these issues?

[jeremy5 (Jeremy)]

@jimditto

Meanwhile, it’s not letting me adjust the size or scale by any increments lower than 1/4" (I want to change it by 1/8", nothing crazy.)

You need to adjust your display precision to allow 1/8" intervals instead of the standard 1/4" in the template you chose (this applies to all of Rhino, not just boxedit):

As for the box shape, upload your model and hopefully someone can figure out what’s happening.

Regards
Jeremy

[jimditto]

Thanks Jeremy. That seems to have solved both issues. I set it to 1’1-1/16". I guess I hadn’t had to change the setting since installing Rhino 6. Most of what I’ve been doing is modeling in feet and half feet, at most.

[sle7en]

I have a similar Box Edit Issue. If I’m not going crazy, I think I was able to do dynamic calculations with the Box Edit tool, and I can, yet more specifically it won’t compute the calculation and implement the change if I mix imperial and metric units, say for e.g. I want to shrink the objects length in the y-axis by 1/2" and I punch in the following calculation it won’t compute; XX'-XX"-.5

my units being in the feet-inch format. Is something awry with Box Edit?

Thank you and merry christmas!

[davidcockey]

It looks like BoxEdit has problems when explicit units are used for math in the dimensions. Presumably the input is not being parsed properly.
Version 7 (7.2.20343.11011, 12/8/2020)

[jeremy5 (Jeremy)]

I don’t see anything in the documentation (caveat: I haven’t read it all!) to suggest that calculation is a feature of the Boxedit entry boxes in R6 or R7. The calculator function that is documented is explicitly linked to the command line.

That said, it looks like you can do calculations in Boxedit if you have your units set to metric, or inches, but not feet-and-inches. And you can’t mix units. Until someone can point to something in the documentation that I’ve missed, I’m going to treat this as an undocumented effect and not trust it to calculate correctly…

But it would certainly be a great feature to have, @pascal

Jeremy

[gustojunk (Gustavo Fontana)]

The native BoxEdit of Rhino was one of my requests, since we used a lot the script that did this before. I don’t recall who had written that one. Probably Thomas A, Ryan Perry or David Rutten?

As a typical McNeel development I had to outline all the things it should have, this happened probably 15 years ago, if not earlier. The original spec included being able to input dimensions in any unit system as long as you identify any values that are not in the file units. Also calculations would be supported. Of course those two things did kind of happen, but not together. Then years later I think @dale included the option of combining calculations AND multi-units, still it was partially executed, never tested, never documented, which makes it very very confusing and something I still today cannot trust.

I had also asked originally for an option of displaying BoxEdit values in a user selected unit, independently fo the file units. This never seemed important enough for McNeel to prioritize.

I stop asking for useful features, all of the going back to the original spec because after almost 2 decades this team can really exhaust you, and I think that exhaustion might be mutual, so I gave up.

In the last few year the only thing I’ve been asking is that the tool is not broken, that it does not show wrong values and that if updates quickly. This also seems too much work apparently.

G

[sle7en]

It’s not necessarily the accuracy I’m worried about (working in AEC ±1/16" is good enough for me but I can see how it is different for others and yea, I have non-overlapping line/point OCD as well) but more so the finnicky nature of it all. I can almost swear that I can shorten/lengthen objects by just punching XX'-XX"±1 with the keypad. Now it doesn’t seem to be working, is it the latest rhino 6 update?

Rhino 6 SR32 2020-12-5 (Rhino 6, 6.32.20340.21001)