Hi Matt,
Thanx for asking.
Clement was very helpful to me.
I still had to ‘ferret out’ the issues for myself.
His equipment and software are older, so it didn’t apply directly to mine.
No, McNeel has not resolved this issue.
I have done enough research to conclude that McNeel dropped the ball on their revision of Rhino5 Digitizing.
My reasons are based on experimental data (see below link) proving that MUS7 properly manages tip lengths, but still nothing exists in Rhino for master tips which are spherical.
NOTE: I HAVE NOT FOUND ANY REASONABLY PRICED SOFTWARE THAT ACCOMPLISHES BALL TIP COMPENSATION FOR DIRECT DATA INPUT. Ball tip compensation is needed when using a spherical tip, b/c Rhino and MUS7 digitize to the center of the ball tip sphere, not to the outside surface. SO, the b.s. “work-around” is digitizing your real-life surfaces, and then properly OFFSETTING those surfaces. OR you can pay $20k for software that MAY do it for you! I absolutely refuse to use the “work-around”, knowing the mess it will make of the process of RE. Been there, done that, not gonna happen. I don’t care what anybody else says, b/c I know better.
One would think that McNeel would have not ‘overlooked’ this in their software, esp. since many of their customers use the MicroScribe digitizers. I was working on this with Scott Davidson at McNeel. See here: https://discourse.mcneel.com/t/microscribe-requires-the-standard-tip/47117/11 . He hasn’t gotten back to me in many weeks.
He said they have an MS digitizer which they will setup and get back to me on. But when I discovered it was a “G” instead of an “M” (like I have), he never got back to me. I clearly spelled-out that the issue is POINTED TIP vs. BALL TIP. The “G” has a master tip that’s POINTED, whereas the “M” has a master tip that’s SPHERICAL. Apparently, McNeel didn’t count on people using an “M” digitizer w/a pointed tip in Rhino4/5.
So it is impossible for me to use Rhino5 with direct input, b/c no matter what I do, I can’t get Rhino to compensate for the tip length on an “M” series like it does on a “G” series digitizer. The reason, I believe, is b/c Rhino5 was designed to be used with a master tip that’s POINTED (= “G”), not SPHERICAL (= “M”).
I wish someone would address this issue, b/c HAD I KNOWN IT EXISTED BEFORE BUYING THESE DIGITIZERS, I WOULD HAVE NOT SPENT THE 1000’S I DID ON THEM. I suppose this is the price you pay for not sucking up to the vendors who extort absurd prices for half-arse hardware that the criminal syndicate pays for by heaping tax monies on these metrology conglomerates. Whatever. I just wish someone at McNeel would address this so we can get on with our work. I also wish those brilliant math people at McNeel would take the public domain University work I’ve read and use it to create a BALL TIP COMPENSATION PROGRAM for the digitizers used w/Rhino5/6.
Finally, I used MUS7 “custom tip” to establish the proper tip length, and then opened Rhino5 and selected the tip name that I established in MUS7. That gets you the correct length. However, it will not get you tip compensation. You can read about that in John Brock’s link above. Again, I refuse to do all that offsetting, b/c it wreaks havoc on the RE process. (I don’t care what others do, or say you can do, b/c such a process introduces an untold number of problems and errors in the process of RE surface modeling. Anybody who’s encountered Rhino’s surfacing limitations will agree with me).
Incidentally, I did use the tip calibration routine in Rhino, and with a “G” series, it worked fine. But I trust MUS7 for that (= custom tip) over Rhino.
Hope that answered your question, even though it involved somewhat of a rant.
Cheers … Chris