Hello!
In the last years, the phrase “small annoying things” has been used in the context of numerous other 3d applications I came across. Allow me to use it here, too, to draw your attention to some little buggers that should be no big problem to fix (I hope).
I like to use the Gumball, however.
When the Gumball is set to “Align to Object” mode (which is desirable since it auto-aligns the GB to the object) the selected VisualArq parts (doors, windows, …) have their origin/GB in the world origin instead of some meaningful position on the object itself. That has the disadvantage that when orbiting the viewport, the object falls out of sight easily.
Please avoid modal dialogs. They are never necessary (I mentioned this already, some time ago).
Please make every and all dialogs resizable! That’s good style, and costs nothing.
That’s it for now. More to come…
Thanks!
Best regards
Eugen
The Gumball should work fine on VisualARQ objects when it is set to “Align to Object” mode. Which Rhino version are you using? Does it work with other Rhino geometry (i.e.a Box) ?
Modal dialogs are necessary sometimes. For example if the Object Styles dialog wasn’t Modal, it would mean that the full model should update at any change. And this would make the modeling performance very slow. Rhino has also Modal dialogs when necessary (i.e Options dialog, Loft Options dialog…). However we will review those dialogs that could be non Modal in future versions.
Any particular dialog you wish to resize?
Making the Space bar work as the OK button is not clear. Some dialogs have text fields and it might be confusing that the Space bar works as the OK button, which closes the dialog.
Gumball:
Here is a small testscene (part of a study project I’m on) - after opening it, please select the window in the middle (a curtain wall object actually) , set the Gumball to “Align to Object” (if not already), and rotate the viewport.
Since the windows’s origin point is far off (at the scene origin), orbiting the vp will move it offscreen.
I have not tested all VA objects, but I know for sure that stairs have the same problem.
Just checked: doors and windows do not show that behavior.
Modal dialogs:
I know Rhino has modal dialogs, but that does not mean it is good style… ; )
Non-modal dialogs can either have some auto-update mechanism, or they can trigger scene changes only after ‘Apply’ is clicked. The latter is preferable in this case, for performance reasons (as you mentioned).
So, as long as nobody clicks ‘Apply’, nothing happens, and you can have that dialog window floating around and happily continue working with the rest of the UI.
Does this make sense?
SPACE = Ok:
That would be the Rhino way, right? I you invoke any command and press SPACE, it’s always ENTER. In VA, as long as you do not set focus in some text input field, there could be no contradiction, right?
What was the little dialog box that brought me to the idea… sorry, can’t find it at the moment. I tell you when I stumble across it again.
Gumball:
You are right, the Gumball doesn’t align well on some VisualARQ objects (Curtain walls, Railings, Stairs and Roofs) when it is set to Align to Object. (I had just tested it with the objects it works). I hope we can fix this soon.
Modal dialogs.
All you say makes sense. We are going to make the Insertion dialogs be non-modal in the next VisualARQ version. We will study if we can do the same with the other dialogs.
Space = OK.
All VisualARQ commands actually work as Rhino’s. So SPACE key works as ENTER key in the command line. And in some dialogs like the Styles dialog or Object properties if you jump from button to button with the TAB key (or the keyboard Arrows), when you are on the OK button, the Space performs as the ENTER.
I think I like this one more to be honest, because as I discovered, the curve doesn’t have to touch the slab in question (like the original image suggests).
Well in fact it has. The slab is created on the curve, according to three different vertical alignment options. But the icon is just a representation, it doesn’t need to be exactly as the command works. Choose the one you prefer!
I think we are talking about different things, for example this was my workflow: I have 4 floors with same slabs, but if it turns out that I have to change something on one floor slab and translate it to others, I just create one curve that fixes the problem and it doesn’t have to touch the first slab (be on the same level with it), what I noticed that in top view they should look like they coincide. So no matter if the curve is on the “first floor”, other floors will be able to pick that up.
I hope I explained it better this time (looking back at my first message it was quite confusing).
All right, I get it. You are talking about the command to add a boundary to a slab (vaSlabAdd), (not the one to create Slabs from curves). In that case you are right, the curve used for the addition doesn’t need to be on the same elevation as the slab.
Best,
Got another wish: those triangular edit points are rather small - I already had problems selecting them when they were amidst other lines or objects. Also, they are quite far offset, I think.
Since people will have different tastes: maybe add a preference in the VA Options?
Thanks!
Eugen
Just noticed that the handle size is indeed coupled to the Rhino Control Point Size parameter in Rhino Options > View > Display Mode > Wireframe.
However, the VA (triangular) point size only starts to increase above 5 pixels, when the Rhino points are already becoming too big.
Best regards
Eugen
? You can just edit the button and add this image.
