This became a plugin induced crash when I tried to cast based on that.
File attached, a simple extrusion. extrude.3dm (40.0 KB)
Summary: select an edge component and watch the selection event. The correct RhinoObject selection is reported, but the subobject information seems to be incorrect.
To replicate, select this edge (shift ctrl left click, when not setting a breakpoint a simple selection and highlight is the result):
Clear the selection. Now, set a breakpoint to view the results and check values when it fires. The RhinoObject type is correct; the typeindex for the component is not. Extrusion isn’t inherited from Brep either so it may just be a typo. Any of the four edges of the surface produce the same result.
How are you selecting the edge? Do you have your own GetObject object in use, or are you just clicking with the UI?
A little background: Rhino’s object picker can quickly create proxy Breps from extrusions during selection. This allows extrusions to appear as Breps so the just “work” for commands that require a Breps.
Sorry, I thought I was pretty clear about exact steps.
I apologize for repeating myself, but I typed that up during the process of replication so I know it works.
and gave a screenshot to show exactly which edge I meant. Then deselect everything, slap a breakpoint on the event, and select it again the same way.
The only thing my plugin is doing at that point is watching events- no edits, no requests that Rhino solicit input from the user, etc. It just passively watches what the user selects and does a few display updates on the next idle event and the display conduits foreground update (both of which occur after the behavior I’m describing.
I described doing it twice: the first time so you get to see and verify that we’re looking at the same piece, because when you catch the event to debug the display hasn’t updated with the highlight yet, and the second with a breakpoint set to examine what’s passed in by Rhino.
So, quick summary: shift-ctrl-left-click to select that edge of the extrusion. Catch the object selected event that gets fired, or do some logging. The passed data reports:
an extrusion object (correct)
a Brep edge as the selected subobject (doesn’t seem to match the docs of the index types, and even if I try to interpret it as a Brep I have no way to access pieces of the Extrusion RhinoObject through a Brep Index type.
The reason I’m doing this is so I can report on details of the actual object, which seems to be the purpose of supplying the component index: The wall edge methods of the Extrusion which accept the component index.
My followup question (once this is working) is going to be a request to expose the other get methods to retrieve subobjects of an Extrusion (described in docs, but apparently not yet exposed as methods).
I want to get detailed information on the subobject clicked that I can match up to a tree I built up of the object and its pieces.
The way I’m supposed to do that seems to be to watch the object selection, pull the selected subobject list, and use the ComponentIndex to request the particular component of the object.
This works just fine for Breps, for SubD’s, and for PolyCurves as examples.
Extrusion just doesn’t seem to be honoring the convention and also needs additional support to make the other types of subobjects (beyond WallEdges) available.
IMO, the whole point of the object selection event is to give you a handle to and information about the selected object, which is not a Brep. Whether one wants to view information or edit it, the user doesn’t want a plugin to unnecessarily change the type of the object.
In any event, Rhino saying “Here’s a RhinoObject that’s an Extrusion and it reports that it has a selected subobject which is a Brep, and provides indexing information which is only usable in the context of a Brep which is not actually part of the document and can’t be accessed and wouldn’t have predictable relations to the components of the actual Extrusion even if the temporary Brep could be accessed” seems like a significant bug.
I understand the behavior with Extrusion objects is not what you expect. But it is by design.
I’ve just added a new Extrusion.GetBrepFormComponentIndex method to RhinoCommon that will convert a component index that identifies a part of an Extrusion to a component index that identifies a part of the Brep. Perhaps this will help you.
Extrusions are relatively simple, so that might work.
If I’m understanding correctly, you’re saying that:
A Brep form always exists for an Extrusion (I’m asking because Extrusion includes HasBrepForm to check whether one does) and this is always how subobject selection is handled: the Extrusion will never be represented as a nurbs surface or other item for subobject selection.
You just exposed a method which will, for a given ComponentIndex referencing a part of the Extrusion, such as (ExtrusionTopProfile, 0) return the corresponding component index of the equivalent Brep. The intended solution is that I walk through the handful of possible Extrusion type ComponentIndex(es) for the selected RhinoObject, convert them to Brep ComponentIndex(es), and compare each to what Rhino passes as subobject selection ComponentIndex(es).
(2) implies that the Brep creation is deterministic (indices will always line up, no chance of a different order because of internally shared curves or such)
If that’s correct, it seems like that would do it and I’m glad the change is minimal on the Rhino end!
I’m not sure if this is working correctly. File attached.
When the user selects the subobject shown (wall edge on the left), I run the following code. The result is a series of messages boxes saying:
0
1
1
1
2
-1
I had expected the 2,-1 pair but I would expect something like the following (not wall edge 0 matching Brep edge 1 AND wall edge 1 matching Brep edge 1)
0
0
1
1
or
0
1
1
0
if (ro.ObjectType == ObjectType.Extrusion)
{
//Rhino bug, reportes a BrepEdge instead of WallEdge
e = (Extrusion)ro.Geometry;
ComponentIndex eci, eci2;
eci = new ComponentIndex(ComponentIndexType.ExtrusionWallEdge, 0);
MessageBox.Show(eci.Index.ToString());
eci2 = e.GetBrepFormComponentIndex(eci);
MessageBox.Show(eci2.Index.ToString());
eci = new ComponentIndex(ComponentIndexType.ExtrusionWallEdge, 1);
MessageBox.Show(eci.Index.ToString());
eci2 = e.GetBrepFormComponentIndex(eci);
MessageBox.Show(eci2.Index.ToString());
eci = new ComponentIndex(ComponentIndexType.ExtrusionWallEdge, 2);
MessageBox.Show(eci.Index.ToString());
eci2 = e.GetBrepFormComponentIndex(eci);
MessageBox.Show(eci2.Index.ToString());
}
@dale See above… I thought I was supposed to use the indices for, as an example, the two wall edges, convert them to Brep edges with GetBrepFormComponentIndex, and then compare that to the BrepEdge componentindex Rhino is reporting as a user selection.
I seem to be getting the same Brep Edge index, 1, back whichever wall edge I ask for (0 or 1). I also asked for [2] on the off chance it might be zero based but that has the entirely rational reply of index -1.
So do you think I’m doing something wrong if I see the same index come back in the result of GetBrepFormComponentIndex regardless of which componentindex I feed into it while checking profile curves?
(except for the invalid one, that’s good)
I see a few possibilities- no attack or anything but knowing where this report stands lets me plan.
you replicate and agree it’s a bug, but it’s so low priority that you’re not going to log something
you don’t have time to investigate and it’s not important enough to log
you think I need to read the docs and figure it out
???
Any of those are fine, I guess- knowing which helps me plan.
I do have a hideous workaround in place (possibly slow and definitely silly): start guessing and just work through the list of Extrusion components until I get one that tests as identical to the corresponding Brep. The idea of applying that to geometrically complex extrusions doesn’t thrill me.
