Release date?

Hi David-

Can you give me an example of this please? Or more than one, if you have the.

-thanks

-Pascal

I am not sure what you mean here…are you saying that the default front and right cplanes should have axis colors that correspond to world space directions? If so, what about custom, arbitrary cplanes, what should happen there? As it is there is one simple rule: each viewport has its own cplane and coordinates , unless the user specifies a W, are understood to be in local Cplane units and orientation. I am not at all convinced, if I understand your comment, that mixing World and local Cplanes will make anything easier for anyone, but I may be misinterpreting…

-Pascal

Having not used ‘proper’ CAD since my university days, I’m really enjoying using Rhino and am really impressed with its capability even in its beta guise. So much so, that it’s got more than enough functionality for me to use it without needing to have any other CAD software. I’ve recently started a company using CNC for rapid prototyping and small production runs. For me, my selfish priority would be having ‘blocks’ fully functional as it would really speed up my workflow, particularly for when I make changes in subcomponents. In my dream world, I’d also like RhinoCAM ready as soon as possible, so I could keep as much as possible in one machine!

You’re going to need to convince Mecsoft that they will sell enough units to make it worthwhile to completely re-write their software to run on Mac… That seems doubtful at the moment… However, as virtually no CAM runs on a Mac right now, they might be able to capitalize on the “pioneer” effect… I would think they would have a lot of success in the EDU market, but frankly not much elsewhere as very few people in industry seriously consider using a Mac.

–Mitch

Hi Pascal,

Several points of clarification are probably needed to better explain my dissatisfaction with Snaps:

1. Cumbersome/Maddening:
When “creating” new geometry (in a freeform design fashion), one does not always know precisely what part of a geometry one would like to snap to in advance. One needs to continually be turning on/off various snaps (which requires a ton of mousing away from the geometry to the menu and back) to pre-visualize what using this snap might look like. It would be great if Rhino “sensed” several important aspects of the geometry one were trying to snap to (such as end, midpoint, center, intersection, and maybe others) suggesting it as a possible snap point while still drawing. I think of Adobe Illustrator a little bit here.

SmartTrack, sort of does this, but its continual display of dashed lines all over the Cplane, no matter where you are is generally so much information that it is useless.

2. Screen Navigation:
Nothing is a greater buzz-kill than lining up the snap that one wants, only to find that it is not enabled. Mouse off drawing to menu, select snap, mouse back to drawing, then recreate the visual result you originally wanted to create, but this time with accuracy.

4. Examples:
Frequently, when I try to move a point (lets say, on a surface) in one of the orthogonal four square views, I find it looked fine in that view, but when I go to perspective view I find the point-move snapped to something controlled by another four square view and is nowhere near where I want it. Because of this complexity, I’ve encountered a number of Rhino users who recommend drawing desired geometry anywhere, then moving it to the location they desire. This seems like a poor workaround. Yes, I realize the solution is possible with some magic combination of snaps and Ortho / Planar settings, but this seems like this could be far, far simpler.

3. Suggested/Desired Behavior:
A) Magnet suggestions might be nice, but should be an on/off toggle
B) Ideally, I would love if each Snap had a hotkey that could be pressed while drawing to activate it. This would prevent the endless “mousing-around” to find the magic combination that works. To me, no other solution is as powerful. However, I realize this might wreak havoc with entering dimensions. Maybe alpha keys could be isolated from numeric keys while drawing?
C) If one is drawing in an orthogonal CPlane, geometry should ALWAYS work ONLY in that CPlane, not in any others.
D) The use of the SHIFT key would be nice to constrain preset angular movement vs free movement.
E) Pet peeve: if OSnap is for Object Snap, why is it not GSnap for Grid Snap? I know of few people who snap to grid on a regular basis, other than beginners, and Snap seems a bit misapplied.

Does that help clarify things any?

Exactly.

Endemic to this discussion are McNeel’s goals for MacRhino. Does McNeel feel (as I do) that beginners will love MacRhino as an initial learning platform that leads to professional super-hero use? Or does McNeel feel that those who already have super-hero capes from WinRhino will be the target market and migrate over? If the former, some interface aspects of WinRhino (which are base on AutoCAD’s…ahem, “superb” interface skills, if I recall) require some thoughtful reconsideration—and this CPlane business is one of them (along with snaps, as I also mentioned above).

I hear your concerns about possibly mixing world and custom Cplane colors, but feel these concerns are worth re-evaluating slightly for one simple reason: anyone able to create a custom Cplane is WELL beyond a beginner user, clearly understanding the difference between a custom plane and a world plane. I, personally, think it would be a nice reminder to know that a custom CPlane is not in the world planes, since I, too, sometimes wonder why things look weird all of a sudden in a custom CPlane view. “Oh right… I did that!” is what finally dawns on me.

Regarding beginners, which I have a lot of experience teaching Rhino, I’ve encountered a number of new users who, once they’ve created a custom Cplane (usually by accident) can not figure out how to get back to the default Cplane. Their solution is to open a new document and paste all their work into it. (Incidentally, I count 26 Cplane tools, and missing from this list—which should be at the top for beginners—is Restore Default CPlanes)

