Probably the best and simplest way to do this without having to create shrinkwraps and all this external references is to make family table parts of all the parts and assemblies that will change, create different materials with different appearances, and swap them out as needed. The parameter: "PTC_MATERIAL_NAME" (if I remember correctly) is a parameter column where each cell value can be swapped out in each instance in a family table, and then just swap out the part at the assembly family table level.
Depending on version, there's a glitch in the software where it doesn't work (WF3) or requires 2 regens (WF4) to work.
There's actually a glitch in Creo Elements Pro (Wildfire 5) where this ALSO isn't working right. The material appearance thing is really buggy (at least in M090 of Creo Elements Pro).
The other problem with using a family table is model size. If this is a small-ish assembly, tabulating each part and sub-assembly might make sense. But if Vassillis has hundreds of parts, he's going to have to create a real rat's nest of tables and instances to make this work.
There should be something easier... but unless we have a Pro/TOOLKIT guru out there somewhere, I'm not sure of a better way. 😕
Imagine that, a glitch......
I think in that case, the entire sub-assembly of 100 parts could have a material assigned to the assembly, that each individual part wouldn't have to swap. The model size isn't as big an issue as you'd think, it's actually just a text file within the generic.
I wish they WOULD fix the appearance of the materials, I was trying to make a big family table of fasteners and wanted to show versions of sizes in stainless, brass, black oxide, etc. In WF4 I SORT of got it to work, but had to regen twice, and it was still wanting to change the instances to whatever the generic looked like.
I think we still have the same problem with the double-regen in WF5. It doesn't pick up the material appearance change the first time... which is annoying.
And I agree about model size. What I meant was model complexity (as in number of components) not actually model size (as in file size).
In older versions of Wildfire I'd always receive calls that users' models had changed color. We had a default color map file (or appearance.dmt file) we always used. There was a rainbow of colors with whatever default color name Pro/E gave them (ie. : ref_color_###). Sometimes different product teams would create their own custom files, too... but they'd use the same default names. This lead to situations where we had TWO appearance files with different colors using the same names.
Invariably when we released a new version of Wildfire we'd put the default appearance file out there. Teams that had been using custom appearance files would call in to say their models had changed colors. This was because they were now using the default file... and the color names were the same. Reloading the custom appearance files straightened everything out.
Vassillis SHOULD have been able to use this! He could've had two files with different colors assigned to the same names. Toggling which appearance file was active should've recolored the models... yet it doesn't. I can only assume when color changes happened to us it was actually a BUG that has now been fixed. Now, colors seem to stay locked to the model they were assigned to (as it should be). But for at least one version that didn't happen.
I'd suggest calling PTC but you'd have to escalate your call a few levels until you reached an experienced support person. The first tiers of support personnel are going to give you the same answers we've given here. Maybe some old timer might know a hidden config.pro option that allows the appearance files to overwrite the model colors? Anything's possible I suppose.
Hey! Watch it with that "Old timer" stuff.....
WF4 sort of worked with the different material types, in spite of the douple regen thing. I wanted to make a whole series of o-rings with realistic colors, so that way we'd know at a glance if the appropriate material was being used for the right temp/pressure/medium. Doing the bolts was cool too so we'd know if the bolts that SHOULD be stainless instead of black oxide coated steel actually WERE stainless. I'd think that's important enough that they'd want to fix that soon. I mean, doesn't anybody besides US beta-test this software???? Didn't the developers test this before release? Don't even release the feature unless it works, guys, sheesh....
I wanted to do the exact same thing with our hardware. Having a visual cue to determine whether the correct material hardware was used would be very valuable.
Many people on this site render some very nice images from Creo and Wildfire. However, I've always felt that Pro/E's rendering capabilities were rather meager. Back in the early 1990's we had inexpensive desktop software capable of producing TV and cinema quality animations. PTC bought up CDRS and tried to merge some of their visualization capabilities into Pro/E (Photorender, Flythrough, etc). Still, many people back then used POVRay (freeware) to make better, faster renderings and animations of their models.
It'll be 2012 in a week. PTC has completely changed the interface of Pro/ENGINEER at least 4 times. Isn't it about time we had a really good visualization system that didn't require endless tweaking and fiddling to produce a useful rendering or animation? (And yes, I've seen the new Creo View tools and they're better... but we're still lagging behind our competitors in terms of rendering/animation power).
If I had one Christmas wish for PTC to grant, it would be for them to please stop messing with the user interface and work toward delivering a game-changing world-class visualization system for Creo.