Add SwiftUI visionOS example.

[halmueller]

This PR adds a standalone SwiftUI sample (ExampleVisionOS) that creates a volumetric window on visionOS.

Of note:

• Vision Pro (native) run destination has been removed from the existing Example app. The RealityKit view does not display anything in native mode. Vision Pro (Designed for iPad) works fine, and remains as a destination.
• EuclidMesh.swift in ExampleVisionOS is virtually identical to the one in Example. UIKit dependency has been replaced by CoreGraphics, and the solid UIKit color has been replaced by a solid Euclid-defined color.
• This sample only displays a volumetric window. It's cut down from the Xcode 15.3 template to be as simple and short as possible.
• I removed the bones of the Apple template relating to the unimplemented immersive experience, because that added a top-level Packages folder to the Euclid project file. I thought that was potentially confusing and distracting. The best way to provide an immersive example would be as a freestanding .xcodeproj that imports Euclid and doesn't mess with the Euclid library project structure.
• If you want to see the distracting modification that I rejected, add a visionOS target to the project file, specifying an immersive app. Note the Packages folder that appears at top level.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.46%. Comparing base (d3afbeb) to head (afaec04).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #115      +/-   ##
==========================================
+ Coverage   77.36%   77.46%   +0.09%     
==========================================
  Files          32       32              
  Lines        8218     8218              
==========================================
+ Hits         6358     6366       +8     
+ Misses       1860     1852       -8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mgrider]

I know this PR is closed, but (and maybe this is the wrong place to ask this question), I'm curious how important makeWatertight() is here.

When running this on device as/is, the print of Time: was ~4.5 seconds. If I remove the call to makeWatertight() and bump the sphere slices parameter down to 60, it runs in around .5 seconds, and there doesn't seem (to me) to be a discernible difference.

[nicklockwood]

@mgrider Are you sure it wasn't reducing the slices that had the main impact, not removing makeWatertight()? The latter is usually negligible.

In any case, the answer is that non-watertight shapes can cause weird artifacts when performing CSG operations, but in this case since it's the last step you can skip it.

[halmueller]

A better improvement might be to get the construction off the main thread with a Task.

[nicklockwood]

I almost forgot, if you are running in debug mode, switching to release mode (or just enabling optimized builds for the Euclid module in debug mode, which will still let you debug the example app) should yield a significant speedup.

[mgrider]

You're totally right. Adding makeWatertight() back yields: Time: 0.6943490505218506.

[mgrider]

And it's just my opinion, but I think a 4.5 second delay in the example project feels broken (or at least not especially great), whereas .5 gets a 🤷‍♂️. Of course there will be ways to optimize, but this is going to be what people see when they're evaluating Euclid as a dependency.

[mgrider]

Love that this got made/merged, BTW. Definitely aiming for (hopefully helpful) constructive criticism!

[halmueller]

There's still a problem with blocking the main thread. What I had missed earlier is that Apple's RK samples all use the try! await Entity(named: "MyEntity") idiom, calling the async method to load from a file. There is no async version of init(_ mesh:...), so we should be calling that in a task and adding the content when it's ready. A real-world user of the framework may have very complicated/expensive meshes to build. Let me poke at that a bit and I'll post a new PR/branch.

[nicklockwood]

Everything in Euclid should be safe to run on a background thread. Distinct meshes should be safe to create in parallel on multiple threads/tasks as there's no global shared state.

Euclid already makes some use of multithreading internally which may not play nicely with async/await but is probably OK. Search for "batch" in the codebase if you're curious.

I plan to add async interfaces at some point, but it's complicated for various reasons. You're more than welcome to take a stab at it if you like.

[halmueller]

See what we think about #116. And let's continue conversation on that PR, close out this thread.