Rhino trouble with radius

[jim]

@TomTom

. My intention was only to say that, on a coding level, this is such a complex topic, no matter if its theoretically possible or not.

. It has already been explained how this could be easily scripted if McNeel supplied a function that identifies the surfaces that are within tolerance of a point in 3D space.

You have yet to say one word that suggests the proposed script would not work flawlessly to make all the fillets in example given at the top of the thread. It would also work in many other examples people have posted. The fillets would be just like Solidworks rolling ball fillets.

@TomTom

. I also believe everyone would like to have a better and more reliable global fillet functionality

That’s another statement that is false. Rhino already has a reliable rolling ball Fillet tool - its called FilletSrf. Rhino can reliably make any rolling ball fillet that Solidworks makes. FilletSrf can also make some fillets that the solid modellers can’t even dream of making. It is precisely because FiletSrf is so reliable and powerful that it deserves some development time. It has been ignored by the developers.

What you don’t seem to understand is that the surface Filleting method can be in many situations a much more powerful tool than the solid modeler way of making fillets. The two methods may get to the same result but they get there in different ways. The 2 methods can not be put into one global tool. It would be stupid to attempt to put the 2 very different methods into one global tool.

[clement]

@jim

It has already been explained how this could be easily scripted if McNeel supplied a function that identifies the surfaces that are within tolerance of a point in 3D space

Hi @jim, that function already exists and is called brep.ClosestPoint which gives a component index so it looks possible (in the first glance) to find out the index of the surface(s) in the brep and then get the required uv point from the “picked” two points to feed the fillet function, for a first starting fillet, but:

The problem is, if a fillet would be a non extended fillet and you would try to get the two required points for the next fillet from it as you wrote above, you have no guarantee which indices of surfaces you retrieve from the brep to be filleted, because under one point, there could and will be multiple surfaces, each fillet ends exactly where multiple surfaces meet. How would you find out which are the ones to fillet next ?

Even if you get all things together to feed CreateRollingBallFillet method it currently will not work to create a non extended fillet like it is possible using _FilletSrf in RhinoCommon. The method does not support _Extend=No and creates an extended fillet. This is where i stopped my trial.

The interesting thing about your proposed scriptable way to add consecutive fillet surfaces by some kind of automated _FilletSrf is that many non programmers could not imagine how much work it is to automate things programmatically. What you spot and decide as a user with your eye within a millisecond requires hundrets of lines of code to figure out if you do not see it. There is no visual feedback at all. As a programmer, you don’t see anything of what the user sees when he is asked to pick points for filleting, when he decides where to put another fillet and where not.

Even if we would have the CreateRollingBallFillet method create non extended fillet surfaces, there are many many things to consider in your proposed scripted version of _FilletSrf. Imho one of the largest is that it will not create any trims of the input brep faces.

The more i think of it, big respect to McNeel and Chuck for what _FilledEdge actually accomplishes. I hope it will be improved further with all user feedback from this forum.

_
c.

[jim]

@clement

that function already exists and is called brep.ClosestPoint which gives a component index so it looks possible (in the first glance) to find out the index of the surface(s) in the brep

Will that find any surface that exists? even one that is not joined to anything else? This script should be a surface modeling tool and therefore should not be constrained to only work with joined surfaces.

@clement

then get the required uv point

Yes that would be the next step. Ideally there would be a surface_closest_point function that returned both the surface ID and the UV location at the point.

@clement

The problem is, if a fillet would be a non extended fillet

That’s not a problem. Not extended is exactly what’s needed.
We are dealing with the case where all the surfaces are tangent. Solving that one case will reduce the work of the filletSrf user enormously. other cases can be addressed later. The process could check the normals at the point and if the normals don’t agree then extend the fillet at that end would kick in. But as a start assume that the surfaces are tangent like in the current example and many other examples that have been posted.

@clement

which indices of surfaces you retrieve from the brep to be filleted, because under one point, there could and will be multiple surfaces, each fillet ends exactly where multiple surfaces meet. How would you find out which are the ones to fillet next ?

That’s pretty rare, but it can happen. But again we are talking about surfaces like in the example that are tangent and trimmed to each other that means only one of the surfaces will support a fillet, The fillet function will return no result for the rest. Only one fillet will be made.

@clement

decide as a user with your eye within a millisecond requires hundrets of lines of code to figure out if you do not see it.

