The simulator provides an occlusion Mesh visualization when that debug option is enabled, so the data appears to be there but it is not plumbed to the data providers.
This is the number one risk with code-once platforms. Product Owners need to understand they can’t be on the leading edge of anything with those solutions.
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.
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 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.
The simulator provides an occlusion Mesh visualization when that debug option is enabled, so the data appears to be there but it is not plumbed to the data providers.
This is the number one risk with code-once platforms. Product Owners need to understand they can’t be on the leading edge of anything with those solutions.
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.
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 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.