Post

Replies

Boosts

Views

Activity

Reply to LowLevelInstanceData & animation
Hey there, thank you so much for your reply. Yes, I realized that replace(using:) won't work as soon as I noticed that the return buffer is GPU-only, and I am using replaceMutableTransforms on the assumption that replacing could be faster than having GPU read the buffer and hand it over to CPU. The current code is something like this: public struct InstanceAnimatorSystem: System { static let query = EntityQuery(where: .has(SyncInstanceAnimationComponent.self)) public func update(context: SceneUpdateContext) { ... // update states context.entities(matching: Self.query, updatingSystemWhen: .rendering).forEach { entity in guard let instanceAnimation = entity.components[SyncInstanceAnimationComponent.self] else { return } guard let component = entity.components[MeshInstancesComponent.self] else { return } for part in component.parts { part.data.replaceMutableTransforms { transforms in for i in 0 ..< 88 { // 88 instances. let transform = ... // obtain transform transforms.initializeElement(at: i, to: transform) } } } } } } I am using a DispatchSource instead of System here, as System fires update(context:) over 90 times per second, and CPU just can't keep up. The closure itself is extremely efficient though, Xcode Instruments reports nearly no cost. However, both simulator and physical Apple Vision Pro results are pretty poor, runloops hits 20ms all the time, while reporting Custom RealityKit Systems as severe bottlenecks. Time profiler is also showing heavy CPU usage, constantly over 200%, however, about 95% of the work is kernel.release. I'm running Xcode Version 26.4.1 (17E202) and visionOS 26.4.
Topic: Spatial Computing SubTopic: General Tags:
Apr ’26
Reply to LowLevelInstanceData & animation
Hey there, thank you so much for your reply. Yes, I realized that replace(using:) won't work as soon as I noticed that the return buffer is GPU-only, and I am using replaceMutableTransforms on the assumption that replacing could be faster than having GPU read the buffer and hand it over to CPU. The current code is something like this: public struct InstanceAnimatorSystem: System { static let query = EntityQuery(where: .has(SyncInstanceAnimationComponent.self)) public func update(context: SceneUpdateContext) { ... // update states context.entities(matching: Self.query, updatingSystemWhen: .rendering).forEach { entity in guard let instanceAnimation = entity.components[SyncInstanceAnimationComponent.self] else { return } guard let component = entity.components[MeshInstancesComponent.self] else { return } for part in component.parts { part.data.replaceMutableTransforms { transforms in for i in 0 ..< 88 { // 88 instances. let transform = ... // obtain transform transforms.initializeElement(at: i, to: transform) } } } } } } I am using a DispatchSource instead of System here, as System fires update(context:) over 90 times per second, and CPU just can't keep up. The closure itself is extremely efficient though, Xcode Instruments reports nearly no cost. However, both simulator and physical Apple Vision Pro results are pretty poor, runloops hits 20ms all the time, while reporting Custom RealityKit Systems as severe bottlenecks. Time profiler is also showing heavy CPU usage, constantly over 200%, however, about 95% of the work is kernel.release. I'm running Xcode Version 26.4.1 (17E202) and visionOS 26.4.
Topic: Spatial Computing SubTopic: General Tags:
Replies
Boosts
Views
Activity
Apr ’26
Reply to `NSWorkspace.open` cannot deal with `xcodeproj`
Finally found the answer, you can use the legacy API, which works flawlessly. LSOpenCFURLRef(url as CFURL, nil)
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
Boosts
Views
Activity
Aug ’25
Reply to `NSWorkspace.open` cannot deal with `xcodeproj`
ChatGPT found a way to deal with this using deprecated symbols: try NSWorkspace.shared.open([path.url], withAppBundleIdentifier: "com.apple.dt.Xcode", options: .default, additionalEventParamDescriptor: nil, launchIdentifiers: nil) I suppose there is something wrong with the latest APIs.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
Boosts
Views
Activity
Feb ’24