That’s nonsense. I decide the same way the proposed script decides. I look at the corners of the last fillet and I click on the surface that I find there.
If I find more than one surface I may have to try them both. There are simple ways the script could determine which one the fillet is going to land on but it is probably just as fast to try them all.

The main reason people have trouble with FilletSrf is because they cannot do what you claim they can. They can’t see where all the fillets go and as a result they miss some of the surfaces and they end in failure. If they follow the recipe of looking at the corners of the last fillet and clicking there, it works. Its extremely reliable.

.

[clement]

@jim

Will that find any surface that exists? even one that is not joined to anything else? This script should be a surface modeling tool and therefore should not be constrained to only work with joined surfaces.

No, above would require a brep to search for the faces. But i could imagine some different way using rs.PointClosestObject if it needs to work with individual surfaces. I think picking and getting the surfaces in the first iteration is not the biggest hurdle. If you get the surfaces, you’ll get the UV location pretty reliable. (if there are not multiple surfaces overlapping at that point).

The only way i see to create the fillet either extended or not is to use Brep.CreateFilletSurface. If you look at the inputs you see that a brep is required.

@jim

That’s pretty rare, but it can happen.

Yes, and when things can happen, you need to handle them. If you do not handle every possible case which can happen, things will just fail.

@jim

That’s nonsense. I decide the same way the proposed script decides. I look at the corners of the last fillet and I click on the surface that I find there.

You will probably get the exact same surfaces which you got in the first iteration. There are 2 different point pairs on each end of a newly created fillet. How do you decide which of the two should add annother fillet ? And if you try both pairs, and all possible combinations and compare with combinations which already have been processed, what do you do if you cannot find out which are the two surfaces to fillet next ?

See below example image, i’ve used Brep.CreateFilletSurface to avoid getting an extended Fillet which would be the case with Surface.CreateRollingBallFillet:

As you can see, i’ve already seperated the result from the command, you get the fillet (green) and a trimmed brep as two seperate arrays. Please understand that it is not nonsense, i decided 2 things visually up to this point: First, the fillet would have to be non extended because it would then be useless while it extends over the vertical large fillet. Second, i’ve decided what to delete from the first iteration.

If i would like to continue as you proposed, how should i find out the next surfaces to fillet ? As you can see in the image, 3 of the 4 corner points of the fillet are exactly above 2 surfaces each. Which is the one to pick and why ? What would you do if the component index returned from a closest point operation does not belong to a surface but a brep edge ?

@jim

There are simple ways the script could determine which one the fillet is going to land on but it is probably just as fast to try them all.

How would that work ? Can you describe these ways ?

@jim

The main reason people have trouble with FilletSrf is because they cannot do what you claim they can

I did not claim anything. I’m just trying to make you understand that things are not as trivial as you think. Imho it is not 100% correct to asume that by picking the pairs of points at the first fillet ends always result in a new fillet. There is much more involved than just two points.You’re probably generating existing fillets again and again or just get no fillet at all. If you want to make a robust tool of your proposal, all possible situations need to be handled for a specific reason. Before going on with this, distinct rules have to be defined.

_
c.

[Vladimir_Aleksic]

Very interesting discussion, it’s maybe important to point out that VSR can do this within rhino.

[philipp.p.suess]

what is vsr?

[jim]

@clement

i could imagine some different way using rs.PointClosestObject

Does that find all the surfaces within tolerance of a point?

@clement

That’s pretty rare, but it can happen.

Yes, and when things can happen, you need to handle them. If you do not handle every possible case which can happen, things will just fail.

I already told you, the next fillet will only land on one of the surfaces, Try it for yourself on the example posted. Create a fillet that is just the right size so that it lands on a spot where more than 2 surfaces come together, That won’t create any problem. Only one of the new surfaces will support the next fillet. The FilletSurface function will just return empty for the other surface.

@clement

There are 2 different point pairs on each end of a newly created fillet. How do you decide which of the two should add annother fillet ?

I already explained this. The typical situation will be there is one surface at one corner and 2 surfaces at the other corner . The corner with 2 surfaces will have one new surface and one surface you just used. The new surface and the surface at the other corner are inputs for the next fillet.

Try using the filletSrf command to do the filleting in the example that started this thread and then you would be able to answer these questions yourself.

@clement

And if you try both pairs, and all possible combinations and compare with combinations which already have been processed, what do you do if you cannot find out which are the two surfaces to fillet next ?

Again I invite you to try making fillets with filletsrf and you will no longer be mystified by how this process works. There is no problem figuring out which surfaces to use next if you follow the recipe I suggested.

