I don't have experience with Maya blend shapes, but I've manipulated Blender armature components programmatically, and you can do so through a Model's joint transforms.

lol! Yes! So much nicer

That I don’t know and I don’t think I have a use case where a window would need to not open in front of the user, either. if you need an accessory window, maybe try a custom ornament view?

I’ve observed that opening a window with a matching value and ID does not bring a window to the front on VisionOS and instead makes a new window

@ZeTof If this works for you, please mark this as an answer so people outside this post know to visit.

Unless the APIs change, this seems like a use case Apple does not want to entertain for 1.0. ”file feedbacks“, etc.

Correct. An immersive space will take the device out of “multi-app productivity mode“ and into a “single app focus mode” of sorts. Perhaps you can create a Volume with a RealityView+attachment but you run the risk of the user rotating your window out of view. ”Billboarding” the attachment so it always faces the user could b disorienting. Also, Volumes do not scale the way windows do. If a user moves a window far from them, it gets bigger to maintain the same visual size. Volumes do not.

If you've got a concise sample project for this already built out, please submit it in a feedback and let us know if there's an answer!

I did not. I rewrote the application to be SwiftUI+AppKit. This has the advantage of unlocking the swiftUI window-size APIs that are hidden from catalyst as well. I think Apple is spread too thin and SwiftUI+UIKit+Catalyst is slipping through the cracks.

Yeah! This can make a lot of sense too, but my app is a Multi-Window app, so while I have an App-level AppState object, I also have A WindowGroup level SceneState. Can you think of any ideas to grab the "right" window state that the intent opens when it brings the app to the foreground? Like I said in a comment above, I think using "App's" "openWindow" environment property is the right solution in that case, but there appears to be a bug in the beta that causes it to not work atm.

Also now discovering that backgrounding and foregrounding my app after launch seems to break openWindow in a more general sense and this could be the source of me not discovering any solutions for this.

Oh gosh, Notification Center sounds like it could actually work. Idk why that didn’t pop into my head. I tried sticking the openwindow object into a singleton and it definitely broke the rest of my opens windowing functionality for unknown reasons. (literally just the act of passing the instance into the singleton cause open window commands from a context menu to fail)

It even feels kind of scammy if they’re going to charge per hour and use slower machines.

This is useful if you're wanting to use the relative shape as a clipping shape (meaning it needs to retain its shape-ness) Otherwise you can use a spacing of 0 and using .padding(3) instead if .inset(by:3) in this example

So.. if I set my options to just [.physics] then I fail to construct a MultipeerConnectivityService(session: session) because it throws the error: RealityKit.MultipeerConnectivityService.SynchronizationError.sceneUnderstandingCollisionEnabled. I don't get this error when I leave sceneUnderstanding options alone. If I set the sceneUnderstanding options to [] or leave it as the default, it constructs fine. Also, I noticed that occlusion was still happening even if I set the sceneUnderstanding options of the ARView Environment to []. I discovered that I was setting the ARSession sceneReconstruction to mesh. Disabling that allowed me to see things without occlusion. Thank you for getting me closer to the right area.