Entity.write(to:)
Reality Composer from macOS (not Pro) was quietly sunset not too long ago.
Aside from being a graphical editor that allowed for basic scene setup, it also had other great utilities, such as cross-platform preview and some popular features that allowed for creating interaction with triggers and events.
Reality Composer used a file format with the extension .rcproject, which, after compiling, produced a file with the extension .reality (as in RealityKit file). This type of file has surfaced in various places, like some AR experiences for the WWDC websites, as well as some other great pieces like Ride transit with Apple Pay in AR and For All Mankind: Time Capsule, and, more recently, if you dig deep enough, you can find it is used on the visionOS environments too.
I'm still not sure why this format is necessary at all, as the .usd format should be enough without the need to be wrapped in a .reality, but there could be intellectual property reasons, some extra configuration or behind-the-scenes optimizations that I'm not aware of. But anyways, on the software side, don't get me wrong: I love its successor (Reality Composer Pro), and I've seen firsthand how important graphical editor tools like this are in a company's pipeline. And now, with the most recent updates, we are gaining back some of the beloved missing features.
From left to right the icons used for .rcproject, .reality and .usdz
Back to the file format, regardless of whether we used .rcproject or the current SPM packages, we never had an API for generating .reality files on runtime; everything happened automagically at compile time, which was practical but limited. With visionOS 2, this is about to change, as Entity instances are getting a way to write their content to disk at runtime, enter Entity.write(to:)
try await myEntity.write(to: .temporaryDirectory)Not much control yet on the results or phases, but it gets the job done
This is significant because it not only allows for simpler exchange of content and state, it unlocks exciting use cases and tools (like debuggers). There is also a counterpart process that supports partial file loading in the under ReferenceComponent, which means that richer loading strategies are now possible (think of game levels loading), as well as frictionless social sharing/consumption of user-generated content (without the loops required for building USDZ files, for example).
someOtherEntity.components.set(
ReferenceComponent(
named: "MyEntity",
loadingPolicy: .onDemand))
if let myEntity = someOtherEntity.findEntity(named: "MyEntity") {
try await ReferenceComponent.loadReference(at: myEntity)
}Overall, seemingly minor details can have a significant impact on the evolution of this platform and its future experiences, and the closer we look at what is going to be delivered, the more clear this claim becomes. To use an analogy, picture a world where video could only be watched in real time until there was a way to share it and watch it again later. Imagine what that would mean.
