tips backlog - parents of surface trims, especially mutual trims

Parent/child in surface models works a little differently than one might
expect. The last feature that adds to the surface manifold takes
'possession of the manifold. It is the only feature that contributes to the
manifold that you can select from the feature tree to 'show' or 'hide' the
surface body, and it becomes the name of the manifold in the surface bodies
folder.

However, knitting two surfaces, adding a fillet to a manifold (and possibly
other edits), while taking possession of ownership for the manifold, will
not change the name that comes up when you use a RMB>parent/child search on
one of its kids (specifically surface trims, but perhaps more).

Because it has an on-screen interface, to edit a surface trim you have to be
sure that the actual parent surfaces are 'shown' in order to pick new pieces
to keep in the edit dialog. To do this, you have to roll back above the
trim, show all the surfaces that contribute to the trim, then you can roll
down and edit the trim.
Because a review of the RMB>parent/child for the trim will not, in all
cases, give you the real name that you must find to 'show' any parents that
you might have hidden that now lurk anonymously in the tree, you have to go
a different route.

Tip1: To see if all of the parents of a surface trim that show in the
RMB>Parent/child dialog are the actual parents you need, RMB click each in
turn in the parent/child dialog, click 'go to...' , RMB click that feature,
and see if 'show' or 'hide' is an option. If so, you are golden and can
work with great piece of mind, knowing they will be easy to find when you
need to. If not, you are in a little doodoo.

Tip2: To find the names of the ACTUAL feature you need to show the manifold,
you can edit the surface trim and note the real names for the parents. It
is curious that SW shows different parents in the dialog than show up with a
RMB search.

Tip3: I go back and make sure to edit the name of the feature that 'owns'
the manifold by adding two asterisks to the beginning of the name - it sure
makes these critical features easier to find in the tree or in the list of
surface bodies.

 

Does this seem as stupid to other people as it does to me? This crap drives
me absolutely nuts when working with a lot of surfaces. There has got to be
an easier way!

Sure sounds like a bug to me. But, since I have never been able to
understand the logic of the naming convention for modified surfaces, I am
probably not a good judge.

Don't you end up having to go back and delete the asterisks all the time as
you continue modifying surfaces?

Jerry Steiger
Tripod Data Systems

 

Does this seem as stupid to other people as it does to me?
I am trying not to use the word stupid, but....Yes

I wonder if it is a bug or just a bad decision? Either way, it is clearly
not the way it ought to be.

Yeah, but its not like I do this for every surface feature. I need to prove
to myself that it's a feature that will get edited again in order to justify
the time. Some trims just neve get edited again, so why bother?
There was one surface trim on a recent model that would require editing
after every significant model change - it just couldn't remember what pieces
to keep. That was worth a few asterisks (and, as it turns out, I got fed up
and broke the trim up into a sereis of three less ambitious trims so the
feature wouldn't need to get fixed anymore)

 

Ed,

Could you get the same affect by using the feature's description instead of
adding an "*"? Then you could just use your tip from the other day: right
click the top of the feature tree -> tree display -> "show features
description"

Just a thought...

Todd

 

Ed:

As long as you're on the surface parent/child weirdness topic, I need some
pointers from you, if you can spare. How do you manage surface body
colors? Especially when you're knitting/trimming, etc. This whole
parent/child thing with surfaces leaves me a little confused. For example,
you can't control the color of a knit child if the parent surface features
have colors assigned, or something like that, I can't quite pin it down.
Do you have any clues about how this works?

And as long as I'm at it, what about solid body names and colors? How do
you deal with those? The bodies seem to rename, reorder and recolor
themselves as new features are added, so I find it difficult to manage
solid bodies if I have to do it in the folder (know which one to hide
without picking each one).

Any tips you've got on this would be appreciated.

Thanks again for sharing freely like this.

matt.

 

I'll be away for a couple of days due to a business trip, so forgive the
delay. I'll see what I have, but I'll warn you its not much. I will say
that I have had the same problems and questions as you. There is potential
hope - I ran into an interesting lead just the other day that begs some
scrutiny.

If YOU haven't been able to figure it out, I put MY chances somewhere
between slim and none. But hey, its worth a little time. Especially since
I suspect that the solid body naming weirdness may be linked to the
'split-part-feature-(which-creates-part-files)-losing-track-of-references-an
d-not-updating-the-child-components-properly' problem, which is a serious,
non-cosmetic issue

-Ed