View Issue Details

IDProjectCategoryView StatusLast Update
0001654FreeCADBugpublic2017-11-29 20:03
Reportertriplus Assigned Tokkremitzki  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
PlatformLinuxOSUbuntuOS Version14.04
Product Version0.14 
Target VersionFixed in Version0.17 
Summary0001654: Part Fillet/Chamfer object Shape Color lost on Position Change
DescriptionSetting custom shape color for part fillet/chamfer objects does not persist in 3D view on original sketch position change.
Steps To Reproduce1.) 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.
Tagscolors
FreeCAD Information

Activities

wmayer

2015-01-02 23:15

administrator   ~0005486

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.

triplus

2015-01-03 17:54

developer   ~0005489

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.

triplus

2015-01-03 18:20

developer   ~0005490

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.

triplus

2015-01-03 18:39

developer   ~0005492

Last edited: 2015-01-03 18:39

View 2 revisions

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.

wmayer

2015-01-05 09:39

administrator   ~0005521

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.

triplus

2015-01-05 17:09

developer   ~0005526

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.

Kunda1

2017-01-30 21:06

administrator   ~0008113

Forum thread: https://forum.freecadweb.org/viewtopic.php?f=10&t=20376

Kunda1

2017-01-31 12:21

administrator   ~0008121

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
Branch: master
Hash: 2d8461521964121b8ac7ac6ebe5f0d29dfe36343
Python version: 2.7.6
Qt version: 4.8.6
Coin version: 4.0.0a
OCC version: 6.8.0.oce-0.17

Issue History

Date Modified Username Field Change
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