My primary concern is with the Green and Red CPlane colors. Okay, if you don’t like the idea of world colors for the default CPlanes (Red, Green, and Blue) why not just change the world axes colors to something like Magenta, Cyan, and Blue? End of confusion. The fact that two of the world axes colors are IDENTICAL to the CPlane colors, regardless of viewing orientation, makes sense only to those who know what a CPlane is. However, very, very few beginners understand that CPlane is a Rhino convention that is not in any way related to the World planes. I don’t blame them a bit, largely because the CPlane in the perspective and top views align Green with Y and Red with X.

Go to Starbucks sometime and introduce a new user to Rhino to test my observation. Ask them why Z is green / and X is red (which is expected) in the Front view; and then why Y is red / and Z is green in the Right view without you explaining it! :smile:

Rhino does precisely this - just leave the most common ones on - you should seee an on-screen indication of which one is activated when you snap.

Use the “Alt” key to temporarily disable snaps, turn on “Project” to project a snap.

Rhino does precisely this. Shift will toggle ortho while it is held down.

–Mitch

I hear you, Mitch, and I’m glad the snaps work for you.

My position remains, though. Add to the mix the Planar and Ortho toggles (in various combinations of being on/off) and snapping becomes more complex than is needed, in my opinion, with lots of mousing involved for changes when things don’t work out as desired.

To be clear, I’m not suggesting that the snaps “don’t” work or “can’t” work as they are. I’m merely suggesting that they could work a whole lot more easily and intuitively—especially, it seems to me, if hotkeys could be dynamically used (as is the case in PowerCADD, who handle snaps better than any other program I’ve encountered). Seasoned Rhino users will possibly have deciphered the nuances required as things are (and I’m not convinced of this based on many conversations I’ve had with others about rhino snaps); however, the reality is that new users are often baffled by snaps/ortho/planar in their totality.

I realize the inherent difficulty of questioning existing methods to those intimately acquainted with existing software. Often it is what we have become (ab)used to that makes existing methods seem immutable. I’m as guilty as the rest in this! However, in the quest for new users, constant improvement (and McNeel has a very good track record here!) is rewarded in the marketplace. As such, there is value in always considering if better ways can be realized. And a valuable way to identify areas for improvement is if frustrations are sought, expressed, and given a degree of consideration without too much defending of the existing solutions. (Again, McNeel has a good record here, too). That’s really my main goal here. Just relaying reactions from teaching Rhino to over 100 students and my own personal observations.

Case in point is that when I proposed The Gumball to Bob several years ago, he directed me to McNeel’s lead programmer. The reaction from more than a few McNeel folks was, “Why in the world would anyone EVER use something like that?” A few weeks later, and to my great surprise, I received a beta Gumball to test-drive. The rest is history, as they say. (And thank you again, McNeel not only for The Gumball, but doing even more with it than was thought possible!!!)

~Dave

I’d agree that snaps are one of the weakest areas of Rhino per se, be that on OS X or Windows. McNeel could definitely learn a trick or two from the seamless user experience provided by ‘construction lines’ in Michael Gibson’s MoI. Such a pleasurable experience and so much more predictable than SmartTrack. I often find myself drafting ideas in MoI and then copy/pasting them into Rhino for refinement because MoI is so much quicker for roughing out ideas and this is mainly made possible by the way that both ‘construction lines’ and the associated object snapping works.

jm

