Box edit issue

[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