The final PR for the external module feature that allows materials to
be stored in an external datastore, webservice, etc.
This includes the final material manager classes, and the UI support in
the form of commands and preference pages.
Refactored code to support local and external material sources
This is the first PR in a series to support external modules. External
modules allow materials to be stored in external data sources such as
databases or web services. No new functionality is introduced in this
PR, rather it is a refactoring of code that will allow for changes to
be introduced in future PRs. Minor performance improvements have also
been made in the model and material managers.
The Python API has been enhanced for many data types to allow for
modification within Python.
The class MaterialLibrary has a shared pointer to its Material objects and the class Material has a shared pointer to the MaterialLibrary.
The class MaterialManager owns all MaterialLibrary and Material objects in static containers. To resolve the cyclic references the method
cleanup() has been added.
The class ModelLibrary has a shared pointer to its Model objects and the class Model has a shared pointer to the ModelLibrary.
The class ModelManager owns all ModelLibrary and Model objects in static containers. To resolve the cyclic references the method
cleanup() has been added.
The Materials module registers a function to App::CleanupProcess that calls the above cleanup() methods.
NOTE: This registration is only done in debug mode mainly to satisfy memory checkers
Improves the MaterialTreeWidget beyond minimum viable product.
- Filters can now be filter lists to allow a variety of filtering
options.
- User preferences allow the inclusion/exclusion of favorites and
recents.
- Widget state such as expansion, tree expansions, etc are saved and
restored.
- show current appearancee material when editing.
- implements a python interface
#fixes 13421: always opens full tree
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.
Continues the work of the material subsystem improvements.
This merge covers the continued development of the material editor. The
primary improvements are in the handling of 2D and 3D array properties.
These properties are now fully editable, and can be saved and restored.
The cards now separate the author and license. These were previously
saved as a single item. Future support will be provided for standard
open source licenses.
Saving operations validate the cards to ensure UUIDs of materials are
considered. Warnings are given when a save could potentially impact the
models, such as saving over a material instead of creating a new
instance.
The editor is still not complete. There are a number of functional
elements, such as drag/drop operations, folder creation, and deletion
operations that need to be added to the main tree. State needs to be
saved and restored to improve the user experience. The appearance
preview also needs significant work. This will be handled in a future
PR.
Rework of the material handling system.
This first part concntrates on a rework of the material cards.
Rather than use a fixed list of possible properties, properties can
be defined separately in their own files and mixed to provide a
complete list of possible properties. Properties can be inherited.
The cards then provide values for the properties. These can also
be inherited allowing for small changes in cards as required.
The new property definitions are more extensive than previously.
2 and 3 dimensional arrays of properties can be defined. Values
are obtained by calling an API instead of reading from a dictionary.
For compatibility, a Python dictionary of values can be obtained
similar to how it was done previously, but this is considered a
deprecated API and won't support the newer advanced features.
The editor is completely reworked. It will be able to edit older format
material cards, but can only save them in the new format.
For testing during the development phase, a system preference can
specifiy wether the old or new material editors are to be used. This
option will be removed before release.
Rework of the material handling system.
This first part concntrates on a rework of the material cards.
Rather than use a fixed list of possible properties, properties can
be defined separately in their own files and mixed to provide a
complete list of possible properties. Properties can be inherited.
The cards then provide values for the properties. These can also
be inherited allowing for small changes in cards as required.
The new property definitions are more extensive than previously.
2 and 3 dimensional arrays of properties can be defined. Values
are obtained by calling an API instead of reading from a dictionary.
For compatibility, a Python dictionary of values can be obtained
similar to how it was done previously, but this is considered a
deprecated API and won't support the newer advanced features.
The editor is completely reworked. It will be able to edit older format
material cards, but can only save them in the new format.
For testing during the development phase, a system preference can
specifiy wether the old or new material editors are to be used. This
option will be removed before release.
