Part Appearance. Can we configure it like a feature, not a property?

AlexPitt

Hi, (this may be an improvement request - however...)

The fact that part colour/appearance is a property (like meta-data) and not a feature (like extrude height) means that it must be configured in the "configured properties" table.  

For colour stability across a configured part, every permutation must be resolved in this table making the number of rows a factor of the other config tables present in the part studio.  This has the potential to be a huge number of entries.

It would be great if it was possible to configure colour/appearance in an independent table in a similar way to part features.

Kind regards,

Alex Pitt

Fig 1. Two independent tables each with 3 configs. Results in 3x3 = 9 permutations.

Fig 2. In "Configured part properties" (right), each permutaion must be defined in the table to maintain colour stability.

AlexPitt

...so fixed the above by simply adding  a new "Red2" colour config (which did work) and deleted the original faulty "Red" config. (below shows the renamed Red2 colour config). 

Thanks Neil, this is exactly what I was looking for! I'll try it with some more complex assemblies.

EvanReese

Inspired by Neil's snippet, I made this Part Color feature. Notable additions and differences.

1. RGB ranges go from 0-255 like the native edit appearance UI (and other things I'm used to like Photoshop). I left alpha as 0.00-1.00 to match the edit appearance UI, even though I'm used to 0-255.
2. The value bounds are custom so it limits only to relevant entries
3. there's an option to use a hexadecimal code, so you could copy and paste it in if you know the one you want.
4. it has an icon.

NeilCooke

This simple FeatureScript can be used to set a Part's color and then it can be configured:

annotation { "Feature Type Name" : "Color Part" }
export const colorPart = defineFeature(function(context is Context, id is Id, definition is map)
    precondition
    {
        annotation { "Name" : "Parts", "Filter" : EntityType.BODY }
        definition.parts is Query;

        annotation { "Name" : "Red" }
        isReal(definition.red, POSITIVE_REAL_BOUNDS);

        annotation { "Name" : "Green" }
        isReal(definition.green, POSITIVE_REAL_BOUNDS);

        annotation { "Name" : "Blue" }
        isReal(definition.blue, POSITIVE_REAL_BOUNDS);

        annotation { "Name" : "Alpha" }
        isReal(definition.alpha, POSITIVE_REAL_BOUNDS);
    }
    {
        setProperty(context, {
                    "entities" : definition.parts,
                    "propertyType" : PropertyType.APPEARANCE,
                    "value" : color(definition.red, definition.green, definition.blue, definition.alpha)
                });
    });

AlexPitt

Thanks Neil,
I'll copy/paste this into a simple doc and have a play. Still a little intimidated by feature script but hopefully this will help me get a grip!
Much appreciated!

AlexPitt

It works! Except for the first colour config...

AlexPitt

...so fixed the above by simply adding  a new "Red2" colour config (which did work) and deleted the original faulty "Red" config. (below shows the renamed Red2 colour config). 

Thanks Neil, this is exactly what I was looking for! I'll try it with some more complex assemblies.

EvanReese

Inspired by Neil's snippet, I made this Part Color feature. Notable additions and differences.

1. RGB ranges go from 0-255 like the native edit appearance UI (and other things I'm used to like Photoshop). I left alpha as 0.00-1.00 to match the edit appearance UI, even though I'm used to 0-255.
2. The value bounds are custom so it limits only to relevant entries
3. there's an option to use a hexadecimal code, so you could copy and paste it in if you know the one you want.
4. it has an icon.

Cache_River_Mill

  

S1mon

@Evan_Reese
@NeilCooke

I'm thinking of using this as a starting point to make a set of standard color ways for a product line. We currently have 5 choices, and those end up being applied to ~6 parts in various levels of the assemblies. We will be expanding the number of choices, but they will be finite. I'm also planning to capture the choice in a "variant" custom property (e.g. a dash number like black = "-04", appended to the P/N). I like the idea of defining these choices in a single document so they don't have to be updated multiple places if there are tweaks to the color definitions (it seems like this would happen in the featurescript code itself, in this case).

Is there a better way to handle this now?

Now that we have Renderstudio, I'm also wondering how to connect Onshape appearances to Renderstudio (or vice-versa).

EvanReese

the Part Color feature is meant for really general use, but you could definitely use the code as a starting point to make something specific to your application. You could make the feature have a single dropdown to select the color, and it could also set the name and part number with whatever your code is. Whenever you add a new one, you'd just go into the feature and hard code in the color and color code. I'd probably use a nested map like this:

const colorway = {
"black" : {"color" : color(0,0,0), "code" : "-04"},
"blue" : {"color" : color(0,0,1), "code" : "-05"}
};

using it looks like this:

colorway.blue.code  should equal  "-05"

S1mon

@Evan_Reese

I'm digging into your Part Color FS again. I noticed something weird. Not sure if this is a bug in the code, or something about Onshape, but I made a simple part studio with a cube and then did a linear pattern of the cube. So I have "Part 1", "Part 2" etc. If I select "Part 1" and use the Part Color FS, it colors all of the parts. If I select "Part 2" or any other part but "Part 1" it will color just that one part.

EvanReese

I think it's because they are children of Part 1. If you had changed the part white using the standard tool (not a feature), then patterned it, the patterned parts would be white. That still doesn't totally explain this, but I think it's something to do with the way parts inherit color in Onshape, rather than something in the feature code.

S1mon

@Evan_Reese

I agree. I tested this out with some very simple code, and it did the same thing, and with a part studio with just the extrude and linear pattern. As long as I edit the appearance for "Part 1", all the parts change.

It does seem like odd behavior (or a bug) on Onshape's part though. Solidworks has the "propagate visual properties" checkbox for patterns and mirroring. Seems like this should be optional here too.