All I’m sayin’ is that the whole discussion started on various BBSs in 1985 with the Parasolid vs. ACIS show… but, luckily, now we have the RGK, the Russian Geometry Kernel, courtesy of Stankin/Ledas!
Спокойной ночи!
All I’m sayin’ is that the whole discussion started on various BBSs in 1985 with the Parasolid vs. ACIS show… but, luckily, now we have the RGK, the Russian Geometry Kernel, courtesy of Stankin/Ledas!
Спокойной ночи!
I expect it to work correctly, which means the software would be doing programmatically what the user must now do programmatically to get the correct result. That’s what computers are for - to do tasks that are formulaic and repetitive.
Take the example RichardZ posted above:
Assuming all those surfaces have tangent continuity the current workflow for making the fillets would involve 2 clicks to make the first fillet (say srf A and srf B). then the next place the user should click to produce the next fillet in sequence is at the corners of the last fillet the user just made. In other words. Rhino should be able to figure out what the next pair of surface to be selected are the same way the filletSrf user now figures it out by examining where the corners of the last fillet landed. In the above example depending on the size of the fillet the next surface would be from C to A or possibly D to A. You find out where the next connecting fillet goes by looking at where the corners of the last fillet landed and then you pick the surfaces that you find at those corners.
This strategy means that you will end up with the correct result even when the pair of input surfaces do not share a common edge, which is a very common occurrence. If the base surfaces are all tangent and the fillet is sized so that it fits you will end up with a chain of fillets all the way around.
Significant time saving to the user could be had if there was an option in filletsrf to continue filleting all tangent surfaces.
In other words if Rhino finds another surface with the same surface normal at the corner if the last fillet then it has all the information it needs for the 2 input surfaces for next fillet. And the other end if that fillet shows what the surfaces for the next fillet are.
As for spherical corners, that is no different then any other tangent surface that is encountered when making fillet chains.The 3 needed inputs for SphericalPatch can be derived from the 3 surface normals of the fillet that runs into another fillet of the same size as shown in this picture
After you have done it long enough you will discover that even in a very cluttered scene you can always figure out where to click for the next fillet by going to the end of the last fillet and clicking on the surfaces that you find at the corners.
I don’t expect everything to be done automatically but there are a few things that are simple to program that would cut the workload on the user enormously.
…assuming your models don’t wind up at the FSB.
The VSR/ADFilletSurface command can fillet two different sets of polysurfaces withfour clicks but - creates a single surface over all connected polysrf. So basically rhino could it also.
Is there any chance we’ll see Fillet surf developed further? Preview, G2, Constant width, handles etc.
Sure, there’s always a chance. We have several items on the future wish list for improvements.
However, we have to make a judgement call about development. Our goal is always to choose the projects that will help the largest number of users with our limited resources.
As was pointed out earlier in the thread, this means that most of the past effort has gone into FilledEdge.
Discussions like this one do help.
John, I would not like to be controversial, but after nearly 6 versions of Rhino, about 30 years of continuous development it is not possible that the fillets (but not only those) are still at the stone age (they work more or less like in the early versions of Rhino, with little improvements).
Resources are few, okay, but efforts should focus on robust surface enhancements (creation and editing). The priorities are these, not the best rendering, or so many unnecessary viewing modes, in my opinion (these are embellishments).
There are dozens of rendering softwares out there, so that should be an ultra-low priority in the light of the fact that if one wants to render finished models, the models have to be of top quality in the first place, so any improvement to the very basics, such as filleting, is more useful, no?
The claim that other functions have been put to the side to prioritize rendering is plain false. Different developers work on different things.
Also, what could be more basic than actually making sure you can see your objects on screen - a lot of work has been put into the display, yes.
i actually have to agree with all of you, BUT this fillet topic is going SO on my nerves already, with the amount of time you invested in complaining you could´ve maid trillions of manual fillets, so to me it seems you are not too much in a hurry anyway and even if that sounds rude now, if you want to invest your time useful…
–> GET A JOB!!!
Improving display quality, with connected antialiasing, goes more than good!
The problem is subtracting development resources for rendering and commands of little utility, often left incomplete and unfinished.
Rhino has hundreds and hundreds of unnecessary and unused commands: not even Catia has all these “little” commands!
Practical example: Blend surface. It works yes, but for years, always the same way. Far from command in VSR.
Patch Command: always the same! often useless, equal …
On the contrary, one of the commands that surprised me is “Extend Surface”: now working and far better than the past (Rhino 4 and 5).
I find myself in agreement with both @Lagom and @wim, and now don’t know what to do…
In all seriousness, I’m looking forward to dramatically better visuals while designing, as opposed to taking in process designs to Keyshot for a ‘look’, and:
Looking forward to future core modeling enhancements too!
(That will be taken to whatever produces the very best image we can get for presentations and marketing materials.)
Easy. Don’t read these kind of topics. This is the best alternative ; )
Here is a file showing how easy it would be for Rhino to improve the user input.
FilletingTangents.3dm (339.9 KB)
It would take very little development time to implement an option to make all the subsequent tangent fillets that are implied by the 2 mouse clicks that define the first fillet in a sequence of connected tangent fillets.
File added to the bug item for this thread, thanks.
-Pascal
Would it be possible to add extend NO to Variable fillet/blend/chamfer?
I’m confused how is that @jim example is suddenly a bug? It’s the well known and documented behavior of fillet edge. It’s why so many have complained about it.
Well, yes, bug is probably not the right word - we track all this on the ‘bug tracker’ whether it’s a bug or a wish or just something we want to keep track of… I would usually use ‘YT item’ or ‘YouTrack item’ if I feel readers know what that is, but here, apparently I did not.
-Pascal
Hello,
I am a designer for the sailing industry, and I get a lot of solidworks files. I can say that if solidworks user is not a specialist, each filets can be deleted and rebuilt in 3D rhino … on a 40 feet boat there are many fillets, and building history in solidworks becomes very long and very heavy … a simple modification in the history, and everything becomes very complicated to resume (under solidworks). and some end of fillets are simply impossible with solidworks …
with rhino, it is very long and tedious, but there are no bad surprises.
there is only with catia files i get,that there is no matter.
sorry for my so bad english
Franck