This a refactoring of the CMake config file to follow best practices:
- A draco-targets.cmake is generated with install(EXPORT ...), and included in
draco-config.cmake.
- For users consuming Draco with add_subdirectory(), a draco::draco alias is provided.
- Removed find-draco.cmake-- CMake couldn't use it anyway due to the file name
not matching CMake expectations for a find script.
Note: this also removes the previous methods of hardcoding the C++ standard in
the Draco build to C++11. Instead of direct manipulation of CMAKE_CXX_STANDARD
target_compile_features() is used. External projects consuming Draco should now
be able to set the standard to a newer version.
Not really sure who is to blame, but in optimized builds from MSVC
gltf_decoder.cc appears to be getting garbage values back
from TinyGLTF when it parses the materials for
testdata/.../three_meshes_two_materials_one_no_material.gltf
Since there's no certainty about whether this is limited to this
particular file, just disable optimizations for
src/draco/io/gltf_decoder.cc in all MSVC build configurations.
This enabled CI testing of transcoder configs and includes a few minor
Windows-only bug fixes. Note that this adds flags to skip
GltfDecoderTest.ThreeMeshesOneNoMaterialMesh for Windows
MSVC CI builds. See https://github.com/google/draco/issues/826 for
details.
Windows specific updates (these do impact non-Windows builds, but
are essentially a no-op there):
- Use a local dupe of a constant to avoid DLL linkage issues on Windows
in the GLTF encoder test..
- Define DRACO_PI to avoid M_PI and entertaining include ordering
issues related to _USE_MATH_DEFINES and interactions between
<cmath> and <math.h> on Windows (fun include guards and order
related things). This is done in core/constants.h.
- Fixed omission of draco_version.h when installed in static
configurations.
- Remove DracoConfig.cmake: it was broken and we actually use
draco-config.cmake.
- Update FindDraco.cmake so it actually has a chance of working
properly. Fixed usage of find_path() and subsequent related errors.
- Correct the usage of CMakePackageConfigHelpers in installation target setup
and the config template.
- Add a CMake version file.
- Normalize the Draco variables exposed in CMake.
- draco_FOUND -> DRACO_FOUND
- DRACO_INCLUDE_DIRS, draco_INCLUDE_DIRS -> DRACO_INCLUDE_DIR
- DRACO_LIBRARIES, draco_LIBRARIES -> DRACO_LIBRARY
- DRACO_LIBRARY_DIRS, draco_LIBRARY_DIRS -> DRACO_LIBRARY_DIR
- draco_VERSION_STRING -> DRACO_VERSION
- Use full path variants of GNUInstallDirs variables to init our
install paths.
Fixes https://github.com/google/draco/issues/764
* Add install() for draco-version.cmake.
Restrict the behavior disallowing the build of both libraries to MSVC. The mingw CMake generators
handle the situation properly:
- Shared library suffix: .dll
- Import library suffix: .a.dll
- Static library suffix: .a
This is a workaround for two issues with CMake's Xcode generator:
- Setting the LINK_LANGUAGE property does not work.
- Library targets that only combine other object files do not build in
Xcode because of some other issue in the generator. They don't fail
at build time: Xcode just does not build them.
The combined behavior of the two issues forces addition of dummy source
files to the listed targets.
Fixes issue https://github.com/google/draco/issues/593
Avoid a confusing failure mode for javascript builds by requiring that
points at an existing directory. Prevents failure of custom
commands late in the configure and build processes.
We rely upon CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS for windows DLL
support, but we must defer the BUILD_SHARED_LIBS check until after the
plugin args are checked since the plugin checks can enable BUILD_SHARED_LIBS.
Without this change Visual Studio will not create import libs for the draco DLLs,
and that breaks the build.
Downstream users sometimes need the standard Draco library targets,
even when building in Emscripten. Add the flag ENABLE_JS_GLUE, which
defaults to ON. When turned OFF, the standard Draco library targets
will still be built within an Emscripten build.
Also do some whitespace clean up while working in CMakeLists.txt.
https://github.com/google/draco/issues/407
It causes a link error like the following:
clang: error: invalid argument '-compatibility_version 1.0.0' only allowed with '-dynamiclib'
Fixes: https://github.com/google/draco/issues/393
* Improved kD-tree based point cloud encoding
* Now applicable to point clouds with any number of attributes
* Support for all integer attribute types and quantized floating point types
* Improved mesh compression up to 10% (on average ~2%)
* For meshes, the 1.3.0 bitstream is fully compatible with 1.2.x decoders
* Improved Javascript API
* Added support for all signed and unsigned integer types
* Added support for point clouds to our Javascript encoder API
* Added support for integer properties to the PLY decoder
* Bug fixes
* Up to 20% faster decoding
* Added support for integer attributes to our Javascript Encoder
* Fixed issues with THREE.DracoLoader not releasing memory associated
with the Draco module
* OBJ decoder can now be used to parse pure point clouds
* Added Unity plugins to support runtime loading and design-time
importing of encoded Draco files
* Javascript and WebAssembly decoder size reduced by 35%
* Added specialized Javascript and Webassembly decoders for GLTF (size
reduction about 50% compared to the previous version)
The latest version of Draco brings a number of new compression
enhancements for even smaller models:
- Improved compression
- Up to 40% better compression of normals
- Up to 5% better compression for models with multiple attributes
- Faster decode speeds
- 30% faster decoding for models with multiple attributes for lower compression levels 4 and below
- Note: Decreases compression by 10%.
- Encoding of metadata to .obj (e.g. Draco can preserve material or sub-object names)
- Security fixes
-Increase version to 1.0.1
-Update Javascript decode timing example
-Fix async creation of DracoDecoderModule
-fixes wasm parallel decoding
-Introduce base class for geometric normal predictor
-Added integer attribute interface to JavaScript decoder
-Move loading Draco decoder into three.js Draco loader
-Add compiler launcher support to CMake build
-Add sanitizer support via CMake build
-Check we are not reading past the end of the attribute buffer
