Retain Part / Surface ID.

Sebastian_Tymoczko

Model revisions that occur higher up in the feature tree often change the surface ID of parts / surfaces, resulting in subsequent feature tree failures. 
Example: I roll up and split a surface. The split then changes the part ID causing any existing solid extrudes that were intended to be added/ removed to lose their reference and need to be relinked.

This happens way too often and rolling through 600+ features again every time the surface ID changes is frustratingly time consuming. 

Send help! 

GWS50

I also come across this time consuming issue quite a lot. Having to re-assign the part to boolean to because the part ID has changed is tiresome. Is there a way to perhaps re-assign the the first broken ID and then have that be passed down to the other commands in the history tree. After all the same ID is there it's just not recognised.

shawn_crocker

I have been bothered by this often when creating configured parts.  Sometimes I will encounter and arrangement of configured features that will cause the part to have a new ID.  Then in assemblies, The part errors out because the configuration selection made a new ID.  It would be cool if we could create a bunch of user defined ids similar to equations.  Then, at any point in the feature tree we could apply a special feature that would allow you to select a piece of geometry and then allow you to select which ID to apply from your list of premade IDs.  This way we could actually name the ID something meaningful and have control over it instead of having to MacGyver a way to get the system to accidentally apply the right id.

lougallo

@Sebastian_Tymoczko I am not going to mark this as an improvement since we are already working on ways to make things more stable in the part studio wrt ids.  Splits, booleans etc can cause these to be reassigned based on how our query system works.  We understand this can cause pain at times and are investing time and effort into stability.  Thanks for the post.  It validates our expense in effort in this area.

nick_papageorge073

I'm coming from proe/creo... This would happen all the time there. When merging two quilts, the resultant quilt would take the id of one of the quilts. Later in the tree if that number is lost, the features relying on that number will fail. The solution in that software was the order of selection of the quilts. Whichever quilt you select  first, the merged resultant quilt takes the id of that first quilt. Knowing this, as you merge quilts going forward, you can always select the one most likely to stick around to make the model more robust and less likely to fail when making changes.

IDK if OS does similar. I do notice when performing a union operation, you can re-order the selection inside the window. Does the order of that selection matter in OS?

NeilCooke

@nick_papageorge073 - yes order does matter with Boolean and I think it is the same with all CAD systems - there has to be a "parent" and it is the first body in the list.