Ticket #6069 - Shape color is not displayed correctly after change in tree
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Ticket #6069 - Shape color is not displayed correctly after change in tree
Not sure if this Forum section is also taking care of the Parts Workbench, but can someone second this?
Modifying existing parts in the tree directly, breaks the color of the shape on screen although it's still set in the part.
1. Part Module
2. Make 5 Cubes (translate sligthly to get overlaps)
3. Select Cube 1&2 and make Boolean Fragments 1 (BF1)
4. Select Cube 3&4 and make Boolean Fragments 2 (BF2)
5. Select BF1, CTRL-Select BF2 > Make boolean intersection (CUT)
6. Select CUT > View > Set any Shape Color (red)
7. In Treeview, drag Cube 5 into BF2 and recompute
> CUT will be shown in default color, although CUT>View will still show the previously set color (red)
Modifying existing parts in the tree directly, breaks the color of the shape on screen although it's still set in the part.
1. Part Module
2. Make 5 Cubes (translate sligthly to get overlaps)
3. Select Cube 1&2 and make Boolean Fragments 1 (BF1)
4. Select Cube 3&4 and make Boolean Fragments 2 (BF2)
5. Select BF1, CTRL-Select BF2 > Make boolean intersection (CUT)
6. Select CUT > View > Set any Shape Color (red)
7. In Treeview, drag Cube 5 into BF2 and recompute
> CUT will be shown in default color, although CUT>View will still show the previously set color (red)
Last edited by Kunda1 on Fri Apr 01, 2022 11:20 pm, edited 1 time in total.
Reason: Added GH ticket number to thread title
Reason: Added GH ticket number to thread title
Re: Shape color is not displayed correctly after change in tree
Some images or at least the model would help. From my understanding the intersection in step 5 would be empty.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
- Gregory son of Carl
- Posts: 99
- Joined: Mon Apr 06, 2020 7:42 pm
- Location: California
Re: Shape color is not displayed correctly after change in tree
Yeah, that seems to be the standard behavior for Part Workbench colors. You can always reset the color again by changing it to something else. It's a pain when editing parts a lot, but at least that option is there. I think FreeCAD does this because it's forced to choose between multiple color options for things like boolean features so it just picks what works for the majority of use cases.
It would be nice to have the option to set features or bodies to have "no color". That would solve this kind of situation where FreeCAD can't tell which colors you want to use. With the "no colors" option, FreeCAD can prioritize top-level feature colors to override child feature colors because the user can always select "no color" to make the child feature colors display instead.
It would be nice to have the option to set features or bodies to have "no color". That would solve this kind of situation where FreeCAD can't tell which colors you want to use. With the "no colors" option, FreeCAD can prioritize top-level feature colors to override child feature colors because the user can always select "no color" to make the child feature colors display instead.
Re: Shape color is not displayed correctly after change in tree
'No color' could be an option, but would complicate things.
As far as i understand, the tree controls a lot of things across workbenches and needs to remain in sequence so stuff won't break.
That should also apply for shape colors / settings.
In my example, the color is still set in the topmost part/operation but after breaking, it won't show on screen until altered! Not even re-setting the same color works. That does not make sense from a usability standpoint.
The final on-screen color should always be derived from the settings in the steps (tree). That can be either top-down or bottom-up, but it has to be consistent.
Since the (color-)settings apparently don't get lost in the system when altering a child(-step), the resulting color would automatically remain as set when following the hierarchy. No need for 'no color'.
As far as i understand, the tree controls a lot of things across workbenches and needs to remain in sequence so stuff won't break.
That should also apply for shape colors / settings.
In my example, the color is still set in the topmost part/operation but after breaking, it won't show on screen until altered! Not even re-setting the same color works. That does not make sense from a usability standpoint.
The final on-screen color should always be derived from the settings in the steps (tree). That can be either top-down or bottom-up, but it has to be consistent.
Since the (color-)settings apparently don't get lost in the system when altering a child(-step), the resulting color would automatically remain as set when following the hierarchy. No need for 'no color'.
- Gregory son of Carl
- Posts: 99
- Joined: Mon Apr 06, 2020 7:42 pm
- Location: California
Re: Shape color is not displayed correctly after change in tree
Higher-level features already have a default color when first created, however the color is only displayed after being changed. When a lower-level feature updates, the color state resets and it needs to be changed again to make it display. This system is internally consistent even though I agree that it is not very intuitive from a user perspective.
I think adding color hierarchy settings would still add a similar level of complexity. That's because such a display setting would be best applied at the individual feature level in my opinion. The option is still essentially an on/off switch for color except it's located in the Properties>view tab instead of the in the color selector window which actually is better in terms of the number of clicks required to reach it.
I think adding color hierarchy settings would still add a similar level of complexity. That's because such a display setting would be best applied at the individual feature level in my opinion. The option is still essentially an on/off switch for color except it's located in the Properties>view tab instead of the in the color selector window which actually is better in terms of the number of clicks required to reach it.
Re: Shape color is not displayed correctly after change in tree
I see. But I guess you agree that the fact that a color is assigned to a part and disappears is not ideal.
I'm just trying to look at it from a user perspective which is key to making things successful...
Whatever the logic is internally, I would suggest, that the changement of a part internally should to re-cascade/re-apply certain settings.
I'm just trying to look at it from a user perspective which is key to making things successful...
Whatever the logic is internally, I would suggest, that the changement of a part internally should to re-cascade/re-apply certain settings.
- Gregory son of Carl
- Posts: 99
- Joined: Mon Apr 06, 2020 7:42 pm
- Location: California
Re: Shape color is not displayed correctly after change in tree
Oh yes. I definitely agree that this behavior is frustrating and should be changed. Sorry if I'm getting too caught up in logistics before making that clear.
I would also extend this criticism to part design body colors which have the same problem, but in the opposite direction. Boolean operations override the colors of child features, but in this case there is no way to make the child colors show again.
I would also extend this criticism to part design body colors which have the same problem, but in the opposite direction. Boolean operations override the colors of child features, but in this case there is no way to make the child colors show again.
Re: Shape color is not displayed correctly after change in tree
No problem and I gladly leave it to those that know FreeCAD better to elaborate the proper course of action. Just making a point.
Re: Shape color is not displayed correctly after change in tree
By the way: Same problem applies to the transparency property which is even more annoying.
In the small test-project I'm working on right now, I have many parts that are cut-bools with transparency applied.
Everytime I modify a primitive within the substract-part of the cut, I loose the transparency (and color) on the cut and can't see what happens on the inside of the object anymore. That leads to a lot of overhead re-settings things.
In the small test-project I'm working on right now, I have many parts that are cut-bools with transparency applied.
Everytime I modify a primitive within the substract-part of the cut, I loose the transparency (and color) on the cut and can't see what happens on the inside of the object anymore. That leads to a lot of overhead re-settings things.
Re: Shape color is not displayed correctly after change in tree
I'm agree with that. Losing color and transparency is boring. Maybe someone could write a macro to reset them?