Hi David- in Windows at least, osnaps are all available at the command line, either as ‘one-shots’ or as persistent, for those that can be persistent (i.e. sets the check box in the dialog) You can asssign to hotkeys/aliases to taste- Checking the mac… the osnaps seem to work- you can look in the Object Snap tool palette for the macros (Rhinoceros menu > Commands > Customize to get at the button macros and assign keyboard shortcuts. Does that help at all?

-Pascal

I personally hadn’t realised that you can affect Osnaps through the command line and this is a huge help. Often I only want to temporarily disable a particular Osnap so the Alt key modifier is a tad sledgehammer like for my needs. Just tested this on OS X and it works too.

Definitely a step in the right direction although I still believe that the way snapping/constructions guides work within Rhino could be improved at some point. I realise this is beyond the scope of the OS X beta but I thought it worth raising anyway.

jm

Thanks, Pascal. I’ve not played with MacRhino’s customizing keyboard commands. Slick interface, btw!

Short answer—Yes, this “Hotkey Hack” is of some help. It leans in a better direction, but I don’t think it’s “there” yet. There are a few issues (SmartTrack no longer seems to work right and one then needs hotkeys for all desired snaps, among these) and I’m not sure if this can be made to work seamlessly without extensive experimentation. If so, I could imagine creating new hotkeys as part of the default and listing them in parentheses next to each type of snap.

For Hotkeys, as I understand it, existing modifiers must be used (rather than just a letter, which is my preference since one can use non-lefthanded characters if not tied to a Control key on a laptop) and these are things like Control / Option (Alt) / Command / or F keys. Shift can also be added to the modifiers but will not stand on its own.

Command = already pretty well populated, so character assignment is limited (and intuitive characters for left hand use are largely gone)
Option (Alt) = Because this turns snaps on and off, unless disabled (somehow?) seems to be out of the question. Seems like a bit of a waste of a lot of potential hotkeys for a simple on/off toggle for all snaps. (Do people really turn snaps off a lot? I hardly ever do this)
Control = Viable and the one I chose for testing. Could probably throw in Shift to double the potentials. (note: I used the non-persistent snaps in my tests.)

Returning to SmartTrack, this is “almost” a good solution, but not “there” yet. And there is a lot I don’t agree with about how this tool “works”. To wit:

  • The user seems to need to have at least one snap enabled to start drawing a line amid other lines, SmartTrack will then give you a
    bunch (read: waaaaay too many) other snap options that are not
    specifically “checked” for the second point. Pick only Endsnap and
    SmartTrack and try it. You’ll see what I mean.

  • Curiously, if no snap options are selected initially, other than SmartTrack, it gives you zero feedback for the second point. Why are
    the mess of snap options not visible now?

  • SmartTrack is simply waaaay too hyperactive to be highly useful. Maybe another approach on SmartTrack is to allow users to just turn off the feedback for OnOrtho type snaps and show only main snaps related to the geometry at hand as a default? In addition, allow the option for users to turn on or off the type of snaps they want to see. (and maybe this is possible currently, I dunno… don’t see this ability).

Jon, thanks for adding your voice to the snap-fest here! Improving snaps would be a welcome step forward for Rhino… if it’s possible! :wink: Will have to try MoI’s snaps. Am downloading a trial and will check it out.

~Dave

Jon, thanks for adding your voice to the snap-fest here! Improving snaps would be a welcome step forward for Rhino… > if it’s possible! wink Will have to try MoI’s snaps. Am downloading a trial and will check it out.

No problem. One of the great things about using MoI in tandem with Rhino is that you can cut & paste between the two apps (MoI uses open .3dm as its file format) so there’s no need for import & export dialogs.

Make sure to check out http://moi3d.com/2.0/docs/moi_command_reference11.htm#constructionlines to understand how construction lines work. My recommendation would be to repeat the examples detailed in the documentation and you’ll find the methodology second nature in no time at all.

jm

I played with MoI’s snaps and I will say, they are indeed impressive! Very peaceful, powerful, and intuitive. This is the kind of simplicity that I wish for Rhino’s snaps.

The only (slight) weakness is that one has to mouse to the bottom of the screen to turn snaps on/off if they can’t get the snaps they desire. Would also like to add hotkeys, as expressed above. But, to be honest, MoI’s snaps work so well, there is minimal toggling necessary.

For those interested in viewing a quick “snap” demo, here is the link to download it (89 seconds, 5.4 Meg. .MOV format).

If you want to play with MoI’s snaps, the download is here.

~Dave

I call up the Osnap dialog in MoI via a simple script (initiated by a simple keyboard shortcut) and keep it open permanently whilst working in MoI:

moi.ui.createDialog( 'moi://ui/ObjectSnapDialog.htm' );

You need to have the attached HTML file installed in MoI’s UI folder too for the script to work.

There are a whole bunch of other scripts that you can use to extend MoI available here (I highly recommend the ones relating to construction lines):

http://kyticka.webzdarma.cz/3d/moi/

Much as I love working in MoI, I definitely see it as a complementary product to Rhino as it lacks many of Rhino’s ‘power user’ features. But with the simplicity of the cut and paste workflow between the two apps they make perfect bedfellows

.ObjectSnapDialog.zip (1000 Bytes)

Hello,
do you plan to integrate material definition for layers soon? This is the key feature for me.

And also some way to navigate rhino to textures folder to make possilbe to open same file from my windows and keep textures running. I often switch between Mac OS X and Windows 8 boot, but priority is to stay on OS X most of the time of my workflow and working with textures and mapping is critical.

Hi Mares,

This one is on the list as MR-682 for future reference but I’m not sure when it will be implemented.

I’m not sure how it works with bootcamped Windows 8 but I believe with Windows 7 you could navigate to the Windows partition from OSX to access files. This is something to research on an Apple forum though to know for sure. Using Windows 7 x64, I am able to navigate to the bootcamp partition through the texture file browser when creating a material in Mac Rhino.

Thank you for the information. Question is, if it is possible to say to rhino where to search textures. I have all the textures in folder on C: and If I open some model created on WIN in MAC OS X, the textures are not working and I am supposed to redefine all the paths of particular textures of all materials to make them working. Is there some way to set this path to texture folder for whole Rhino system? (add to library)

Rhino 8 needs a new ARCHITECTURAL tab with a draw on face tool and a press/pull tool to create SOLIDS similar to Trimble’s Sketchup software. Sketchup is the easiest software to use in the Architectural arena. A draw on face tool and a Push/Pull tool similar to Sketchup would appeal to a great many Sketchup users who would gladly switch to Rhino 8 if it had such a tab with those tools. Sketchup software is currently only available on a subscription plan and it doesn’t have the same capacity to create large complex models like Rhino. Sketchup crashes a lot. I know a lot of people who would rather buy a perpetual license if Rhino software was more user friendly like Trimble’s Sketchup software.

1 Like