Can you post an example of this as well? thanks.
FWIW the examples you posted still all work in V8 with your script. That being said there is currently a bug that makes FilletSrf produce less accurate results than it does in V7
What I’m talking about is not unique to joined fillets. Its everywhere and I have a hard time believing this is something that happens by accident. It has all the earmarks that somebody had the goofy idea that this was some kind of an improvement.
I already reported this previously here after Pascal observed that the individual edge curves of a joined fillet string failed to trim. The cause I suspect is that gaps in the edge curves.The edge curves don’t have their ends at the surface vertices
Here is another example created using Filletsrf and then joining the 2 fillets made.
Bad_Edges.3dm (74.1 KB)
If you check the continuity of the edges using Gcon it will tell you that the edges are not connected.
If you zoom in and look at what is supposed to be a single Brep vertex you will find 2 points that end snap will find:
So, let’s suppose I want to split the basesurf (by isocurve at a point) which one of those snap points will it snap to?
Another problem is that neither of those snap points are the actual BREP vertex location. If you export the polysurface as .stp and re-import you will see what the correct edge definitions are. Those are the edges that Rhino 6 (and every previous version) will make.
The joined edge that Rhino 7 and 8 shows the user is not the valid joined edge that every previous version of Rhino made. How is anybody expected to accurately model when you can no longer rely on object snaps to show the true location of objects?
This is how far off the near snap is in snapping to the true location of an edge:
2 Likes
rhino seems to be plagued with these things its frustrating. another bad example was made about pipe command creating inaccurate geometry. i have a bad feeling about the trend.
2 Likes
Thanks Jim,
after closer investigation, I see that this is indeed an issue that is not limited to Fillets, but is caused by edges handled differently during Joining after V6. The simplest example being two surfaces that have an intentional 0.001mm gap, Joining gives the same issue you are reporting.
In V6 the edges are averaged out, In V7 one edge stays in place and Joining leaves a gap on the adjacent edge of the moved edge.
I’ve written up RH-74792 Edge handling in Join: Difference between Rhino 6 and later
1 Like
Thanks for taking this seriously. I hope you grasp how really deeply ingrained this problem is.
The real problem is the lack of good quality control. If Rhino had good quality control when a serious malfunction gets introduced it would be noticed immediately and fixed immediately. It would not linger in the code for years and years and lead to further malfunctions.
The thread where I first posted about this problem with Rhino7 edges has a model that illustrates perfectly what I’m talking about.
Here is the same model with clear instructions on how to reproduce the problem. Bogus_Edges.3dm (129.1 KB)
In this file you will find a cyan polysurface which you trim with a red curve.
After trimming with the red curve run the DupBorder command and it tells you that it produced 3 borders.
WTF!
How is that even possible? How is it possible to cut off a part of polysurface with one curve and turn the object with one border into an object with 3 disconnected borders? Two of the so-called borders are just tiny little lines.
And of corse Check command tells you its a valid polysurface
The last time Rhino was able to trim the cyan polysurface with the red curve was Rhino5. So it looks like this bogus trimming strategy was introduced 7 or 8 years ago and has been plaguing Rhino users ever since.
And that brings us to the topic of this thread…
How is it possible for the edges of a Brep to not have their end points at the Brep’s vertices? How is that obviously invalid construct even allowed to exist?
2 Likes
thanks @jim for sending the additional file, I made
RH-74830 Trimming creates a polysurface that has 3 borders where one is expected
just in case it a different problem.
I don’t have the answer to that I’m afraid, other than that it is allowed to exist because of a bug. Maybe @chuck has more to say about this. He’s currently investigating this issue and looking if the proposed fix by Mikko is safe to be made without breaking other things.
Thanks again for taking the time to report this.
There is a fix in the works for this - it is currently in V8, I don’t know what the propects are for V7, but for now here is a script that can help clean up those cases.
CleanupEdges.py (401 Bytes)
To use the Python script use RunPythonScript, or a macro:
_-RunPythonScript "Full path to py file inside double-quotes"
-Pascal
1 Like
OMG.
Remind me please, just how much am I getting paid to debug your crap???
I tried that script it didn’t fix anything in the example I posted above.
Apparently you never even bothered to see if the script you posted actually does what you claimed it does.
The surface (or polysurface it comes from) still has 3 borders after running your script. It still makes a BadObject when its joined to the neighboring surfaces, because nothing was fixed!!!
The problem is not that you come up with some kind of miracle band-aid that fixes some previous wound that Rhino has inflicted on the users. The problem is that Bob McNeel and Brian Gillespie stubbornly refuses to allow error checking in Rhino. The consequence of that monumental stupidity is that the developers are constantly wasting their time trying to paper over the errors that are bound to happen as a consequence of upper level management stupidity.
I’m sorry I can’t help you with your blood pressure issues but the little fixer script fixes the object in BadEdges.3dm which you kindly posted in one of the messages above.
-Pascal
I see, you blame the problem on my blood pressure and disregard the fact that your script does not work on the model that was under discussion when you interjected that your script would be a fix? Excuse me for assuming you knew what was currently being discussed.
Yes you are correct, your script does fix the edges on the model that was being discussed farther up in the thread.
But here is the thing - Every single polysurface in every single model created in Rhino 7 and Rhino 8 has those messed up edges. Are you seriously expecting every user to run your script on every polysurface every time any changes are made to those polysurfaces if they don’t want polysurfaces with messed up edges?
This is fixed in our internal builds, and will be most likely backported to a V7 SR according to my latest info.
FWIW: The Bogus Edges can in fact be fixed, by running the script on those polysurfaces, then duplicating the edges and then trimming.
Note that the upcoming fix will not automatically run through already joined polysurfaces, but in case of the Bogus Edges file, if you explode and join back each of the three polysurfaces, DupEdge the trimming edge of the red fillet chain and Join, it will trim the cyan polysurface correctly and DupBorder will only generate a single border.
This fix has no influence on JoinEdge, but to my knowledge, this command has always modified only one side of the join.
2 Likes
Maybe I’m not following your instructions, but that is not what I am seeing.
Here is what I did.
- Ran the CleanupEdges script on the cyan object then the orange object and then the lavender object.
- Joined the individual edges of the orange fillet string into one curve
- Trimmed the cyan polysurface with the curve from step 2
At this point the trimmed cyan polysurface produces only one border, but it is still a bogus boundary curve and when the 3 polysurfaces are joined into one the BadObject warning pops up and now I’ve got 3 surfaces with bad edges.
So yes running the CleanupEdges script on the cyan polysurface does do something that results in DupBorder producing the correct number of borders but it actually in a way makes the problem worse.
If you trim without running CleanupEdges script then you get 3 borders. Two of them are bogus tiny curves, but the 3rd is the correct border curve. If you trim after running CleanupEdges script on the cyan polysrf then you get 1 border but that border curve is not correct and then as a result of the bad boundary on the cyan object the join goes bad and you end up with 3 surfaces instead of one with bad edges. It is good that Check finds the badoject after joining. But the real problem never gets fixed because the problem originated in a previous action and not the one that produced the error message. Errors need to be caught when they happen, not down the road.
Bogus_Edges.3dm file I posted earlier is saved in Rhino 5 format. If you open it in Rhino 5 and trim with the red curve and then join everything works! The trimming produces a perfect border on the cyan object and joining the 3 objects produce a sound and valid polysurface (and that’s without even fixing the bad edge definitions on the orange fillet first).
If anyone at Mcneel was really interested in how the whole process got screwed up after Rhino version 5 they would trace through the process of trimming in Rhino 5 and see how it is doing correctly what current versions are getting wrong.
Jim, I’ve updated the YT regarding that file with additional info, thanks. In short: it seems this problem is introduced in V6. When exploding the cyan polysurface before trimming, Trimming with the red doesn’t generate the tiny edges.
Yes. You are right. Everything trims and joins properly if you first explode the cyan polysurface and then trim all the individual surfaces with the red curve.