Quilt merge intersect unexpected behavior

[tbraxton]

I have some basic geometry that when merged presents different solutions based on the order in which the merge reference quilts are selected. I am not able to explain this when considering the boolean logic resultant from the set intersection. 3 Unique solutions are available depending on the order in which the merge reference quilts are selected.

Can anyone offer an explanation as to why this is the case? See the video for a detailed explanation of my observations. Creo 7.07.

[Tdaugherty]

Maybe this is helpful? It seems that the first quilt in the list is the parent quilt (the one you're modifying). The subsequent quilts are the ones that you use to modify the parent quilt. In my experience, this logic seems consistent with the other merge commands in Creo (component operations > boolean > merge, data doctor merge).

http://support.ptc.com/help/creo/creo_pma/usascii/index.html#page/part_modeling%2Fpart_modeling%2Fpart_three_sub%2Fto_merge_more_than_two_quilts.html%23 

I recommend using the preview that is mentioned here (#3). It's very helpful to see what the merged geometry will look like. 

[tbraxton]

@Tdaugherty  thanks for the reply. The support article does not address what I am looking for. I am able to get the desired geometry in this case. The issue is that the resultant geometry is different depending on the order of the references and I do not think that should be the case.

I should add some context to this inquiry. It is driven by me being frustrated by some undesirable behavior in models when modifying them. I have recurring issues with surface normal vectors of draft features being reversed and the direction of merge intersections being flipped without user input. This results in lost productivity in the design process. Manual verification of these issues is quite tedious in the models I typically deal with.

I am trying to understand exactly how the algorithm works for merge (and draft) when determining the directions. If it is predictable then I can attempt to build the models such that they are more robust and avoid this unpredictable behavior when editing models.

Consider this geometry and compare the results to my test model above. There are 4 unique solutions here as I would expect and I can generate all 4 regardless of which reference is selected first.  i.e. if one reorders the quilts, the resultant  solution does not change. This is not the true for my test model in the original post.

[pausob]

Seems overlapping surfaces cause the issue?

This test model shows the results of the merge before / after reference swap:

 --> 

After "swapping the quilts" (used the edit references tool), result is quite different:

[pausob]

nevermind, same results if the quilts do not have overlapping surfaces:

vs

So @tbraxton , I suppose I don't know how you made your results independent of the quilt order in your example:

[pausob]

Ok, I think I understand it (more).

When you swap the quilt order, you have to edit the definition of the "side" to keep, but you should still be able to generate the same 4 solutions when using the "intersect" mode of the merge tool.

I believe the algorithm works consistently when both of your quilts are "closed".   If you have one that's open, then things get confusing and results are less predictable, as you illustrated in the video.  The desired solution is dependent on the pick order, and it also seems that it's best to pick the closed quilt as the 1st one if you want the result to be the "union", but I don't know.

I suppose from my experience, I just expect that after the modification of the skeleton, there's going to be work updating surface based models and one just has to deal with regeneration failures and manual rebuilding of features down to the end of the tree.

[tbraxton]

Open quilts do affect the behavior which is what led to me posting this issue. I am looking for an explanation of why. I will try to inquire with PTC R&D and post back here if I get an explanation.