Swift for the content creation industry, metaverse, and beyond

Community Showcase
, , , ,
1

I would like to begin by saying thank you to the entire swift team for the incredible work done to make cxx-interop possible. I think this this will play into a pivotal moment for swift in its ability to write cross-platform applications, especially for computer graphics applications designed for content creation and the visual effects industry (given the prominence of C++ across its software landscape).

Universal Scene Description (USD) for Swift
Universal Scene Description (USD) for Swift1920×1272 240 KB

Through cxx-interop and the tooling of SwiftPM, I've so far been able to build many of the industry's C++ libraries without a single line of CMake in MetaverseKit, and then additionally provide these libraries as package dependencies through SwiftPM to bring Pixar's Universal Scene Description (USD) to the swift programming language with SwiftUSD.

I'm very curious to the rest of the community's thoughts here, what has your development experience been like with swift's cxx-interop so far? What are your thoughts on its potential with interoperability with other languages in the future like Rust? And more generally, how do you think the existing C/C++ landscape might benefit from Swift's tooling here?

Thank you all!! :heart:

12 Likes
2

Nice, I have no interest in the "Metaverse" but I took a look at your MetaverseKit wrapper package and there are some libraries I am interested in using. Have you tried building for Android at all using my Android SDK, as Android headsets currently dominate? Unfortunately, C++ Interop has never worked fully on the Android port, so you would've likely seen issues.

Let me ask you in return: what has your development experience with Swift been like?

2 Likes
3

Have you tried building for Android at all using my Android SDK, as Android headsets currently dominate?

Your effort so far on putting that together for Android is incredible! I have not attempted anything on Android as of yet, but it's planned for the backlog. It looks like your work on that will pave the way into bringing all of this over to Android, I'm excited to try it out. I have ensured to maintain full support on Linux, though I've been running it on Ubuntu 23.04 aarch64 (Lunar Lobster), so distros and versions will likely vary as I've just not been able to get around to testing those platforms yet.

Unfortunately, C++ Interop has never worked fully on the Android port, so you would've likely seen issues.

Have you been able to keep a record of some of these errors? I'd be happy to take a look into them and attempt to figure out some solutions.

Let me ask you in return: what has your development experience with Swift been like?

My development experience with Swift has honestly been great, especially with cxx-interop!

However, I should warn you ahead of time that I've been rather quick to just chaotically restructure a huge cxx project for the sake of adhering to the very strict requirements of SwiftPM's little to zero flexibility in how it expects each target's public header directories to exist within respect to each other -- so it's a lot of shameless modification on my end of current cxx projects into this typical directory structure:

  • sources:
    Sources/MyCxxTarget/MyCxxTarget.cpp
  • header files:
    Sources/MyCxxTarget/include/MyCxxTarget/MyCxxTarget.h

The (extremely unfortunate) limitation of having very little control of how to specify include directories for targets via the publicHeadersPath property is the reason this massive restructuring of existing projects is necessary, and is currently a show-stopper in terms of official projects (such as Pixar with USD) from being able to officially adopt Swift & SwiftPM given this limitation.

Aside from that critical limitation, I've honestly experienced very little issues, there are some annoying things I've experienced such as very slow compilation times (but I'm also building a bit of a ridiculous amount of libraries together at once for USD's sake), so that bit is expected, and sourcekit seems to be really struggling at times with cxx interop which I am hoping will improve here soon, and other just very minor things.

Overall the experience has been amazing, but I can't wait until we get more flexibility in the include directory dilemma outlined above.

1 Like
4

Yep, detailed logs from the compiler validation suite, including this recurring error:

Command Output (stderr):
--
<unknown>:0: warning: the '-enable-experimental-cxx-interop' flag is deprecated; please pass '-cxx-interoperability-mode=' instead
<unknown>:0: note: Swift will maintain source compatibility for imported APIs based on the selected compatibility mode, so updating the Swift compiler will not change how APIs are imported
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "SwiftGlibc.h"
         ^
/data/data/com.termux/files/home/build/Ninja-Release/swift-android-aarch64/lib/swift/android/aarch64/SwiftGlibc.h:165:10: note: in file included from /data/data/com.termux/files/home/build/Ninja-Release/swift-android-aarch64/lib/swift/android/aarch64/SwiftGlibc.h:165:
#include <iconv.h>
         ^
/data/data/com.termux/files/usr/include/iconv.h:122:3: error: missing '#include <bits/mbstate_t.h>'; 'mbstate_t' must be declared before it is used
  mbstate_t dummy2;
  ^
/data/data/com.termux/files/usr/include/bits/mbstate_t.h:47:3: note: declaration here is not visible
} mbstate_t;
  ^
<unknown>:0: error: could not build C module 'SwiftGlibc'

