Who owns the quilt?

2008-01-09_063142_who_owns_the_quilt_wf2_.prt.zip


This has been a thorn in my side and I stumbled on the 'fix'
which I hope hasn't been hanging around here or in Help all
this time and I just never saw it.


Note that the trim feature owns the quilt (color, Hide, etc.)
To correct ...
_ Trim Feature -> Edit Definition.
_ Flip Direction until 'keep both' is active.
_ On the References tab; click Swap.
_ Enter Verify (preview) mode and cancel back out.
_ Flip direction once more & OK.


If you've already created dependent features be prepaired for
some Resolve mode time (or so I expect, haven't been faced
with that yet).


I never understood the cause until stumbling on this. A 'flag'
is being set if you ever flip thru the split option and is never
reset. Bug, version specific, follows some obscure logic? I
would never(?) expect a Trim feature to own a quilt (or curve)
unless both sides were kept.

Hi,

As far as I know, it's simply the ID of the first element you select, which is kept (which owns the quilt) in case of trimming, melt operation and such. This can be used to deliberately set how e.g. melt operations behave when the referenced quilts are changed. I always keep the ID of the more important surface. E.g. If I have a snap hook geometry as quilt and a design surface to trim the hook with, I always select the hook surface first, because if the design fails or is exchanged , there is a good change not all following features for the hook (e.g. chamfers, radii, drafts) fail. If you have kept the design ID and exchange the design surface, everything dependant on this melt feature is guaranteed to fail, because the referenced ID doesn't exist anymore....

I can't reproduce your problem here (WF2 M230). The resulting quilt alway has ID5, regardless of which side I keep.

Nevertheless, ProE has a very annoying way of even breaking these kind of features when somewhere up in the tree other things have changed, which have NOT influenced the quilts IDs. If you really haven't changed the IDs of the referenced quilts, just simply edit the definition, flip the order of the quilts twice (to get the exact selection order as before, do not flip the directions) and somehow now the feature will work again .... it's magic ...

> I can't reproduce your problem here (WF2 M230).
> The resulting quilt alway has ID5, regardless
> of which side I keep.


Super deal. If you can ...
_flip once (keep second side)
_flip again (split & keep both)
_flip a final time (back to side one)
... and the extrusion still owns the quilt
someone else must have thought it was a bug, too.


> .... it's magic ...


Yes, I see that pretty frequently, too. Have found
a way to trigger it if the conditions (whatever they
are) that cause it are present. I, almost exclusively,
use absolute accuracy and when something (trim,
intersection, etc.) isn't working as I think it should
will vary the accuracy by a factor of .25 to .5 and
rethink strategy based, in part, on what happens.
Anyway, I've found that changing accuracy by a minute
amount (i.e. from .001 to .0011) will trigger the lost
reference failure. Neither canceling Insert Mode nor
Model Player regens will trigger it, IIRC. I presume
any change in Rel Acc will do the same thing.
Conjuring on it a bit; using rel acc, effective accuracy
changes with any feature change that influences bounding
box size. If you're using rel acc you might be seeing it
more often than I do(?).


Many Thanks for your input. Appreciated.