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.
The explicit activation of the MaterialWorkbench breaks the toolbars layout for every start. When fixing it manually it will be broken
again after the next start.
Because the core doesn't depend on the Material module it's a no-go to add an explicit runtime dependency to the corresponding workbench.
Since the Part module depends on the Materials module and the PartGui on MatGui the correct way is to let Part an PartGui load their
dependencies.
* fix warning -Wunused-variable
* fix warning -Wreorder-ctor
* fix warning -Wunused-but-set-variable
* fix uic warning for DlgDisplayProperties.ui
* rename the target MateriaTestLib ALL (note the typo and the already existing MaterialTestLib ALL) to MaterialTest ALL
drop the hard dependency to the Part module: The document is checked for a property ShapeMaterial of type Materials::PropertyMaterial.
An alternative could be to cast to GeoFeature and use the methods getMaterialAppearance() and setMaterialAppearance()
* Restored previous logic of GeoFeature::getElementName()
* Added precompiler directive to use the old logic if FC_USE_TNP_FIX isn't defined, otherwise use the new logic
* Reworked SketchObjectTest::getElementName() as a consequence of the previous points
Signed-off-by: CalligaroV <vincenzo.calligaro@gmail.com>
Uses new material system for appearance
Each feature object now has a property called ShapeMaterial that
describes its physical properties. If it has a shape, it has a
material.
The ShapeColor attribute is replaced by a ShapeAppearance attribute.
This is a material list that describes all appearance properties, not
just diffuse color. As a list in can be used for all elements of a
shape, such as edges and faces.
A new widget is provided to allow the user to select materials in a
consistent fashion. It can also launch the material editor with its
more advanced capabilities.
