We would be satisfied with a plug-in developed ad hoc that takes care of generating fillet/blend/chamfer edges, perhaps implementing a Parasolid library just to perform these operations (the only reliable Kernel, which can perform almost perfect fittings in all circumstances) . If we wait for Rhino fillet edges we should wait for version 50 (in 126 years!). Easier said than done. 
4 Likes
This is a huge problem for âMcNeelâ, because the most popular CAD programs already have a much better âPatchâ tool (similar to âxNurbsâ), better âBlend surfaceâ with âBlendingâ factor and even an option to match the remaining edges 3 and 4. Not to mention the more advanced tools for control point editing. These tools are the reason for individual designers and companies who do product design to rely on competitor CAD programs instead on Rhino.
If I recall correctly, Rhinoâs âPatchâ tool was left unchanged since Rhino 1 and havenât received any useful update during the last 25 years. Looks like an abandoned tool to me. Meanwhile, expensive plug-ins like âxNurbsâ exist due to the lack of a good âPatchâ tool in Rhino.
Rhino lacks a good tool for âControl point modelingâ, so 3rd party plug-ins like VSR were created for Rhino 5. Sadly, itâs not supported by Rhino 6, Rhino 7 and Rhino 8.
6 Likes
Plasticity has all this (and more), to name one not very expensive. I canât imagine when theyâll get to Plasticity 8! (Iâm currently on version 1.4).
Even Moi, even though he has many fewer tools than Rhino, is following the right path.
4 Likes
Yes, the same modelling strategies work in both Sw and Rhino. Just in SW you have to rely on curves to control surface form as direct CV manipulation is not available
1 Like
Plasticity got an amazing deal on the Parasolid kernel (probably because Siemens are curious about the concept artist market), so thatâs why it got all those nice features.
The guy who apparently played a major part developing the Rhino kernel left to do Moi, and even he decided that he wasnât going to do that again and licensed kernels just like the Plasticity guy did.
Rhino is one of the few unique kernels still out there⌠but again I have to wonder if anyone who still works at Rhino knows the ins and outs of it, or how to properly develop it. Yes, itâs very difficult and it takes a long time, but looking at the close to zero development in critical areas in Rhino for the few years Iâve used it⌠I still donât think they have in-house know-how honestly.
Now, Xnurbs was mentioned, and itâs crazy to me that McNeel havenât hired them yet (former PTC people apparently) and now thereâs Cyberstrak (weird name but apparently former VSR people) which also should just be a straight up hire.
A McNeel employee recently said on this forum that Industrial Designers still are the single largest customer group, but I donât think it reflects in the development of Rhino (I bought V8 to get some bugfixes, thought right now thereâs more new bugs than fixes⌠but thereâs nothing new in there for me otherwise and even the same old UX issues which daily wastes unnecessary time that doesnât even have to do with the kernel⌠it just has to do with not listening to that âlargestâ group).
9 Likes
what i really dont like is no clear roadmap what to expect in the future.
7 Likes
In my opinion Rhino has lost its way. With each version they provide new tools, useful yes, but they remain almost unchanged over time.
After several versions it is not possible to provide a complete and convincing âsrf blendâ in every part. The same goes for âmatch srfâ⌠also the âshellâ: a great addition but it works more or less as it did when it was introduced. The fillets? apart from the rewritten srf fillet, the fillet/blend edge is still the same, lacking⌠The patch? the same one at the time of Rhino 5!
At this rate Rhino will never be able to compete with any other Cad out there, since each, in their own way, and in one area, does better than Rhino; they just narrowed the gap between Rhino and SketchUp through the push/pull tool - great!
4 Likes
As seen in this video, one major drawback is the inconvenient way of changing the scale of the slider. By the end of the video (after the 1:35 minute) I needed to adjust the slider by a very small amount, but Rhino lacks a convenient way to change the scale (the numerical value responsible for the drag resolution), so I was forced to do the following 5 unnecessary steps:
- Double-click on the slider;
- Select only the last number of the existing value;
- Remove the last number;
- Type a new number;
- Press the Enter key.
Try repeating those steps multiple times and you will understand the pain. It took me whole 80-90 seconds and tens of mouse clicks and typing on the keyboard just to fine tune the radius by a few microns. 
The âMoveUVNâ tool has a much more intelligent solution. It has a dedicated field for the numerical value, plus two tiny arrows to quickly alter the resolution. That way, the user could set whatever scale is needed and then fine adjust the control points by extremely small increments. Exactly the same approach must be used in the âSurface filletâ tool, as well.
1 Like
hi @Rhino_Bulgaria You can do the following with the scrollwheel, but there are some issues that need to be ironed out (currently on the Mac it works a bit better, where you can actually scroll by 0.0001)
As you can see from my video, the problem is caused by the inability to fine tune the very small digits. Itâs necessary to be able to change from 16,861064 to 16,861063 or similar numbers. Rhino must allow adjusting even the 7th number after the decimal comma in a quick and convenient way. Working with greater radii requires even more accuracy, up to the 8th or 9th number after the decimal comma. While those numbers sound too exotic at first glance, in reality they do quite a lot of difference when the radius is very small.
Also, lets see what happens when the radius is as large as 4000 mm. The sliders prove to be extremely clumsy and limiting. The user is forced to spend a lot of extra time and effort, in order to guess which is the value that could work, hence my proposal for this tool to be improved with an Auto mode to offer a range of values that actually build some fillet surface between the target surfaces.
On top of that, the adjustment via the current sliders is super slow and requires gazillion of mouse clicks and still canât offer a large adjustment. At one point the slider will refuse to move at all due to the bad automatic start and end values set by the program. This is where another proposal about adding custom values would fix the problem. Imagine if I had the chance to set custom values between 4000 and 10 000. That would let me move the slider all along the entire lengths of the target surfaces.
Well that dude did invent Rhino or something, but his path has been super boring so far. MOI is a waste of time imo. Maybe in 10 yrs it will be worth something. 
hmmm
yeah they barely use 3D mouses too
Well I donât agree though. Imo, Rhino has more competitors than ever before, but itâs a bit like the turtle winning the race. Rhino imo, is in the top 5 CADâs of all time. Their price points, and license strategy is bar none. If that changes then weâll have a problem lol.
They didnât even adjust for hyper inflation with R8. We all basically get R8 for like $200 pre 2020 lol. thanks to the fed and the M2 supply.
1 Like
Last time I checked, You cannot just hire people just because you want to.
Those people need to want to be hired too.
3 Likes
XNurbs may have a good product, but judging from some of the forum posts the dev made here, im not entirely sure youd want this guy as a collegue at work, personalitywise.
3 Likes
Something like this is not possible, but itâs not too difficult to make a script that brute forces a range to try for you.
This is actually a design choice, because you want that range to be fixed and not automatically be adjusting if you happen to drag too far. You can however go past the ends with the scrollwheel:
no need to repeat earlier (logged) requests.
Could we expect the implementation of the custom values to be added in Rhino 8 in the coming months? Also, what about the ability to extend only side 1 or side 2, instead of both or neither?
I tried to scroll the mouse wheel to overcome the too strict automatic limits of the slider, however, this is also extremely slow and requires more than 100 rotations of the wheel to be able to adjust the surface fillet when the radius is about 4000-5000 mm. Even though that my mouse (Logitech G502) has a wheel with a release switch to spin freely, this is still a slow and inconvenient solution. Not to mention that the mouse scroll wheel canât move the slider when the radius is beyond the range at which a surface fillet could be created in the preview. That makes the whole process even more tedious.
Why is that?
KeyShotâs scaling handles have an auto-adjustment feature and Iâve found them to be more useful than harmful (if over-aggressive adjustment/unexpected program behaviour is what youâre implying would be the issue here).
1 Like
Say you want to try a range between 5 and 15, you set the slider to 10, the range to 10. You can now drag the slider up and down, without having to closely watch this slider, knowing it will stay in that range. Again, you can move the range, beyond the slider if you will, by the scroll wheel.
Hey Bobi, from what I gather, is the functionality youâre looking for something akin to BlendSrfâs interactive handles and numerical input except, in this case, for dictating the size of the fillet?
Or put another way, would you like it if BlendSrf had another set of handles in the menu that allowed you to drag the fillet past the initial surfaceâs edges (similar to how in BlendCrv, you can choose a point along the curve as well as the curvesâ ends) and lock the handles or play with them individually?
I guess if weâre dreaming up suggestions here, then perhaps it would be cool to have a more direct-editing way to craft blend or fillet surfaces by just dragging the end edges of the surface, or selecting a few shapes and dragging them where you want.
Hmm, yes I can see how that workflow could work, but personally, thatâs less intuitive than, say, clicking the numbers on the end of the range, typing what you want those to be, then dragging the slider between those numbers. Like, that involves math (Iâm lazy) and even then, what if you want a range between 20 and 70?
Actually, now that I think about it, dictating the scaleâs range using the range number buttons doesnât seem intuitive to me as compared to dictating the range yourself (using the auto-generated range that Rhino provides as a basic range to start) and using those number buttons to dictate the sensitivity of the handleâs drag or scroll. But even then, other programs use shift for big changes and alt for smaller changes iirc.
The way KeyShot works is such that if the slider gets close to the ends of the range and the user lets go of the slider, then it adjusts. It doesnât adjust while sliding if thatâs what you were worried about. Iâll record a demo and add it to this post in a bit.
I think Rhinoâs menu has a 1 up on KeyShotâs in terms of intuitiveness by displaying the current âradiusâ in the middle and the numerical limits either end, instead of having to guess or drag the handle to each end of the scale like in KS. However being able to click on those numbers and specify a range would make it super useful.
1 Like
we found the jumping sliders to be very annoying if you want to try certain values, you donât want to constantly hunt for the slider control
as mentioned, custom range request is logged earlier in this thread