The Materials module does a conversion from float to double when saving the transparency and again a conversion from double to float to double
when restoring it. This causes a considerable loss of accuracy so that the representation in percent leads to different numbers.
Using consistently some helper functions to do a proper conversion from float to long and back fixes the problem.
The new property ShapeAppearance is a PropertyMaterialList and always read after the DiffuseColor property when restoring a document.
Thus, the method onChanged() doesn't override DiffuseColor when restoring a document. Additionally, the method finishRestoring() is re-implemented
to set the colours per face in case DiffuseColor has defined multiple colors.
When synchronizing the Transparency property with the transparency value of the ShapeAppearance property then do not convert between float and
double as otherwise some strange rounding issues can occur.
Example: Set the Transparency property of an object to 35 in the Property Editor. After leaving the editor the value may switch to 34.
* Correctly load a file if colors are set per face
* Result of boolean operation is correctly colored if source objects have different colors
* Result of compound is correctly colored if source objects have different colors
* fix several linter warnings
* remove code that cannot be executed: inside the constructor it cannot ever happen that getObject()
returns a valid object
* in ViewProviderGeometryObject::handleChangedPropertyName call the method of the direct base class
as otherwise this may break the mechanism in the future
* Shape is a property of an extension module -> move its handling to ViewProviderPartExt
This PR demonstrates the known regressions of the recently merged material branch:
* Changing the transparency after setting color per face will reset them
* The result of boolean operations or compound doesn't inherit the colour of its input objects
* If colour is set per face to a boolean operaton object then saving and restoring the file causes weird rendering behaviour
because material binding is set to PER_PART but only a single colour is defined
* If a shape inside a part container has set colour per face then saving and restoring as STEP file causes weird rendering
behaviour for the same reason
* Shape binder or datum objects don't show the correct default shape colour
* Fixed translations
* Reference objects can now use whole file contents instead of having to choose a part
* Support for DXF files
* Support for IFC files (if NativeIFC is available)
* General code cleanup
The edit datum dialog is opened by double-clicking on a dimensional constraint in a sketch. However, the double-clicking event doesn't work realiably on
some systems. As a workaround this PR adds the command to the context-menu.
For more details see the forum thread: https://forum.freecad.org/viewtopic.php?t=71137
FreeCAD is crashing during 'Solve Assembly' call if the Part property
(Assembly/Joints/Fixed/Joint Connector 1/Part1 or Assembly/Joints/Fixed/Joint
Connector 2/Part2) of fixed Joint is unset.
Steps to reproduce:
- make simple Assembly e.g. of two cubes with Fixed joint
- Select Fixed joint in the tree and go-to property 'Data' tab
- Select Part1 or Part2 of 'Joint Connector 1' or 'Joint Connector 2'
and remove this reference
- call 'Solve Assembly' now
The FreeCAD will crash here because the call
App::DocumentObject* part = getLinkObjFromProp(joint, propPartName);
will return NULL pointer.
The property Part1 or Part2 can get empty (unset) during usual
construction operations - during changing construction history
and it can be very hard to find the cause of FreeCAD crash on a big
model.
This patch tries to fix the crash in such situation.
