This is an old bug and its been reported before, but its an especially egregious example of just how bad the quality control is at the Mcneel company.
Extending the edge on the enclosed model creates a Bad Object. ExtendSrf_bug.3dm (49.3 KB)
But worse than that, Rhino fails to identify it as a Bad Object. After extending you can run DupBorder and then the Bad Object warning pops up. I’d like someone at McNeel explain how the borders of a polysurface can be a Bad Object but the Polysurface itself is deemed not to be bad?
This bug has been around ever since they made it possible to extend surfaces that are joined. That would be a nice feature if it could be trusted to not trash the users geometry.
So the prudent user has to continue to do it the old school way of extracting the surface then extending then joining it back to where it came from. If the user can do it correctly, why can’t McNeel?
I installed the latest Rhino (8.5.24047.13001) and Extending the surface at that edge still creates a Bad Object. And in addition Rhino still fails to identify the object as invalid.
Rhino does however identify the border curve (DupBorder) as an invalid curve. Seems like a no-brainer to identify an object with an invalid border as an invalid object.
This bug has been around since around 2018 and the obvious reason for a dumb bug like this to persist for so many years is because the built in mechanism for checking error fails to do its job. I have seen this bug reported by others, so that mechanism for catching errors isn’t working very well either.
And here it is almost 3 months later, after Pascal said this has been fixed, but its still broken.
Rhino still makes a bad object when trying to extend this
Rhino still fails to detect that the object created by extendsrf has an invalid boundary definition.
Folks at Mcneel better wake up.
When they can’t acknowledge and fix things as simple as this after 6 years of compalints, its a clear sign that they are circling the drain…
Can you please
a) confirm you are also using the latest Rhino 8 service release 8.6 (which was released two days ago) and
b) try again. If you are - as you write above - still experiencing problems, then please give more details about how you are able to produce a bad object.
Thank you for taking the time to look at this, but please read what I have written.
This is the 3rd time I have posted to this thread and nobody at McNeel seems to be able to read what I have written each time. I know that Rhino calls the result a valid polysurface, but that is one of the bugs I am reporting.
One of the two bugs this file demonstrates is that ExendSrf turns a valid polysurface into an invalid polysurface but Rhino fails to warn the user that it is a BadObject. The failure to identify obviously defective geometry is the very reason that Rhino continues to create such defective geometry.
If you run Dupborder on the polysurface after using ExtendSrf, Rhino will correctly indentify the border curve as a BadObject which it obviously is.
As I wrote in my first post:
I am currently using Rhino8.7, but I have tested this file on 8.3, 8.4, 8.5, and 8.6 since I first reported this bug.
I gave the details months ago. Run Dupborder command on the polysurface after using ExtendSrf.
But the main point is that catching that error after the fact is obviously not “good enough”. The reason errors like this proliferate in Rhino is because they are not caught when the error occurs. Waiting until some downstream operation blows up is entirely inadequate. This thread is proof of the fact that the failure to identify obviously bad geometry and warn the user does nothing but allow McNeel to ignore bugs.
Thank you for taking the time to explain, and sorry about having to repeat yourself. I’m afraid I did not pick up on the error produced in DupBorder, so thanks for pointing that out.
The problem seems to stem from using the option Merge=Yes. If you were to use Merge=No, the problem does not happen, but you end up with a separate surface. Explode, MergeSrf, Join will get you where you want to be, with no faulty border after this workaround. The option Merge=Yes should just work though of course.
What seems to happen is that after ExtendSrf the internal edge is suddenly a naked edge. That shouldn’t happen. I’ve added an item to the YouTrack bug tracking system (see link below). This only means that it is known internally, and someone will look at it at some point in the future. I cannot promise more than that I’m afraid, and I understand your frustration with the process.
The error is not produced in DupBorder. It is produced in extendsrf.
Well of course that doesn’t produce the error. Using Merge=No option tells Rhino to leave the input geometry unaffected.
That is an absurd workaround. First of all that is not what I want. I want a simple planar surface after extending, like the surface I started with was. I do not want patched together geometry that resembles something created in Dr Frankenstein’s lab.
I’m well aware how to workaround this bug*. I have been doing it for 6 years. This might be the first report of this bug for Rhino 8. But other users and myself have posted about this bug in Rhino6 and Rhino7.
The reason simple to fix bugs like this linger in Rhino for so many years is because the command that is supposed to detect such errors fails to do so. The fact that the Check command fails to detect this as a bad object is a serious bug that nobody at McNeel is willing to acknowledge.
*the workaround is to never trust Rhino to extend a joined surface. Extrract the surface then extend then join it back
Windows 11 (10.0.22621 SR0.0) or greater (Physical RAM: 16GB)
.NET 7.0.0
Computer platform: LAPTOP - Plugged in [100% battery remaining]
Hybrid graphics configuration.
Primary display: Intel(R) UHD Graphics (Intel) Memory: 1GB, Driver date: 7-8-2020 (M-D-Y).
> Integrated graphics device with 3 adapter port(s)
- Windows Main Display is laptop’s integrated screen or built-in port
Primary OpenGL: NVIDIA GeForce RTX 3070 Laptop GPU (NVidia) Memory: 8GB, Driver date: 12-6-2023 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 546.33
> Integrated accelerated graphics device with 4 adapter port(s)
- Secondary monitor is laptop’s integrated screen or built-in port
OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)
Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High
Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 12-6-2023
Driver Version: 31.0.15.4633
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 8 GB
Rhino plugins that do not ship with Rhino
C:\Users\Anto\AppData\Roaming\McNeel\Rhinoceros\7.0\Plug-ins\Bella (813de3fb-18eb-405f-bfcd-b0b4d3da91fb)\23.6.0.0\bella_rhino.rhp “Bella” 23.6.0.0
C:\Users\Anto\AppData\Roaming\McNeel\Rhinoceros\8.0\Plug-ins\KeyShot12RhinoPlugin (78243fe3-17a0-4865-b713-88b4c224c48c)\1.3.0.0\KeyShot2023RhinoPlugin\Rhino 7\KeyShot2023RhinoPlugin.rhp “KeyShot12RhinoPlugin” 1.0.0.0
C:\Program Files\Cyberstrak\R7\CS_ModelingPlugIn.rhp “Cyberstrak Modeling PlugIn”
I see. I do get something very weird with this new file:
I had CheckNewObjects turned on as well and still did not receive a bad object warning; and fyi for McNeel staff, same SystemInfo as my last reply.
I didn’t realize DupBorder was only supposed to result in the closed curve. If it’s recognizing the shared edge as a naked edge despite the surfaces being joined and then still creating the open curve based on a perceived naked edge, then yeah, I think that’s buggy. Good catch!
EDIT: I turned CheckNewObjects on and went back to your first example file and yep, it’s buggy.
Odd that Rhino doesn’t catch it as a bad object. But oddly enough, exploding and rejoining the surfaces, then running DupBorder does not result in the extra invalid curve. So the issue does seem to be related to the ExtendSrf operation.
Apparently, Rhino developers also do not realize this.
When ExtendSrf extends a surface that is part of a polysurface with one closed border the result must also have only one closed border for the result to be valid.
That is an undeniable fact that apparently Rhino developers don’t know or don’t care if they do know.
Yes that fixes it in the case of the first file I posted, but in the case of the second file it makes the geometry even more screwed up.
This is just another example of a feature that was half-baked when it was implemented and has never been fixed.
Prior to about 6 years ago Rhino did not allow users to extend joined surface.
So back then the user had to extract the surface and extend it then join it back. The new feature was supposed to do all that for you, but it has never been reliable and never fixed to make it reliable.