@clement

i’ve already seperated the result from the command, you get the fillet (green) and a trimmed brep as two seperate arrays. Please understand that it is not nonsense,

As I said earlier we are dealing with the case where surfaces are all tangent for the sake of simplicity. Automation of filleting all tangent surfaces alone will be an enormous increase in productivity to users of filletSrf.

In your example on the right you find at each corner a new surface and an old surface. At the point of contact the surface normals between new and old do not agree so that means the chain ends there. If you are writing code you start with the simplest case first. You get the code working flawlessly for that case and then you move on to adding things to handle other cases. The left side of your fillet is the simple case like in the example above.

On the left you have 2 old and one new surface. The surface normals do agree between new and old so the chain continues there, using the one new and one old as input for the next fillet.

@clement

There are simple ways the script could determine which one the fillet is going to land on but it is probably just as fast to try them all.

How would that work ? Can you describe these ways ?

Its an extremely rare event so it isn’t worth doing anything more than the brute force method of feeding both sets of inputs and using the one that works.

@clement

The main reason people have trouble with FilletSrf is because they cannot do what you claim they can

I did not claim anything.

You claimed that I can see in a millisecond where the fillets go. That’s just nonsense. Most often, the only way I can tell for sure where the next fillet goes is to look at the corners of the last fillet.

@clement

I’m just trying to make you understand that things are not as trivial as you think.

It is obvious to me you have little experience making fillets with the filletSrf command. If you had just a couple days worth of experience with filletsrf you would realize that all your objections have been groundless.

Try filleting the example that was posted, you might learn something

[Vladimir_Aleksic]

The discontinued autodesk surfacing plugin for rhino.

[clement]

@jim

It is obvious to me you have little experience making fillets with the filletSrf command. If you had just a couple days worth of experience with filletsrf you would realize that all your objections have been groundless.

Ok, thanks, i’ve just been using that command since 1998.
_
c.

[jim]

@clement

Ok, thanks, i’ve just been using that command since 1998.

Then the next time you use it pay attention and you will notice that it works exactly as I described. You may also notice that you could be saving a huge amount of time if the areas of tangent surfaces could be done with just 2 clicks instead of 20 or 30 or more.

[clement]

Who said that it takes me 20 to 30 or more clicks to generate a fillet using _FilletSrf ?

_
c.

[jim]

@clement

Who said that it takes me 20 to 30 or more clicks to generate a fillet using _FilletSrf ?

Everything you write leads me to believe that you have very little experience using filletsrf. The example at the top of the thread requires at least 20 mouse clicks. For smaller size fillets the number of clicks would be closer to 30.

If you had any experience you would know that the user can’t just look at that model and tell where each fillet will land and how many fillets there are going to be and which base surfaces are going to be involved. The only way the user can figure that out is by making one fillet and then using that as reference to figure out where the next fillet goes and then using that as reference for the next and so on. Why is it that the user is expected to be smart enough to figure all that out but its way too complicated for the developers?

[clement]

@jim

The example at the top of the thread requires at least 20 mouse clicks

Nope. Please stop insulting everyone who disagrees with you, it will not bring us further to gain something useful from this discussion. The solution to the problem of the OP is not to click 20 or more times and create all these litle fillets using _FilletSrf, then the same problem is just carried over to the next.

If you look at the source, it is much easier to fix that. It’s been already explained above how to obtain a fillet with a single click not 20 or more by creating the half pipe and cutter from single surfaces. I would prefer doing it just to avoid all the mess.

@jim

Why is it that the user is expected to be smart enough to figure all that out but its way too complicated for the developers?

I’ve tried to explain how i see it, the problems developers have to cope with are quite different from what you see (with your eyes) as a user.
_
c.

[TomTom (Tom)]

@Vladimir_Aleksic

Very interesting discussion, it’s maybe important to point out that VSR can do this within rhino.

I already solved that in my library. And it required me to go beyond scripting, actually doing real Bezier/Nurbs math .
I basically mirrored the manual approach: You need to extrapolate a fillet at the ends and pull cps in extrapolation direction back to the tangent edge blend . This process is called trim, not to mix up with the term “trim” used in Rhino. Because it keeps a surface (Rhino) untrimmed.
I heard a couple of times from Rhino users this is not possible, but Alias,Surf and VSR have that functionality and its a vital part of modelling. For those who not know, VSR Plugin was made by Icem devs, with over 30 years of experience. And this what leads me back to my initial comments, and what @clement says as well: Its not trivial at all… It is not only because you need very specialised knowledge, you also need a bunch of functionality first, to actually begin to solve your initial problem.
Which also explains, my initial statement

