SelVolumeObject misses objects - bug

Rhino Rhino for Windows
1

SelVolumeObject misses objects and needs a tuneup. I’ve encountered the problem when splitting curves with a box or plane, and then use the box as the selection volume to separate the curves into two layers. The curves are created by contouring a fine mesh.

Example: SelVolObjDC01.3dm (2.7 MB)
Start with the unsplit curves in the Unsplit Curves layer.
Use the box to split the curves. Result is in the Split Curves layer.
SelVolumeObject and select the box as the selection volume.
The selected curves are in the Selected Curves layer.
The remaining curves are in the Unselected Curves layer.

Obviously some curves within the box were not selected. Remember that the original curves were split by the box so they should be entirely within the box. SelVolumeObject is missing some objects which it should select.!

Added: Or perhaps Split needs the tuneup. I assume curves with a plane is “exact”.

SelVolObjBug1|544x500

2

Hi David - something is amiss with that box - if I explode and rejoin it, the selection is as expected, here - or make a bounding box of the box and use that as the volume - also works.

Can you try?

SelVolumeBox also behaves a little oddly… still poking.

-Pascal

3

The box was created using the Box command. Started in front view and placed to opposite corners of the first face on the Cplane, then switched to top or right view to pull out the volume. I’ve made several volumes that way over the last several days which have had the same problem.

I exploded the selection box and rejoined it, and the results are the same.

Created a bounding box around the box I created. Results are the same.

I had forgotten SelBox. I tried it and the results were the same.

I created points on ends of the curves should have been selected but were not, and then checked the coordinates of those points using List. The y coordinate of the those curve end points are negative by order of E-16 or E-17, so basic double precision floating point round off error.

Absolute tolerance is 0.001 which is what I use almost always, and has not been changed since the geometry was initially created.
SVOtolerances

Rhino 7 SR5 2021-4-10 (Rhino 7, 7.5.21100.03001, Git hash:master @ 2cd158094b595f6400479d7cbe511454b6149527)
License type: Commercial, build 2021-04-10
License details: Cloud Zoo

Windows 10.0.19042 SR0.0 or greater (Physical RAM: 16Gb)

Computer platform: DESKTOP

Standard graphics configuration.
Primary display and OpenGL: NVIDIA GeForce RTX 2080 Ti (NVidia) Memory: 11GB, Driver date: 4-8-2021 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 462.31
> Accelerated graphics device with 4 adapter port(s)
- Windows Main Display attached to adapter port #0

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On

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: 4-8-2021
Driver Version: 27.21.14.6231
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 11 GB

Rhino plugins that do not ship with Rhino

Rhino plugins that ship with Rhino
C:\Program Files\Rhino 7\Plug-ins\Commands.rhp “Commands” 7.5.21100.3001
C:\Program Files\Rhino 7\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 7\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 7.5.21100.3001
C:\Program Files\Rhino 7\Plug-ins\RhinoRender.rhp “Legacy Rhino Render”
C:\Program Files\Rhino 7\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 7.5.21100.3001
C:\Program Files\Rhino 7\Plug-ins\rdk_ui.rhp “Renderer Development Kit UI”
C:\Program Files\Rhino 7\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 7\Plug-ins\RhinoCycles.rhp “RhinoCycles” 7.5.21100.3001
C:\Program Files\Rhino 7\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 7.5.21100.3001
C:\Program Files\Rhino 7\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 7\Plug-ins\Displacement.rhp “Displacement”

4

@pascal I may have found what determined which curves were selected and which were not.

The y coordinates of the ends of the selected curves are positive (ie inside the box) by order of E-16 or E-17. The y coordinates of the ends of the curves which were not selected but should have been are negative by order of E-16 or E-17. For both sets of curves this is the order of accuracy of double precision floating point numbers. It looks like SelVolumeObject and SelBox are using an exact test for whether objects are entirely within the selection volume.

Added: The relevant corners of the box I created are exactly and precisely at 0. I assume when a curve is split there is a routine which determines the parameter value of the curve associated with the intersection of the curve and the splitting object, and then creates the new end control point by evaluating the curve equations for that parameter value. The limitations of double precision floating point numbers mean that the calculated coordinates can differ from the exact solution by the amount seen in these curves.

So what may be needed in SelVolumeObject and SelBox is a tolerance of E-15 or so added to the test to see if an object is inside the selection volume.

5

Yeah, I’ll ask the developer to take a look - it does seem to be numerical fuzz because I can see the selection both work and not work in different attempts. My guess is this will be a hard one to get right.
In fact, if I start from your blue, unsplit, curves, split with the box and SelVolumeObject, the correct curves are selected.

-Pascal

6

Important lesson - Do not assume that splitting with an closed surface/polysurface and then using the same closed surface/polysurface as the selection object will resutl all the split objects inside being selected.

My current workaround is to shift the box used for splitting by a small amount after splitting. This works with only one face of the box used for splitting. A more general workaround would be to offset the selection object by a small amount if the object.

7

This continues to be an annoyance.