Hmm... I've seen model colors change before when a different color map file was loaded (back at Wildfire 2 and 3). I forcibly TRIED to make that happen just now in Creo Elements Pro (Wildfire 5) using two different appearance files and couldn't make it happen.
It's supposed to be that colors are saved with the model. But in the past it was possible to name your colors, load a new appearance file, and then OVERWRITE those named colors with new ones. I've seen this change the model colors on the screen before in WF3... but I can't make it happen now. This makes me wonder if the instances I witnessed in the past were bugs... or if I am mistaken that it was ever possible in the first place.
I'll keep digging... stay tuned.
Yuck. Here's what I found:
I was able to swap colors on models by applying colors to my materials and setting the config.pro option mat_assign_appearance to yes. Using a simple dummy material, I assigned a color of blue giving it a name "material_color". I saved this color from the MATERIAL input window as global_blue.dmt. The global appearance file supercedes the normal model appearance file... so I used this to help achieve the color swapping effect.
I went back to the same material, changed the color to green but kept the name of the color set to "material_color". From the MATERIAL input window, I saved this appearance file as global_green.dmt. Now I have two color files assigned to the same color name.
When global_green.dmt is active, the color called "material_color" is green. When I load global_blue.dmt, the color called "material_color" is blue. I can swap between the two color files and my model changes color (not quite automatically but close enough). In practice, this would be awfully tough to achieve.
I tried a variety of other ideas. I tried UNASSIGNING all materials hoping the model would revert back to it's original color. It did not. I tried saving two appearance files with different color palettes and loading them over top of each other (in an attempt to overwrite the colors). This failed.
In fact, loading the same named color over itself caused Pro/E to throw out a message warning me I was changing my color palette. I accepted this and told the system to overwrite the old palette with the new one. Yet the OLD palette stayed active until I physically clicked on each color from the palette. Once I clicked on the old colors, they disappeared and the NEW colors popped up. Weird. Definitely buggy... very buggy.
I hate to leave people with a NON answer and no possible solution... so I have to give you something. In a pinch, try these:
- Create a new assembly ONE LEVEL HIGHER than your current top level assembly. Add your top assembly as the only component. Color your assembly there for final rendering. This allows you to leave the colors alone in your current top assembly and create a different look to your part for rendering.
- Assign a string variable called "render_color" to each part in your assembly. Use that parameter as a selection device using the FIND tool. You could select all objects with the "render_color" set to "blue" easily using the find tool. Apply your rendering colors this way to save time. You might even be able to use a mapkey to speed this up.
- Play around with the material appearance assignments. they aren't great but they do offer some hope of toggling colors at the part mode quickly (when they're working properly... I had a few issues with having to re-issue the commands several times before the system responded).
Sorry I don't have better advice... anyone else got anything?
there is a way to do it which i often use, make seprate part/assembly for rendring. all u have to do is to copy all surface and publish thoes sufaces and call publish geometry in new part by copy geometry. This way u can keep both color schemes... and dont worry about changes that u will made in part or assemble it will automaticaly update.. try it and let me now
Message was edited by: DalbeerSinghSohal
There are some shortcuts to using this technique Dalbeer is suggesting.
You can create a Shrinkwrap which will automatically gather all solid surfaces of your assembly and all sub-levels (or selected sub-levels) into one object. If you create an External Shrinkwrap, you can keep the new model separate from the existing assembly while preserving associativity.
To do this, you have to create your shrinkwrap from the Insert>Shared Geometry>Shrinkwrap menu. You can't do it properly using the File>Save a Copy menu to save your shrinkwrap.
There are problems with this technique, though. In Dalbeer's method, you create MULTIPLE copied surfaces. Each one represents one part from your assembly. In my method, you avoid having to copy surfaces manually, create publish geometry, and then create external copies. However, the downside is that my technique creates ONE copied surface with sub-features representing each part in the assembly.
Both techniques appear to give the same result. Mine is faster and more automatic but with Creo Elements Pro (Wildfire 5), it's harder to assign colors to my copied model. Dalbeer's is easier to color because he has individual features. Mine are all lumped under one feature which still should be easy to color but the software really fights you when trying to select surfaces.
Ideally, you'd combine the two methods. If you make one separate copy/shrinkwrap feature for each component in your assembly, you'll avoid the selection problems my method has. If you use External Shrinkwraps or External Copy Geometry, you'll avoid carrying copied surfaces and publish geometry in your top assembly.
None of these suggestions gives us what we really need... "Appearance States". We need the ability to keep multiple appearance settings in the same model and toggle between them. We have Layer States, Simp Reps, Style States, and a ton of related features but we don't have Appearance States yet and that would be the best solution to your problem.
Dear Brian and Dalbeer,
thank very much you for your time and effort.
Yes, both of your techniques can give some results but unfortunatelly they are not so easy to use. Imagine how much time you need on an assembly with some hundreds of components...
On the other hand, I believe that it's not a bad idea to have the ability, to define various "Appearance States" for a model.
PS. What do you think about a poll questioning about the necessity of this functionality?
I totally understand that neither of these techniques is giving you the function you need. For a few parts, they work well enough... but for a large assembly they're just too time consuming. We need Appearance States. Perhaps we can convince the powers that be at PTC to develop this for us.
I wish I had a better technique for you. Short of taking the files into a 3rd party rendering package for processing, I am out of ideas.
However, you really SHOULD be able to put a color parameter on each model and use that as a selection filter for coloring. You can add parameters to parts and subassemblies right from the model tree... making it very easy. You could have preset values for your color parameters making them easy to assign. You should then be able to use the Find Tool to gather components by color code. Yet this doesn't work correctly. It only seems to work for ONE level of an assembly when it should work recursively throughout your entire model. I'm fairly certain this is a bug in the Find Tool because it makes no sense that this technqiue doesn't work. In theory, this technique could solve your problem... a few mapkeys, a color parameter, and clever use of the Find Tool is a great answer. Not sure WHY it isn't working though.
It's certainly frustrating!
Hi, i suppose you have already tried this technique:
I have used it sometimes but would like Pro/Engineer to offer a feature to handle this.
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.