@TomTom

Its not an reliable automated fillet edge, its general surface tools, Rhino lacks of. In other direct modelling software, manual filleting is much faster.

So without these functionalities : extrapolation, real trim, non-rational fillets, improved matching (yes, you can match a surface with much more options as Rhino offers), improved blending etc, you have no chance in automating the process. But if you would have them, you would also be able to create fillets much faster in a manual process (if you know how). This is also why we don’t use Rhino as primary cad modelling software. Not because we don’t like, but because it lacks same very basic (but technically advanced) tools.
VSR Tools was the right direction, but still it was lacking some functionality. And if more people would have needed such functionality, there would have been no need in selling it to Autodesk. Another truth is, most Rhino users don’t need that, so I also understand if McNeel goes into another direction. If you need pro tools you need to buy them, they are available but expensive due to the lack of demand.

[TomTom (Tom)]

@ec2638

Likely solved in the ‘20s, and hopefully commercialized by the ‘30s.

Until then, take your arse, and I.D., to Santa Barbara CA, or Loja Ecuador

I’ve been in Santa Barbara 4 month ago, and seriously if I would have the chance to actually life there, I would definitely say yes (although my family probably has another opinion on that).
Its not that Wolfsburg or that particular car brand is what I promote as the best, I would even find enough arguments to prove the opposite. I’m not even the most car enthusiast around. I currently like to solve cad related problems and this is what makes me happy. And who knows what happens in 20 years. If peoples madness improves with the same speed as innovation does, its also very likely ending up filleting battle drones … or being filleted by one

[nathanletwory (Nathan 'jesterKing' Letwory)]

@TomTom

or being filleted by one

[ec2638]

@TomTom

filleting battle drones

Find your 75 degree paradise where EV range loss won’t annoy you.

Refocus, take @jim with you, and open a shop called …Fillets-R-Us. Jointly develop a killer Rhino plugin, and shut all the rest of us up.

5 Places Where The Weather Is 75 Degrees And Sunny All Year Long

[TomTom (Tom)]

@ec2638

filleting battle drones

Find your 75 degree paradise where EV range loss won’t annoy you.

its not the ev range loss which annoys me, its the way e-cars shall look like.

@ec2638

Refocus, take @jim with you, and open a shop called …Fillets-R-Us. Jointly develop a killer Rhino plugin, and shut all the rest of us up.

at which point of my comments I said I’m a masochist? Its not that I do fillets all the day. How boring would that be…

[jim]

@clement

It’s been already explained above how to obtain a fillet with a single click not 20 or more by creating the half pipe and cutter from single surfaces.

I’m well aware that you can merge the surfaces and reduce the problem to just 2 surfaces and then you can make the fillet with filletSrf in just one operation, but if you look at the result you will see that you end up with a chain of individual surfaces like you would if you did the fillets one surface at a time. What you fail to grasp is that only adds support to the idea that Rhino should be able to make all these fillets in one go even when the surfaces are not merged.

There is no reason the user should be expected to merge all those surfaces. That’s just another example of the user being expected to be more competent than the developers.

FilletSrf should make those fillets in one operation even if the user has not merged the surfaces. In fact, Rhino should make the fillets in one operation even when the surfaces cannot be merged. The only requirement is that the surfaces need to have tangent continuity

and furthermore

they only need to have tangent continuity at the one point where the fillet chain crosses over edges.

Anytime those conditions are met Rhino should build all the fillets in one operation.

@clement

I’ve tried to explain how i see it, the problems developers have to cope with are quite different from what you see (with your eyes) as a user.

That’s not correct. I have not proposed anything that requires seeing with eyes.
You have made no valid arguments. All you have done is declare that your programming knowledge is so vastly superior that it allows you to declare the idea invalid without understanding how it works or a single factual objection to support your declaration.

[clement]

@jim

All you have done is declare that your programming knowledge is so vastly superior that it allows you to declare the idea invalid without understanding how it works or a single factual objection to support your declaration.

Aha. Interesting. I think i got it an know exactly what i am talking about. I’ve added a 1 second delay after each fillet.

It seems to work with the model posted above too.

But: You are completely wrong about when FilletSrf works and when not. It is quite amusing what you know about other peoples ability to use FilletSrf or or about their programming knowledge.
_
c.