View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001654||FreeCAD||Bug||public||2014-07-30 16:28||2017-11-29 20:03|
|Target Version||Fixed in Version||0.17|
|Summary||0001654: Part Fillet/Chamfer object Shape Color lost on Position Change|
|Description||Setting custom shape color for part fillet/chamfer objects does not persist in 3D view on original sketch position change.|
|Steps To Reproduce||1.) Create simple closed sketch with few edges.|
2.) Use Pad feature on created sketch.
3.) Use Part Fillet/Chamfer tool on some edges.
4.) Set Shape Color property to custom color on Fillet/Chamfer object.
5.) Select sketch and under data tab change position of the sketch.
6.) Fillet/Chamfer object will change position but custom Shape Color property will not persist.
The fillet and chamfer inherits its shape colour from the object it depends on. If you only change the colour on the fillet/chamfer object and touch the sketch/pad afterwards the fillet/chamfer will override its colour.
You must colourize the pad instead.
First thanks for explanation.
I "reopened" this bug report because use case scenario was a bit more complex. I used Set colors... tools on Fillet/Chamfer object to apply different color to different faces in one project i did back then. After i had to move finished object i noticed the colors where gone and reported this "bug".
What you say makes sense. It is made this way for Fillet/Chamfer object to inherit colors from its parent object. But changing face color on Fillet/Chamfer object can't be done on parent object. I tried to simplify bug report and just focus on the fact the color does not persist.
How come Part Design Fillet/Chamfer object can have persisting (face) color? And for example Part Thickness object. Is the reason for Part Fillet/Chamfer tool to inherit color from its parent technical one because it would be hard to implement the support for custom color or administrative one? If it is administrative one i would say it might make sense to change this and allow Part Fillet/Chamfer object (faces) to have its own color instead of inherit it from parent object.
Just to be clear color can be applied to the face of parent object and it is inherited. It can not be applied to Fillet/Chamfer face before it is created.
And further testing Part Thickness tool moving parent object does remove colors added to Thickness object.
What confused me and what i didn't test/know at the time i reported this bug is in Part WB you don't have to move parent object you can move just Fillet/Chamfer or Thickness object and the color is preserved! Wish i knew that back then.
I guess this can be used as "workaround" in use cases like this but nonetheless i do see some may still consider this behaviour as bug in the future when moving parent object (for child objects created in Part WB) to find out colors are gone.
Well i don't know how i lost colors on Thickness object when moving parent object but lets make it simple for now. In the Part WB:
Insert Cube solid
Use Thickness tool on it and apply random color on produced Thickness object
Move Parent object (Cube solid)
The color is preserved.
Insert Cube solid
Use Fillet tool on one of its edges and apply random color on produced Fillet object
Move Parent object (Cube solid)
The color is NOT preserved.
I don't know if this counts as bug but at least it is inconsistency. Color is preserved in one situation and not in other. Mixing this objects further and making more complex compounds probably increases inconsistency? Just guessing.
Part fillet and chamfer implement the logic to check which faces of the output model correspond with the faces of the input model. But this means that colours set by the user will be overridden again and again.
Part design operations don't implement this logic at the moment because the models there may change too heavily so that the mapping of old and new faces is almost impossible and that's why they keep their colours. Once the topological naming mechanism is fully implemented the part design operations will be adjusted.
Since the part design objects don't handle the colouring at the moment this means that if a model has set different face colours and it changes too heavily (so that the number of faces change or their order) the colours may flip or will be reset to a single colour.
After all part fillet/chamfer is the way to go and it's more or less just a preview of how it will behave. But as said above we have to fully implement the topological naming first.
I see. Part fillet/chamfer implementation is the way to go and after topological naming is available it will/could be easier to move color between parent/child object faces more predictably and behaviour across workbenches will/could be more consistent. Support for moving colored face from parent to child object will still have to be implemented but after topological naming is implemented this should be easier to achieve.
Nonetheless could the logic in Part WB (just for color support) mimic the behaviour of the logic in Part Design WB until topological naming is implemented and the logic to move color from parent to child object face is added? I don't see issue like color flip as big obstacle because until topological naming is implemented users should not change geometry up/down design tree anyway. Or is the Part WB (future proof) implementation that much different this is simply not possible to simply change the set color behaviour to mimic Part Design WB ATM.
Just thinking out loud and i don't expect to much effort should be put into this. But if it is only administrative decision and behaviour could change easily i would say until topological naming is implemented user should not lose set colors when moving parent object.
P.S. As for workarounds available ATM if somebody else stumbles on this. Two possibilities are available ATM to set color for Part fillet/chamfer object and move it around.
-Apply color to last Part WB feature and move the last feature and not the parent.
-Create simple copy and apply color to that standalone object.
||Forum thread: https://forum.freecadweb.org/viewtopic.php?f=10&t=20376|
Per @chrisb in https://forum.freecadweb.org/viewtopic.php?f=10&t=20376&p=157209#p157209
> It is fixed in this version. Tested moving the super placement of the sketch an the placement of the body. In both cases color is preserved.
MOS: Ubuntu 14.04.5 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.9898 (Git)
Build type: None
Python version: 2.7.6
Qt version: 4.8.6
Coin version: 4.0.0a
OCC version: 6.8.0.oce-0.17
|2014-07-30 16:28||triplus||New Issue|
|2015-01-02 23:15||wmayer||Note Added: 0005486|
|2015-01-02 23:15||wmayer||Status||new => closed|
|2015-01-02 23:15||wmayer||Resolution||open => won't fix|
|2015-01-02 23:15||wmayer||Fixed in Version||=> 0.15|
|2015-01-03 17:54||triplus||Note Added: 0005489|
|2015-01-03 17:54||triplus||Status||closed => feedback|
|2015-01-03 17:54||triplus||Resolution||won't fix => reopened|
|2015-01-03 18:20||triplus||Note Added: 0005490|
|2015-01-03 18:20||triplus||Status||feedback => new|
|2015-01-03 18:39||triplus||Note Added: 0005492|
|2015-01-03 18:39||triplus||Note Edited: 0005492||View Revisions|
|2015-01-05 09:39||wmayer||Note Added: 0005521|
|2015-01-05 17:09||triplus||Note Added: 0005526|
|2017-01-30 21:06||Kunda1||Note Added: 0008113|
|2017-01-31 12:21||Kunda1||Note Added: 0008121|
|2017-01-31 12:21||Kunda1||Status||new => resolved|
|2017-01-31 12:21||Kunda1||Fixed in Version||0.15 => 0.17|
|2017-01-31 12:21||Kunda1||Resolution||reopened => fixed|
|2017-01-31 12:21||Kunda1||Assigned To||=> Kunda1|
|2017-01-31 12:21||Kunda1||Assigned To||Kunda1 =>|
|2017-03-10 20:35||kkremitzki||Assigned To||=> kkremitzki|
|2017-03-10 20:35||kkremitzki||Status||resolved => closed|
|2017-11-29 20:03||Kunda1||Tag Attached: colors|