Your first one isn’t possible with NURBS surface modeling since the box and sphere surfaces do not intersect, so no on that one.
The tangent pipes is a surface intersector question. @GregArden is working on those and getting closer. There are a handful of special situations like yours that can’t be done automatically yet.
The corner fillet pull-back would be something potentially possible. Please make your case for why that would be a benefit to your modeling or work-flow. @chuck
The blend surface is possible with current tools like NetworkSrf and the rail sweeps, but something along the lines of the adjustable Blend Curve might be possible. Again, please make your case for how that would be a benefit to your modeling and work-flow process. @dalelear
I guess having a setback option in the blendedge/filletedge command would come handy when one wants to model blend- or filletedges with - wait for it - a setback.
The benefit seems to be quite self evident to me.
A setback fillet or blend is a design characteristic not a workflow option.
A design may or may not require setbacks for esthetic reasons.
If it does, a setback function in blend-/filletedge is an obvious problem solver as it automates the construction of these setback corners.
Personally I prefer to layout blends and fillets differently and am no big fan of setback corners, but they are a common design feature, especially in product design and are quite complicated to construct manually.
Okay, I wasn’t aware of this script.
I have not tried it yet, but I asume it works.
So that means there already is a solution, which makes it even more strange to not want to implement it into the existing filletedge/blendedge commands.
This would, amongst others, give the possibility to preview the result.
It would also make this function accessible to all users, not only the ones knowing about a specific script that is not documented in the help files.
By the way, wouldn’t it be a good idea to have an official script repository, organized by function rather than by “people” as it currently is in the wiki?
I note that the fillet type “setback” are present in almost all modelers (solids and NURBS), including in solidThinking, where they implemented a few years ago. Are widely used in design, and build them manually is very tiring.
The command “BlendCrv on srf” (adjustable), I would be quite useful, to avoid continuous projections of the curves on surfaces, in order to obtain a continuity at least in G1. In UGS NX this command exists, and I think it is also present in Catia, if I’m not mistaken.
If we work on a surface or polysurface, and we want to get a connection between 2 curves, for example, this command would be very useful and straightforward, what do you think?
Small aside: I also hope that the command should be revised “ExtendSrf,” I’d like to see implemented to allow a handle to pull and extend one or more edges at the same time (cut or not) of a surface. Currently its operation is rigid and not very functional, in my opinion, I would say limited.
You should also create an option in the command that tells me whether or not I want to keep the extended part, as in Catia example.
Norbert I think you are misunderstanding the way McNeel works. There are a number of features that are an integral part of Rhino, (of course) and there are a number of items developed by people (scripts and plugins) that are available for Rhino. Just because someone develops one that doesn’t mean that McNeel will incorporate it in to the master program. Sometimes they do, and sometimes they don’t. The fact that McNeel allows people to create these scripts makes for a much more creative and robust program. If everything had to run directly through McNeel and be approved before being available for Rhino it would slow down this process. McNeel’s willingness to have us create these scripts is remarkable and impressive.
I can understand your wish to have a particular feature added to the program, but you still haven’t made your case. Just because you want it and someone has written a script that still doesn’t explain why this feature is important to add to the master program.
Let’s just forget for a second that the script in question doesn’t do what was requested.
As I said, I hadn’ used it and therefore was not aware it only works on curves.
Let’ s just pretend Pascal’s setback script worked on filletedge/blendedge.
Last time I checked, Pascal Golay was working for McNeel.
So it is NOT just somebody who wrote a script.
I agree that McNeel cannot take care of ALL user generated scripts and incorporate them into the program, I was merely pointing out that if a special function is already provided by a McNeel written script, it might as well being implemented into the more general command interface.
But back to the actual topic:
I made my case, you just don’t happen to understand it ( that may very well be my fault), so let’s spell it out again:
I don’t particularily need the setback feature, it was requested by another user.
John questioned the benefit of a setback option, I answered it would help making setback fillets/blends (surprise, surprise)
still John and you asked: “what problem is solved”, “why is setback important”, I answered that setbacks are very common fillet/blend types especially in product design. A command that allows to create them therefore has exactly this benefit: creating setback fillets
(you might as well ask the question: “Filletedge? Why is this important? What problem does it solve?” my answer would be:“it creates filleted edges. Doh!”)
I really don’t know how to make this any clearer.
the whole script discussion started because you pointed to Pascal’ s setback script, but this does work for curves only, so this just leads to nothing.
Well, there are also reasons for why this does not happen. Mainly reliability and robustness, but also after that speed and memory consumption. If you run a script and it fails, you say, “Well, it’s only a script… no big deal”. If it’s a real “official” Rhino command, that’s different, you expect it not to fail, which means it has to be made bulletproof, and that can take a lot of time and effort to both create and test. Also to become a “core” function, a script would have to be re-written in lower-level code than a typical rhinoscript script. That’s usually more complex and time consuming as well.
So when Pascal hacks out a script to try and solve a user problem, even though he is who he is and can work magic with his scripts, that does not mean that they can be instantly transformed into core Rhino functions.
All that being said, functions that start out as scripts and that are found to be universally useful usually do end up getting into Rhino after awhile… I don’t know how many of mine I’ve “retired” with Rhino 5, but there are certainly a few… OTOH, I think I still have a few that I use from other people (before I could do it myself) that go back to V2 or earlier…
If Rhino wants to be competitive will have to adapt to other major software: I know that Rhino is a separate program, different than, for example, UGS NX or Catia, however, certain things you can not miss.
SolidThinking is trying to solve as many problems as possible, especially in the fillet, the Boolean and the shelling. Rhino is doing, but in my opinion, loses sight of some fundamental aspects to look for alternative routes, ending up becoming a program full of “useless” commands and function of dubious value.
What do you think?
If 8 out of 10 CAD programs have the fillet type of setback, because Rhino should not have them? (this is just an example).
We can say: Rhino does other things; but that does not mean anything! A software dedicated to design free-form should solve certain problems, as it has been for the shelling finally added after 5 versions, after years and years of development!
Rhino can not do everything and satisfy all users, but some critical aspects , after many years , should it have already been solved , or not?
I agree with these guys that, before adding features, they’re are a few current elements that could be improved.
A better way of removing duplicates rather than just Sel Dup or
intersect. Or upgrade SelDup so that it has an option of selecting
partial lines as well as identitical copies.
Improving the reliability and versatility of Fillet Edge to make it easier to fillet something in multiple directions.
Offset multiple is awesome. Now we need an offset that never gives
junk curves (I’ve been talking to Pascal about this . He has some neat
curve clean up tools but can’t stop it from happening in the first
Also, how bout an offset that can change the corner (round,
smooth, chamfer etc) when offsetting inward and not just outward like
On that note, offset multiple needs to get the tolerance override option. So that we can choose to get offsets that don’t have a million
A rebuild option that will keep the straight edges and sharp
points of a polycurve whilst letting you simplify the rest of the curve.
Sometimes you have a curve that meets itself at a sharp point. Using rebuild on these is a pain because that point flies out unless you have a curve with a million points, and even then its going to be fillet. It’d be nice to keep the sharp points and yet be able to rebuild, say when trying to fix nasty offset curves for example.
Fillet corners doesn’t grab everything. Many times you can manually fillet stuff with the same dimension no worries, while fillet corners failed.
I know that the boolean operations will be difficult to improve,
but there are still many situations where I can boolean things the long
way (intersect, trim extra sides, join) that won’t boolean with the
These simple things affect the majority of your users, even if they
don’t realise it. 90% of professional drafting is simple tools. -Offset, fillet, trim ,extrude.
Boolean has gotten more important than ever before thanks to 3D printing and feature-finding in CNC CAM programs.
For your first request “- Boolean difference: solid into a solid.” there is a solution, not as easy as it should be for me, but you can create a solid with surfaces that don’t touch like the case you show.
You need to use 2 commands, first select the outer and inner surface or polysurface and use _NonmanifoldMerge, then use _createregions this will create a solid and leave the inner surface as a separate element than you can delete.
I find this extremely useful when you need to export something to other programs.