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 in the Boxedit tab will appear in 4-5 seconds !!!

I select another object with mouse , its selected immediately (yellow), then the Boxedit params will first change to zero in 4-5 seconds, then they change to the selected object’s params in another 4-5 seconds, thats 8-10 second added up !
Its really unresponsive, very annoying to work with, very slow, this is why I consider this as an error, not just something what needs some optimization. I guess the object lookup code is very bad, although 58 objects are not so many at all in my opinion. This is near unusable.

My machine is not so good not so bad AMD FX-9590 8 core CPU , 32GB RAM, 500 GB SSD drive, nVidia GTX 980ti video card.


PS: it is 64bit Windows 7, I forgot to mention

Box edit issue

Error or not, if its unusable (which it is) it needs to be fixed. :slight_smile:

// Rolf


Hi Rolf,

Yes I agree. We’ll see what is their next step. I saw your info. I’m also learning CAD just like you. I tried some programs, and it seems this Rhino is the good choice, probably one of the best. Although its not cheap, this is why I’m always being critical, this is not the 1st error I reported. They have to work for their money. But actually they do, no complaints, the support and the community is quite good.

PS: Congratuations for the Seven Magnificent, that is something you can be proud of :slight_smile:


I am. :slight_smile:

Regarding errors in the Serengeti, which is a WIP (Work In Progress, that is, not a final release), you really should expect bugs. Lots of bugs. You have decided to be a tester when you use the WIP version. Rhino 5 is the stable version.

WIP versions is only for the tough guys. Cough, cough. :slight_smile:

But it is very good that you do report bugs!. That’s why the WIP/test version is made available.

// Rolf

(Pascal Golay) #5

Hi Laci - I do not see this lag here with 125 block instances. I see a fraction of second delay - can you repeat this with a relatively simple file, or can you send us your test file -




Hi Pascal,

I donno how to send it because its full of linked blocks, and the linked file paths are absolute, so you will not be able to load it. This is another problem, file paths should be relative to the project path in my opinion.
But I send it anyway, and when it complains of missing files you need to choose them one by one, it will take some times.



Hi Pascal,

It says :
"We’re sorry, but your email message to [“”] (titled File Uploaded ( by didn’t work.

None of the destination email addresses are recognized. Please make sure that you are sending to the correct email address provided by staff."

They don’t like your email address.
Would you please give me another one.

(Wim Dekeyser) #8

Did you use
The recipient eMail address there is So you only need to make sure that your own address is valid.
In the comments area refer to this discussion.


Thanks, its been sent.

(Pascal Golay) #10

Hi Laci - I don’t know if this can be improved or not - your objects are somewhat complex and they are blocks, which adds another level of complication. It’s about the same on my machine, 2-3 seconds, very roughly, between selection and BoxEdit getting hold of them. If I explode the blocks it’s perhaps 25% faster. I notice that selection is quicker if BoxEdit is not on top. I don’t know that any of this is wrong, exactly- there are a lot of objects to process by BoxEdit though perhaps it can be tuned up, I’ve added an item with your file(s) for the developer to look at.



(Gustavo Fontana) #11

Hi Pascal, it feels slower than in V5. Just me? also teh numbers don’t update properly sometimes.

(Pascal Golay) #12

Hi Gustavo, Laci - It is possible- these are all new style dialogs in V6, there may be some more tuning possible. I’ll do some comparisons…

Removing blocks from the problem, it does appear that V5 is somewhat faster to react in BoxEdit with the same (fairly complex) file. @dale if you open the file linked to the BoxEdit bug I posted, ExplodeBlock, Purge and Save As to V5, you can compare that much at least. I get maybe, very roughly, 30% or more slower-to-react action from V6’s dialog.


(Gustavo Fontana) #13

weird thing of this dialog/current implementation"

when you are on the X field, and press tab it jumps to ‘uniform’ instead of Y field

also in in increments, if your file is in mm and you type 1", it turn it in to a number 10 (sometimes, some other times it leaves the 1" in the field but it makes 10mm increments!). Here’s a clip showing teh 1" bug + uniform not making any uriform changes:

I can type in that X field 110.677+1, I can also type 1", but not 110.677+1"

when I select a subObject, I can’t use it. And I don;t have a good way to make numerical/explicit scaling using gumball either as I already discussed. So this shoudl be considered as an alternative option (once fixed).

I can check uniform for XYZ, but no way to make uniform XY, XZ, yZ (the only ones I ever want). Ihave absolutely no idea what this “options>uniform” do:

The whole thing is a bit of a disaster right now, very fragile and not ready to work numerically, proportionally, with additions, and/or multiple units. In needs some love IMO.



Hi all,

You forget something what I mentioned earlier.
The delay is exactly 4 times longer if there are 4 visible views (top,left,perspective,whatever), than if only one view, for example only top. This is the sign of a theoretical mistake. The lookup time of the object must not depend of the number of views, because it has only one property of each, one y size and one x position or whatever. I think its in a loop of views and the same property lookup will be repeated 4 times, and thats not good. I can’t imagine any good explanation of this symptom. Its a bug for sure, in my opinion.


Yeah this is definitely true. I used v5 a lot. It doesn’t not goes with lighning speed, but its usable, I never reported it as slow and unusable, though I have had some much bigger projects than this one.
Thank you Pascal for investigating this, I think its very important for those who want to use Rhino for engineering tasks. I know there is SolidWorks and things like that, but sorry to say I like Rhino, I can’t tell you why. I want Rhino fixed if possible.

(Brian Gillespie) #16

RH-38790 is fixed in the latest WIP


Hi Brian,

I donno what is RH-38790, but the boxedit speed is now much worse than earlier.

I tested with this WIP:
6.0.17116.6371, 4/26/2017

Earlier (in the top of this thread) when you had a selected part and you clicked on an other one, it was 4 seconds to deselect the part (zeroed boxedit parameters) and other 4 seconds to select the new part, that was only 8 seconds. Unusable but only 8. Now its about 13-14 seconds added up. The file is exactly the same, nothing has changed in it.

This is the case when you have 4 views open. If you zoom into one view the time will be much-much less, it will be about 2 seconds only. So the time strongly depends on the number of views.
And I think this is the proof of the error. A view should only be a visual representation. The Boxedit data refreshing time must not depend on the number of views.

Does it refresh the views so slowly (make the selected yellow) or what could happen ? Is the process sequetial ? Can’t you run a new thread to refresh Boxedit parallel in the same time ? Or if it must be sequential, can’t you start refreshing Boxedit data first ?

Today a guy had a question in the forum, how good Rhino is for mechanical engineering tasks, can it replace SolidWorks. I haven’t answered, but of course Rhino6 WIP is totally unusable to that kind of thing at the moment, its much worse that Rhino5 was earlier. I used Rhino5 + RhinoCAM even to manufacture things, it wasn’t very king, but it was usable. Parameter editing in Boxedit is a vital thing when you edit mechanical parts, simply you can’t edit them by hand, only by numbers.



Hi Brian,

I have to report that this error (the topic started with) has been fixed in WIP 6.0.17172.1151, 6/21/2017
Thank you very much, I like Rhino again. This function was very important to me.
Now the boxedit properties do refresh in less than 1 second, when I select/reselect an object. Good job !