I will be trying some things in the coming weeks and let you know how that goes. If my attempts don't work, I may take you up on that. :wink:

5

Would you be able to show me what the SwiftGlibc.h umbrella header looks like?

#ifndef __SWIFT_GLIBC_H__
#define __SWIFT_GLIBC_H__

// in file SwiftGlibc.h

// ...

#include <iconv.h>

// ...

#endif /* __SWIFT_GLIBC_H__ */
6

It looks exactly the same as it does in the linux toolchain, as both use that same header, which has not been modified in years. However, there are efforts underway to properly modularize that C library for Swift, so I'm hoping that will get C++ Interop working fully for the first time with the Android port.

7

I was just curious what the actual raw generated umbrella header looks like as I have never seen it before, example.

But yes, modularizing that library makes a lot of sense, afaik the existing approach was never intended to be all-encompassing of that C library, where even just the absence of a couple header includes could quickly progress into the chaos you ran into in your error above.

Being modularized can ensure every include is provided for, and at least if you run into any problems - they are scoped to just a couple offending modules instead of having the entire library to worry about.

8

If you download a Swift toolchain for linux and look at usr/lib/swift/linux/x86_64/SwiftGlibc.h, the one for Android is identical to that, modulo comments. You can check that for yourself by downloading my Android SDK linked above and diffing the two.

1 Like
9

@Finagolfin I gotta trivia question for you because I'm clueless.

10

We have been trying to build SwiftUSD for VisionOS without any success. We have tried both adding the project as a dependency as recommended and also using the shell approach. We are getting link issues for missing symbols (_deflate, _inflate and other similar). Recently we were told that SwiftUSD is NOT supported on Vision because components within it our not all fully supported in vOS. Is this correct? Is it possible to do a partial build and leave out unsupported capabilities? the main utility we are looking for is access to the USDAPI for building out a valid USD file and for quickly traversing the stage and updating properties like the transforms. Any thoughts??

11

The only thing missing to compile SwiftUSD on visionOS is to fix the MetaversePythonFramework dependency to include the proper python binary compiled for the visionOS platform in its .xcframework binary target. Everything else already builds for visionOS.

Somehow even after specifying the xros platform to build the Python library against, a macosx binary was produced (more than likely I am guessing I had accidentally copied the built python library from the macosx directory instead of the xros directory). It should not take me much effort to fix it, and will do so as soon as I find the time.

If there’s missing symbols, I'd ignore those until the Python library is fixed first, since lots of things have a dependency on Python, and without Python; many of the dependencies will not build (which will almost certainly lead to missing symbols).

12

Is this something you are planning to fix or something that we need to do individually on our local machines? Are the proper python binary builds for vOS available?

Is there still an issue since Alembic is not supported on vOS? Will we still be able to run and utilize the rest of the USD API for creating and manipulating USD files?

13

Sorry Furby. For some reason I did not see your whole reponse in the email that had your post.

14

Once the SwiftUSD libraries are built and available on the VisionPro, will the toolkit tools also be available? For example, the ability to convert a USD or USDC into USDA? The ability to create a USDZ given a folder of USD* files?

15

Will we still be able to run and utilize the rest of the USD API for creating and manipulating USD files?

Yes.

Once the SwiftUSD libraries are built and available on the VisionPro, will the toolkit tools also be available? For example, the ability to convert a USD or USDC into USDA? The ability to create a USDZ given a folder of USD* files?

Yep, that's the goal, I believe you are referring to all the usd utilities here (such as usdcat, usddiff, etc.).

Those will all simply be .executableTarget()'s that you can run with:

$ cd ./SwiftUSD
$ swift run usdcat ...

Additionally, I can add swiftpm package (command line) plugins for each of the cli utilities as well, so you can run them from your own swiftpm packages with:

$ cd ./MyCoolUsdSPMPackage
$ swift package plugin usdcat ...
16

Is there still an issue since Alembic is not supported on vOS?

Unless visionOS is doing something drastically different than iOS (which I haven't yet seen to be the case), I don't believe there should be any issues with supporting Alembic on visionOS.

Also thank you for your patience, I am hoping to finally get visionOS supported sometime this month, will let you know when that is ready to go.

17

Also welcome to Swift forums, I just realized this was your first post! I'm not on here very often, but trying to get more involved on these forums.

18

At the moment we don't need it to support Alembic, we just need all the other stuff in openUSD to work. The most important and nearest term need is to be able to zip a folder of USD files on visionOS into a USDZ on the AVP

1 Like
19

Got good news for you,

That should be your missing working python for visionOS to work with SwiftUSD, will run some tests and stuff on my end and push a new release of SwiftUSD shortly with any additional changes that might be required for this to work for you.

~ cheers :slight_smile:

20

You are awesome, thanks! Looking forward ti the new build.