iTwin Reality Data integration

[jjspace]

Description

This PR is building off of #12289 to add an easy function to load Reality Data meshes. Currently we are only supporting 3D Tiles meshes and pointcloud types of Reality Data to keep the initial integration simple. More can be added in the future but they will require different datasources and constructors in CesiumJS and will require a little more thought on how to design the API.

Issue number and link

No issue

Testing plan

• Running the test sandcastle
  • Load the new sandcastle and make sure it loads.
  • Check that the reality mesh in that iTwin loads and shows in the surrounding area.

Author checklist

• I have submitted a Contributor License Agreement
• I have added my name to CONTRIBUTORS.md
• I have updated CHANGES.md with a short summary of my change
• I have added or updated unit tests to ensure consistent code coverage
• I have updated the inline documentation, and included code examples where relevant
• I have performed a self-review of my code

[github-actions]

Thank you for the pull request, @jjspace!

✅ We can confirm we have a CLA on file for you.

[jjspace]

@ggetz I know we discussed it this morning but can you do a quick pass on the API here just to confirm it looks good? then I'll start adding tests.

[ggetz]

Overall API looks good @jjspace! Just a few comments.

[jjspace]

@ggetz I've added tests now and I think addressed all your comments above. Should be ready for another look and I think it's close to done if not already there

[ggetz]

This is looking good @jjspace!

I noticed that the reality mesh looks a bit blurry at the default settings. I was getting a comparable visual to other photogrammetry tilesets after setting the max SSE to 4 —

realityMesh.maximumScreenSpaceError = 4;

I'm guessing this may be because the geometric error of the tileset is balanced against the iTwin viewer, what may have different tile selection metrics. Have you seen the same for other Reality Data meshes?

What do you think of passing a default of 4 for all with the type of RealityMesh3DTiles?

[jjspace]

@ggetz I agree the tileset in the sandcastle was too low quality by default. I check some other reality meshes I have access to and sse of 4 looked better on all of them too so I just set it as the default as you suggested.

[ggetz]

This looks fantastic, thanks @jjspace!

[aruniverse]

fyi @matmarchand

[matmarchand]

I believe type and rootDocument should be extracted from the reality data metadata to ensure that they are consistent with what actually exist in the storage container... or maybe this is our way to avoid a call to get metadata since they were already extracted and assumed consistent?

[jjspace]

or maybe this is our way to avoid a call to get metadata since they were already extracted and assumed consistent?

@matmarchand You are correct. If either of these values is missing we will fetch the metadata needed to load the tileset. This will likely only the rootDocument commonly but we grab and update both from the new request anyway.

However if the application using this function already has these values we can skip that network call. This could happen if the app loads the list of reality data using return=representation instead of return=minimal. Or if the app already called the individual metadata route themselves. No need to waste extra time and bandwidth if the info is already accessible