Add Cesium3DTiles project

[lilleyse]

Merge #361 first

Adds a new project Cesium3DTiles that will be used by Cesium3DTilesReader and Cesium3DTilesWriter. The files are generated from #361. There are no additional helper functions like you would see in CesiumGltf. I spot checked the generated documentation.

I plan on updating CHANGES.md after the reader and writer are merged.

Questions:

• What tests should be added? All the classes are essentially struct-like.
• Why don't we use vector and matrix types for the generated code? That would be nicer than seeing std::vector<double> transform = {1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1};. Maybe we can use OrientedBoundingBox, BoundingRegion, and BoundingSphere in generated code as well?
• What's the best approach for BoundingVolume.h? The bounding volume types in boundingVolume.schema.json are mutually exclusive. ImageSpec.h has the same problem for uri/bufferView. Not sure if it's even possible to express well in C++ while also keeping the API consistent and user friendly (aka I don't think std::variant or getters/setters are the answer here). tinygltf doesn't seem to do anything special either so maybe we just live with it.

Here's what the file looks like (with some comments removed)

// This file was generated by generate-gltf-classes.
// DO NOT EDIT THIS FILE!
#pragma once

#include "ExtensibleObject.h"
#include "Library.h"

#include <vector>

namespace Cesium3DTiles {
/**
 * @brief A bounding volume that encloses a tile or its content. Exactly one
 * `box`, `region`, or `sphere` property is required.
 */
struct CESIUM3DTILES_API BoundingVolume final : public ExtensibleObject {
  std::vector<double> box;
  std::vector<double> region;
  std::vector<double> sphere;
};
} // namespace Cesium3DTiles

[kring]

Looks great! Just the one comment below, and it can be addressed in a separate PR if necessary.

What tests should be added? All the classes are essentially struct-like.

I don't think there's any behavior worth testing here.

Why don't we use vector and matrix types for the generated code?

Two reasons, but I don't know if either of them are really any good:

1. To avoid a dependency on glm (and also other Cesium libraries if we use OrientedBoundingBox et al).
2. Because we can't easily tell from the spec that a property is a matrix versus some other array of doubles.

What's the best approach for BoundingVolume.h? The bounding volume types in boundingVolume.schema.json are mutually exclusive.

Yeah I don't think we can/should do much here. The philosophy with CesiumGltf, which extends to Cesium3DTiles too, is that every valid glTF should be representable with CesiumGltf. But just because we can represent something with CesiumGltf doesn't mean it's a valid glTF. We can't encode every requirement in the type system, and attempting to do so would just make our libraries harder to use.

[lilleyse]

This change is the result of #365

[lilleyse]

Couldn't use forward declarations anymore after the changes in ExtensibleObject.h

[lilleyse]

This is not required for all files (e.g. classes that inherit from NamedObject instead of ExtensibleObject) but I don't see the harm in keeping it around.

[lilleyse]

And eventually NamedObject may make its way into CesiumUtility

[lilleyse]

Moved here since clang-format will order includes for us

[lilleyse]

CesiumGS/3d-tiles#498 was merged so I updated the links

[lilleyse]

@kring I updated the PR to use the single ExtensibleObject.h and left inline comments for things to point out

[kring]

It's essential to never include a using namespace Anything in a header file.
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rs-using-directive

[lilleyse]

Yeah I should have realized this. Thanks for making the changes.

Also a bump for clang-tidy to help catch mistakes like this #203

[kring]

Well, that escalated quickly... I thought I'd just get rid of the using namespace CesiumUtility and the duplicated class and merge this, to avoid another cycle through different time zones. But it turned out to be a lot of changes. But I think I've gotten rid of most (if not all) of the duplication between CesiumGltf[Reader] and and CesiumUtility / CesiumJsonReader now at least.

I noticed when I regenerated the 3D Tiles files, though, that Cesium3DTilesReader doesn't exist. Is that intentional?

If you're happy @lilleyse, feel free to merge this.

[kring]

I noticed when I regenerated the 3D Tiles files, though, that Cesium3DTilesReader doesn't exist. Is that intentional?

Oh, yep, #363.

[lilleyse]

Thanks for wrapping this up @kring