cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Have a PTC product question you need answered fast? Chances are someone has asked it before. Learn about the community search. X

Parametric surface selection as model tree features to color assignment

Parametric surface selection as model tree features to color assignment

The way Creo deals with Appearances needs further improvements.

 

One of them, is the parametric colors assignment based on feature selection or even parametric surface selection methods susch as seeds and boundary. Currently we can use selection intent, including seeds and boundary to assign colors to surfaces. But this is done in a one time way, not as a parametric association between input and output. Meaning, if we redefine some features and new geometry is created, the new surface geometry is assigned the default color appearance, forcing the user to have to repaint whatever surfaces his features generate. Then, there is the problem of inconsistencies.

 

2. Copy Geometry feature now allows the user to control the copying of appearances from source geometry, which is fine. But if we use "Merge/Inheritance" or "Cut", we cannot control the supression (or not) of the appearances, meaning, the source model always controls color appearence, and we cannot force new colors in an inherited model, even sometimes its the intended behaviour. So, Merge / Inhertiance / Cut should also have the an option to: a) Copy appearances once, b) Copy appearance always c) Do not copy appearances.

 

3. Mirror geometry, weather be it Mirror Part Body, or Mirror feature, or Mirror Quilt, in general does not copy color appearances, even if this might be the desired behaviour. Allow the mirror feature/geometry/part/Body the option to mirror also the surfaces' color appearances, with the option of "Once", "Always", or "Never". Flexiblel modelling seems to be the exception, and when copying bodies or geometry in general, does keep the new geometry with the same colors as the original.

 

4. Patterened geometry, or patterened features, also do not pattern the source surface geometry color to the new instances, even when this would be the desired behaviour. Allow the option in patterend to copy the appearnces to the newly generated geometry surfaces.

 

5. Some generated geometry, should have the option to be color coded, such as hole geometry, with different colors for the threaded surfaces than the for drilled surfaces.

 

6. Body boolean operations currently also do not assign colors from a tool body to a destination body. We would like to use tool bodies as a way to transfer colors from the tool body to the target body, so that we would only need to color the tool bodies once, and have those colors applied always to a boolean cut (or more rarely, to a boolean merge or intersect operation). In the case of a boolean operation, if the colors of the source tool body and target body have coplanar surfaces that have assigned different colors, leave the option for the user to select if there should be surface simplification or not (eliminating co-planar faces and common edges).

 

Instead of having so many options to copy color appearances, maybe the better option is to introduce surface coloring as a regular feature in the model tree, where the user could Seed Surface select several surfaces at once to be painted the same color, and having this selection being parametric, and with a time stamp in the model tree to make the process more clear. Or at least, as a specialized feature tree (such as there is a special model tree inside the Style feature) in the Appearance menu, that would let the user reselect, or make Edit Definitions in his process of selecting those features to paint.

 

I think the adding "Coloring" as a regular feature in the model tree has some additional benefits if used in conjunction to another feature that I propose, the activation and deactivation of some surface modeling options on a feaure by feature basis, instead of a global part selection one. One of the localized options that could be inserted as a feature (a time stamp) in the model tree, is the "Accuracy" (which is an option in several CAD packages, namely, NX and Catia), and also the simplification of geometry. Creo always simplifies geometry whenever possible to elmiinate extra coplanar faces and uneeded edges, which is useful for 99.9999% of the time. But there are situations in which we may specifically want that a few features do not perform surface and edge simplification, to allow precisely to have coplanar surfaces with different colors, where the edges specify different coplanar surfaces (or even cylindrical surfaces in threaded holes), to allow coloring what the user wants as separate geometry, but which Creo always simplifies. In Creo Manufactoring Mold Cavity Module, the extracted parts have the option to be painted with different colors if the surfaces come from the reference model, or from the parting surfaces, which is the intended behaviour. But if the user has to make a feature in a cavity or core, such a draft, or an extrude, that "touches" or modifies any planar or cylindrical face that is split in two, and assigned the two different colors, the co-planar surface separation is removed and suddently simpified to a single surface, even though the user would want to keep tham color coded differently to have a clear edge separation in the parting line. There is a config.pro option that the user can select to turning on and off the "Simplyfing geometry", called "mold_split_dont_merge_same_srfs", which is useful, but only works as long as those extracted surfaces are never included in any of the Creo general modeling features, and another problem, is that this is a global config option. We should have the possibility to activate and deactiivate this behaviour (simplyfing geometry), but localized in a context, ie, activating this option in a "options change feature", then modeling a little bit, then deactivating this option in another "options change feature" to activate the normal geometry simplifying behaviour. Inside this "options change feature" we could also make a localized accuracy change, to be restored to the normal accuracy value later, and thus allow us to better control the behaviour of the software. With localized options defined as a feature in the model tree, and parametrized surface selection for assigning colors also as a feature, instead of the regular Appearances assignment methology, advanced uses would not be su frustrated and not loose so many time due to the current way that Creo deals with surface coloring. Regular users could continue to use current methods, but please allow powe users to assign the coolors, and control surface division and merge on a more granular manner, and in a more parametric way.

