only 4 of these warnings are still relevant, CMake shall be used to disable them
Compiler definitions:
NOMINMAX:
* is already globally defined in SetGlobalCompilerAndLinkerSettings.cmake
WIN32_LEAN_AND_MEAN:
* use CMake target_compile_options on relevant targets
Warnings that still occur:
C4251, C4273, C4275: all related to dllimport / export
* use CMake target_compile_options on relevant targets
C4661: no suitable definition provied for explicit template instantiation request
* triggered in Mesh because of Vector3D in Base - not all functions are defined in header
* use CMake target_compile_options on relevant targets
Warnings that are Currently not triggered (fix code if they appear again):
C4005: macro redefinition
C4244: argument conversion, possible loss of data
C4267: conversion from size_t to type, possible loss of data
C4305: truncation from type1 to type2
* only occurrence disabled in Reader.cpp
C4522: multiple assignment operator specified
C5208: unnamed class in typedef name
Obsolete Compiler warnings:
C4181: not mentioned in Microsoft docs anymore
C4290: C++ exception specification ignored except to indicate a function is not __declspec(nothrow)
* throw(optional_type_list) deprecated in C++17
C4482: nonstandard extension used: enum 'enumeration' used in qualified name
* not generated for compilers that support C++11
C4503: 'identifier': decorated name length exceeded, name was truncated
* obsolete since Visual Studio 2017
C4786: not mentioned in Microsoft docs anymore
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.
* Materials: Model Manager External Interface
Implement the ModelManagerExternal class for the external Materials
interface.
This is part of the ongoing merges of code to support external material
interfaces. In this PR the ModelManagerExternal class is implemented,
along with changes to supporting classes required for this class.
* Apply reviewer feedback
The ExternalManager class calls python functions in an external module
to create, read, update, and delete material definitions. The API
provided by the modules must conform to that defined in the
MaterialManagerExternal.py file.
All communications with the external module is routed through this
class.
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.
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.
Add support for embedded SVG files. These are not the same
as image files so need to be handled differently.
Add the ability to filter materials in the editor when called from
code. This allows programs to select objects supporting specific
models, complete models, older models, etc.
Updated tests, and refactored code.
New models and materials supporting patterns such as used by the
TechDraw workbench.
fixes#11686 - checks for the presense of a model property before
assinging a value. This can happen when a required model definition is
not available.
---------
Co-authored-by: Chris Hennes <chennes@pioneerlibrarysystem.org>
Continues the work of the material subsystem improvements.
This merge covers the continued development of the material editor. The
primary improvements are the addition of new data types, a new
appearance preview UI, and changes in the array data types.
New data types were added to support more advanced workflows, such as
the Render Workbench.The Image datatype allows the material to embed
the image in the card instead of pointing to an image in an external
file. Multi-buyte strings span multiple lines as the name implies.
It preserves formatting accross those lines. Also several list types
are now supported, with the primary difference being the editors.
List is a list of strings, FileList is a list of file path names, and
ImageList is a list of embedded images.
For the appearance preview, the UI now uses the same Coin library as
is used in the documents, meaning the preview will look exactly the
same as the material will be shown in the documents.
The array data types are now more complete. The default value wasn't
being used as originially envisioned and was tehrefore removed. For
3D arrays, the Python API was implemented.
There were a lot of code clean ups. This involved removing logging
statements used for debugging during development, reduction of lint
warnings, and code refactoring.
The editor can automatically convert from previous format files to the
current format. This has been extended to material files generated by
the Render WB. Old format files are displayed in the editor with a
warning icon. Selecting one will require saving the file in the new
format before it can be used.
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.
