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.

Reply to
Edward T Eaton
Loading thread data ...

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

Reply to
Jerry Steiger

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)

Reply to
Edward T Eaton


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...


Reply to

All of these tips have been interesting to me, and a few of them have cleared up some issues for me. Thanks for taking the time.

On this issue I have some questions. Does it seem like re-ordering the feature tree doesn't seem to work in regard to surfaces? I especially see this when split lines are involved. I'll be going along and see a surface that I wish I had split. I'll roll back and create a sketch for a projected split line and split the subject surface. Then roll forward and try to use this split surface and find that it is greyed out. I'll check parent-child stuff and all will seem in order except that SWX won't access features in the way I have re-ordered them.

If I thought I could explain this to my VAR, I'd try to get it reported as a bug. I think that is why some of this stuff slips through the SPR system. It is so blamed difficult to explain, that we don't bother.

Thanks again for all of your insights.


Reply to
John Kreutzberger


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.


Reply to

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


Reply to
Edward T Eaton

I've been seeing something similar in that I'll roll-back, create a splitline, and the surface won't split all the way. It's kind of hard to explain... you can select it, but you can't see it or add relations to it. You have to create it higher in the tree for it to work properly.

Mike Wilson

Reply to
Mike J. Wilson

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.