10 Comments
S_Edgenear
14-Alexandrite

I think that we should have the possibility to override inherited colors from a part that has it's geometry copied or merged/inherited from other part, and a feature would be the best way to do it. That feature and could have several sets of color assignments, just as the Round feature has several sets of references to apply the same radius value. This Appearance or Color feature would have several sets of the same color applied to several set of surfaces, using the existing several methods of surface selection (manual, loop, seed and boundary, intent surfaces, feature selection (coloring the feature generated surfaces to the same color, unless it's a hole feature, in which case it should allow the several parts of the hole to be color differently). Implementing this as a model tree feature would avoid having to change any existing UI interface, or clutter the existing features UI to add additional color selection tabs. This way, for most users and most workflows would preserve the existing UI, but also give power users in industries that require colored coded surfaces as is the case of the mold industry, the possibility to waste much less time manually color coding hundreds or thousands of surfaces, that sometimes get reset suddenly by the software uppon a needed regeneration.

S_Edgenear
14-Alexandrite

The color assignment as a feature in the model tree would also benefit users that need to specify material color depending on paint or plastic color, ie, the color assignments should be based on a parameter (that in reality is a four component R,G,B,A byte (0.255)). This new parameter type used to define the three color components and transparency, could then be included in family tables to specify that a component could have different paint colors based on a reference, or could be parametrically defined in Pro/program based on other parameters that the user selects. Currently, there is no way for we to have a component that varies only in color but is the same from a geometric point of view. The appearances Manager was created to allow us to specify different appearances for a part, and there is a master and default appearance, but we cannot use that mechanism to parametrically select wich appearance becomes active. So, I propose to have a new "Color" type parameters (4 byte component with range 0.255, as used in the graphics cards) for the R, G, B and Alpha channels), and allow us to parametrically specify those 4 sub-component values in a relation or family table (for instance, in a relation: WallPaint would be declared as Color type parameter. Then, in Pro/Program we could use this relation:

 

If PartColor ==" Red"

  WallPaint.R = 255;

  WallPaint.G = 0;

  WallPaint.B = 0;

  WallPaint.A = 255;

If PartColor ==" Green"

  WallPaint.R = 0;

  WallPaint.G = 255;

  WallPaint.B = 0;

  WallPaint.A = 255;

If PartColor ==" Blue"

  WallPaint.R = 0;

  WallPaint.G = 0;

  WallPaint.B = 255;

  WallPaint.A = 255;

endif

endif

endif

mneumueller
17-Peridot
Status changed to: Acknowledged

Note:
#6: is planned for implementation in Creo 10.0

Brndn4
9-Granite

In the spirit of overhauling how appearances work in this software, and while I agree with the modifications suggested above, I would also like to see the UI updated such that it's more user friendly. I also sometimes experience fatal errors during appearance manipulation and trying to assign colors by material has been borderline dysfunctional for as long as I've been trying to use it (Wildfire 5?). I actually believe there's another idea that touches on this stuff, as well.

 

With that said, I'd like to specifically throw an exterior surface coating option on the pile. Due to part evolution (cast -> machined -> painted or machined -> coated), I often select all solid surfaces during a part's evolution and select an appearance to replicate the real world. Similar to what has been noted above, there is nothing parametric about this. If something is modified or a feature created afterward, surface appearance then needs manually modified again. Being able to toggle only exterior surfaces (or selected surfaces) would be even more useful since not all surfaces receive the same treatment sometimes, which is always noted on a drawing, but the transition from model to drawing can by rocky for this kind of callout. The best solution I've found for this is using the Designated Area function, which produces its own challenges.

mneumueller
17-Peridot

@Brndn4  a workflow that you could apply in more recent Creo Parametric builds includes assigning a color to a solid body. That way new geometry will automatically inherit that color. In addition to a body color you might then want to apply colors to individually selected surface in the context of an appearance state. That will allow you to toggle between different schemes. 

We do understand the intend behind the above request, but I wanted to point out a few workflow options in response to the comments

S_Edgenear
14-Alexandrite

@mneumueller 

 

A default body color for a body, where all geometry generated will automatically inherit that color instead of default gray color would also work, and probably simpler to implement and users to understand. As long as individual surfaces could override the default body geometry color, I currently see no problem with this proposed solution. I think is really the best one indeed. To specify the default initial color of the body, the user would only righ click in the model tree and specify the default body color as a property, like the "Construction" property of a body, or the temporary "Transparent" toggle. Any additional "painting" of surfaces, would be done by the usual Model appearances dialog.

Brndn4
9-Granite

@mneumueller  Assigning a color to a body is a good idea and I look forward to testing that when I have an application for it. Especially in the case of removing material to then show a part as machined in those spots. Thank you.

 

Considering that I mostly work with parts that are coated now, the latter part of my post is more relevant to my coworkers and me. Regarding what you said, I have transitioned to using appearance states in the model for particular functions (like people not preferring a real-world color during design), but those do not translate to a drawing. I believe appearance states in drawings were mentioned in another idea. Still, designated areas are needed if only portions of surfaces are coated (highlighted), and I'm curious to know how much simpler any or all of these workflows would be due to implementation of other suggestions in this thread (as well as related idea implementation like appearance states in drawings).

S_Edgenear
14-Alexandrite

@mneumueller

 

Since default body color might a new functionality, could this new functionality architecthed in a parametric way, considering the possibility of defining colors as a 3 or 4 element tuplet parameter (R, G, B (and A for Alpha))? Currently the appearances mechanism does not have any way to specify colors as parameters, but to be able to change easily the color of a part, different to different ink or paint for coatings to be added to family tables, or specified via pro/program, it would be easier if the base color of the body would be able to be parametrically specified. The Appearances states can make a part havev different colors if we choose a different state, but we cannot relate automatically a different appearance state to a BOM or family table selection, or automation via Pro/Program. Also, the appearances funtctionality has many properties to define appearance, namely, ambient, shine, highlight, relflection, etc, which are superfluos to be defined in a parametric way or alter a BOM. We are only intereded in parametrically defining the base color (and to a lesser defree, transparency).

 

mneumueller
17-Peridot

@S_Edgenear : yes, that seems to be a useful enhancement to specify body colors parametrically. We have also a related item in the backlog to drive hole colors through the .hol table

@Brndn4 Just as an FYI. In Creo 9.0, you also have the "Divide Surface" feature that would allow you to divide a portion of a surface off into a new surface that could be colored separately.

S_Edgenear
14-Alexandrite

@mneumueller 

 

The hole table specifying the hole colors might not be the best idea. In big companies that can standardize hole colors for all the parts, it might be useful. For smaller companies that deal with multiple customers with each customer having is own idea of how the hole surfaces should be color coded to be automatically recognized by their CAM software, it is not the best solution. In this case, for each customer we work with, we would have to pre-select (for a creo session, or worst, for each hole) the hole table to be used for the holes to be color coded correctly. And if we try to do a standard library, which hole table should we use? For which customer? 🙂