Sure did! I’ve tried with collision shares off of Wall targeted anchors and world targeted anchors. Both appear to have an odd “offset” behavior associated with the tap location.
I’m told the offset for wall-targeted anchors is expected, but the one with the world targeted anchor was possibly a bug.
J0hn
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
From
Dallas, TX, United States
Post
Replies
Boosts
Views
Activity
"movement upward should move the entity away from me"
In the simulator you can hold shift to move things away from or toward the camera.
Still working with them. It turns out entities that are not descendants of a world targeting Anchor entity will not return accurate position3D information in the spatial tap gesture handler.
If we want that capability we should file a feedback.
@FrankZielen
Hmm, Yeah addChild should work for that.
Content.add will add the attachment View relative to the 0,0,0 position of the realityView.
If you add it to a parent entity it will be added relative to the 0,0,0 position of that entity. Is it possible its inside the parent entity?
I suspect Apple may keep those tools locked down to prevent Unreal from gaining tractions on the platform.
Are Apple employees allowed to file feedbacks on behalf of the community?
I am going to mark this as the accepted answer. While I don’t like needing to place and manage my own Collision-enabled Entities, it enables both a SpatialTapGesture and raycast solution.
I was hoping there was a way that did not involve manually creating and managing plane collision shapes as the PlaneAnchors change size and location.
Also, I think if I did manage my own collision shapes, I could use a simpler TapGesture to detect the tap and 3D location of the tap instead of using a recast.
" For example, data about the other personas (outside of their immersion status) is not exposed via APIs. I am guessing this is for privacy reasons (?)." Could each persona share it's world anchor and keep it updated within the SharePlay session?
Only work around I could think of was requesting a dev kit. iOS and VisionOS have enough differences with ARKit, that I'm not sure it's worth it for me to deal with that for a hobby project.
If I don't get a dev kit, or the simulator doesn't get updated, I'm probably SOL for a few years.
I will also add that despite Vision Pro being designed to not keep the user isolated from the world around them, shareplay experiences don’t seem to consider users as being in the same space.
I’d bet it’s being saved as a 2.0 thing. Shareplay this year even feels like a 2.0 version of multipeersharing.
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