A C++ library providing 3D Repo Scene Graph definition, repository management logic and manipulation logic. It is is essentially the refactored 3DRepoCore and (parts of) 3DRepoGUI
This fixes #679 - DWG object handles do not match Navis.
This PR adds a dedicated DWG importer using the Drawings SDK, replacing the previous importer which converted the DWG to a DGN, and then imported that using the DGN importer.
The new importer preserves the Handle Ids from AutoCAD, and better matches the Navisworks tree.
Description
New classes
The new importer follows the pattern of the existing ODA importers: a FileProcessor reads the file into an OdDatabase, which is then vectorised by a Graphics System View subclass (DataProcessorDwg), which sets up the collector layers and metadata, before the Gs tesselates the geometry into the DataProcessor superclass's methods.
View
The importer always imports the ModelSpace view.
Blocks
The importer creates tree nodes for all primitives outside of Blocks, and Block References. Block References take the name of their Block. All nested Block Entities are collapsed to the top level Block Reference.
Where Block Entities are assigned to different layers, tree nodes are created for the top-level Block Reference under each relevant layer. This allows the user to select & toggle elements by Layer regardless of Block membership, mirroring the behaviour of AutoCAD and Navisworks.
Names
Leaf nodes take the name of the type of primitive. Known class names are converted to a user-friendly name, mirroring the behaviour of Navisworks.
Metadata
Entities have only one metadata entry (Entity Handle::Value), which contains the hex encoded handle of the object. This handle can be seen in AutoCAD with the LIST command.
Colours
ODCOLORREF has been replaced with OdCmEntityColor in the MaterialColours struct across all ODA importers.
This is because this struct is part of the DataProcessor superclass which is used in a number of places.
The change was made because the ODCOLORREF macros are encoding dependent, and a different coding was turning up for DWGs leading to colour channels being swapped. OdCmEntityColor should handle this transparently.
CMake
New dependencies have been added to FindODA.cmake
Additionally the ODA_LIB_NAMES variable now has each entry on its own line as is done for the sources and headers, to make diff/change control easier
Unit Tests
Two new unit tests for DWGs have been added, to check the tree logic, and to check that password protected DWGs fail with an appropriate error.
Things to note
A new error code has been added for the password protected case. The code is 37. This code will also be used by #667.
The handle entities created by the new importer are "correct", however they do not match those created by the NWD importer or the (Navis) plugin. The plugins and NWD importer will need to be changed before cross referencing will work.
This fixes #679 - DWG object handles do not match Navis.
This PR adds a dedicated DWG importer using the Drawings SDK, replacing the previous importer which converted the DWG to a DGN, and then imported that using the DGN importer.
The new importer preserves the Handle Ids from AutoCAD, and better matches the Navisworks tree.
Description
New classes
FileProcessor
reads the file into anOdDatabase
, which is then vectorised by a Graphics System View subclass (DataProcessorDwg
), which sets up the collector layers and metadata, before the Gs tesselates the geometry into theDataProcessor
superclass's methods.View
Blocks
Names
Metadata
Entity Handle::Value
), which contains the hex encoded handle of the object. This handle can be seen in AutoCAD with theLIST
command.Colours
ODCOLORREF
has been replaced withOdCmEntityColor
in theMaterialColours
struct across all ODA importers.DataProcessor
superclass which is used in a number of places.ODCOLORREF
macros are encoding dependent, and a different coding was turning up for DWGs leading to colour channels being swapped.OdCmEntityColor
should handle this transparently.CMake
FindODA.cmake
ODA_LIB_NAMES
variable now has each entry on its own line as is done for the sources and headers, to make diff/change control easierUnit Tests
Things to note