Determining number of vertices on a bRepFace with features.

[pludikar]

Could someone enlighten me?  I want to find the number of vertices on a face from the API - specifically the body on the right (purple).  It's a simple body with a corner cutout by extrusion.

Both examples show top face bRepFace.vertices.count => 4.  I was expecting the right body to show 5.

bRepFace evidently refers to the original face and not the consolidated one.

It's clear that internally F360 can correlate face correctly with the final body, but it's not obvious how to get the same information via the API.

How do I get what I'm looking for?  What am I missing?  

I'm getting count information by putting  break into a selectionEventHandler when a face is detected.  Then querying the resultant selected entity in Spyder.

Regards

Peter

[pludikar]

Interestingly when I changed the selectionFilter to 'PlanarFaces', (originally I used 'Faces') it gave me the right result.  As both were referencing the same face, I'm curious to know if this is expected

Peter

[burzins]

Hi Peter,

The top and bottom faces of the body on the right should each have 6 vertices, and the other 6 faces should each have 4 vertices.  Please share your code.  Maybe a face other than the one you intend is referenced.

Steve

[pludikar]

@burzins

Hi Steve,

Attached is the add-in folder with my sources.  I've also added the sample to use the program on.  It's still a work in progress, and needs tidying up.  I'm also having trouble setting the right proxy context - the program mostly works, but I can't get holes to generate properly in components - it has to be a context thing - however, I'll post that another question if necessary. 

It's a bit weird - I copied over the salient loc to another add-in I created and I get the correct results.  It's entirely possible that something hiccuped in the cache, because I'm still a way to go to get up the last part of the learning curve, I suffer the occasional crash which could leave residual bits in memory that hasn't been gc'd.

It's always good to have another pair of eyes on things like this.  I appreciate your time.

Peter

[burzins]

Peter,

After some testing, I'm not sure whether it matters that the bodies are in components.

Be sure to set holeInput.isDefaultDirection to True.

Sometimes after the addition of a hole, face.isValid becomes False.  After that point, none of the holes for the remaining edges are added.  I don't know what is causing this.

Steve

[pludikar]

@burzins

Hi Steve,

Many many thanks.  Setting holeInput.isDefaultDirection = True has certainly made a difference.  

I think the problem with the face validity error is due to the location of the hole.  I'm trying to set it's center in the middle of an inside corner, so that both edges are just scalloped out enough to expose where the original corner edge would have been.  I suspect that what is happening, is the first hole changes the face loop profile (adds an arc to the loop) - because the loop changes this probably then invalidates the face, so subsequent attempts to reference the original face for hole positioning won't work.  I'll have to see if there's a work around somehow.  If I position the holes totally within the face, the problem doesn't arise.

I definitely have either a corruption somewhere, or there's some residual add-in data that hasn't got cleaned out - my original add-in (even after subsequent changes) will reset the selections if I move the cursor off the clicked face and over another.  This doesn't happen with a similar fresh add-in, that uses almost identical code.  I suspect there has to be a cache lurking around somewhere, but I don't know where (yet).

If I move a component, and capture its position - the add-in fails.  But it seems the occurrence doesn't fully adjust for the new coordinate space.  I'm not sure if this is intentional, or if it's a flaw.

Anyway, many thanks again for your input.

Peter