Top Toolbar Pallete Tool Limits?

Just noticing in most of the defined tools (toolbars) there are more tools than display on the toolbar when the tab is selected. For example, on my machine Surface Tools ends at Adjust surface end bulge, while in the customize dialog it shows Divide Along Creases, Remove Multiple Knots and several others after Adjust surface end bulge.

Is there some hard coded limit to how many tools will display? There’s quite a few of them that I’d like to add additional items too, but they won’t display if I do.

If that is the case it’d be nice to be able to create additional tabs or something to get more stuff accessible without needing to completely pick and choose on a per palette basis what is and isn’t there due to a limit on the number than will actually display.

Also, what’s the difference between primary palettes, Modified Palettes and Secondary Palettes?

And finally Why is the top one called Main + Standard? Does it have any special significance? Is it possible to change the default toolbar to one of my own choosing or creation?

First, some definitions of the terms I will use. In OS X, Apple calls the area at the top of a window where the window title and close, maximize, and minimize buttons live the toolbar. It contains the sidebar show/hide buttons, the Ortho button and so forth. I call a collection of Rhino tool buttons a tool palette which can either be floating, in the left sidebar, or in the modeling window under the OS X toolbar.

I believe you are describing the ribbon bar. In the current WIP release, the ribbon bar is restricted to a single row of tool buttons. If your window is narrow and your tool buttons are large, then there will not be enough space to display all the buttons. You can either make your modeling window wider or make the tool buttons smaller in Preferences > Tool Palette.

In the next WIP release, the ribbon bar will grow vertically to fit all the tool buttons for each tab. This means that the rest of the window will shrink or grow as you select different tabs in the ribbon bar, which will be a different annoyance.

There are more than 100 tool palettes. The categories put the tool palettes you are most likely to use or modify at the top of the list.

In Windows Rhino V4, there were two palettes in the default configuration, Main, and Standard, in different areas of the modeling window. You can still find those two palettes in the Secondary palettes category. Rhino for Mac provides one default area for tool buttons, so it combines the tool buttons from both the Main and the Standard palettes into a single palette.

I believe you are describing the ribbon bar. In the current WIP release, the ribbon bar is restricted to a single row of tool buttons. If your window is narrow and your tool buttons are large, then there will not be enough space to display all the buttons. You can either make your modeling window wider or make the tool buttons smaller in Preferences > Tool Palette.

In the next WIP release, the ribbon bar will grow vertically to fit all the tool buttons for each tab. This means that the rest of the window will shrink or grow as you select different tabs in the ribbon bar, which will be a different annoyance.

Odd, as my toolbar buttons are the small size, and I have a 1920x1200 res on the display with the rhino window maximized… There’s plenty of room for additional buttons in a single row, so I’d think they would show.

I see the issue with Surface Tools in the current WIP release. This will be fixed in the next WIP release.

Thankee. There’s a couple others I’ve noticed as well, but can’t remember off the top of my head which ones.

it’d be sweet to be able to load up a fair number of them, and to be able to keep constantly used items on most of the tool palettes. Over time I’ll learn the command line variants, but for now it helps to see the icons as there’s so many tools, and I’m newish to Rhino that the visual cue helps remind me they exist.

On a side note, I can’t thank you folks enough for porting this to the Mac platform. While I have blender, (and it’s really astounding for an open source project as to it’s abilities, I find new stuff in the rendering department on a daily basis, and it’s multi pass rendering abilities and composting stuff are even more amazing to be in an open source tool), I just could never get my head around mesh modeling. I’m a cad type by nature, and having a powerful nurbs based solid modeler on the mac platform that isn’t a “joke” port means a lot.

I gave up on AutoCad for mac in hours as while it’s drafting stuff is ok, it just falls apart at the seams when you start tossing any kinds of flowing surface trims at it. I used a nurbs sheet as a cutter on a solid and chamfered one of the edges afterwards and from that point on it was just excruciatingly slow for every operation. Typing chars into the command line was absurd. You’d type a word, walk away for a couple minutes and watch the charcters pop into the command line one at a time every 20 seconds or so.

So it’s nice to see a quality modeler take the mac platform seriously rather than as an afterthought. I realize you have quite a ways to go (plugins, which from your .net based variant on the windows front means complete recoding across the board, which is ginormous undertaking), lack of internal step mode debugger for scripting and various other items missing would give many pause, however, the basic toolset is pretty much there, and to it’s credit it hasn’t crashed once.

As a alpha and beta test for electric image for years back in the day, I’d gotten used to the notion of saving a derivative version of a file every few operations just in case it puked so I’d have before and afters to send in for examination, and crashes were not just occasional, but many times a day, every day for months.

I’m pleased to say I have had anything really bring Rhino Mac to it’s knees, and thus far haven’t had a single crash, which is very impressive. I’ve had a few issues with OBJ exports and blender puking on them, but have been able to backtrack a few steps and recover. (in those cases tooling through the OBJ file shows coordinates with really bizarre values with large exponents, not sure if this is the culprit or not having not spent a lot of time under the hood in OBJ land. I just picked that as it handles named groups and objects which STL does not).

I have noticed the (apparently already reported) flakyness with naming groups and the missing group dialog and some other issues, but over all, again, kudos.

I’m sure a lot of my issues I’m seeing at this point are probably just as much my not understanding the “rhino way” in terms of how things flow and the appopriate approach to a given modeling puzzle, but that will come in time (and hopefully with more beefy documentation).

I picked up a copy of modeling Jewelry with blender (written back in the 4.0 days) and it’s actually helped a great deal. There’s only so much you can noodle out of a blurry low res youtube video where the person talks about one operation while hitting 5 different tools you can’t make out on a totally different version of the app on a totally different platform where the toolbars aren’t even vaguely similar to what you see on screen. At least with the book I could find the tools based off the icons and that expedited the learning curve markedly.

I haven’t really even scratched the surface yet, have done absolutely zero with rendering and many of the drafting type tools in Rhino and have only barely scratched the surface with scripting. managed to get atom up and running and have been following those discussions. Plenty else to learn before I’ll need to dive into that stuff, and as a CG friend of mine said at a Siggraph keynote she gave some years ago on her experience with a 3rd party parallel process rendering board for after effects said, “as far as I can tell the primary purpose for any early adopter of a bleeding edge technology seems to be to provide a softer landing spot for the next batch of fools that follow them off the cliff”. So I’ll let you folks get the whole scripting thing a bit further along before I dive into that.

At any rate, just wanted to say thanks for all you folk’s hard work and that it IS appreciated, at least by one who’s lived though one modeler initial development cycle already.

1 Like