Post not yet marked as solved
I'm currently developing an application where the models present inside a volumetric window may exceed the clipping boundaries of the window. ( Which I currently understand to be a maximum of 2m )
Because of this, as models move through the clipping boundaries, the interior of the models becomes visible. If possible, I'd like to cap these interiors with a solid fill so as to make them more visually appealing.
However, as far as I can tell, I'm quite limited in how I might be able to achieve this when using RealityKit on VisionOS.
Some approaches I've seen to accomplish similar effects seem to use multiple passes of model geometries rendering into stencil buffers and using that to inform whether or not a cap should be drawn. However, afiact, if I have opted into using a RealityView and RealityKit, I don't have the level of control over my render pipeline such that I can render ModelEntities and also have multiple rendering passes over the set of contained entities to render into a stencil buffer that I then provide to a separate set of "capping planes" ( how I currently imagine I might accomplish this effect ).
Alternatively ( due to the nature of the models I'm using ) I considered using a height map to construct an approximation of a surface cap, but how I might use a shader to construct a height map of rendered entities seems similarly difficult using the VisionOS RealityView pipeline. It is not obvious to me how I could use a ShaderGraphMaterial to render to an arbitrary image buffer that I might then pass to other functions to use as an input; ShaderGraphMaterial seems biased to the fact that all image inputs and outputs are either literal files or the actual rendered buffer.
Would anyone out there have already created an effect like this that might have some advice? Or, potentially correct any misunderstandings I have with regards to accessing the Metal pipeline for RealityView or using ShaderGraphMaterial to construct a height map?
I'm attempting to regularly interact with ApplicationMusicPlayer in MusicKit, even while in the background. I'd like to allow for changes in the network to allow me to change songs.
While this works fine while the application is in the foreground, due to idiosyncrasies with how ApplicationMusicPlayer does not in fact "count" for your application actively playing audio while in the background my network connection becomes lost.
I would like to check the network again while the app is in the background, and it seems like I could do so with BGAppRefreshTask. However, the frequency that I'd like to request would be on the order of sub-30s refresh timelines. This seems...excessive, given how BGAppRefreshTask seems to be documented.
Are there best practices in terms of what is an appropriate interval for BGAppRefreshTask being executed? Is there an upper or lower bound on intervals that is known? Should I consider using something different to achieve what I'm after?
Thanks for any help.
I'm attempting to create a service that:
Listens on iOS device A using NWListener
Broadcasts the NWService ( using NWListener(service:using:)) ) on Bonjour
Allows a separate device, iOS device B, to receive information about that service via an NWBrowser
Connect to that service using the information contained in NWBrowser.Result 's NWEndpoint
I've been able to successfully do this using a SwiftNIO service, in the following environments:
iOS device A and iOS device B are physical iOS devices on the same WiFi network. This works.
iOS device A and iOS device B are iOS simulators on the same machine. This works.
iOS device A is a physical device, and iOS device B is a simulator. iOS device A is not connected to a WiFi network, iOS device B is connected to a WiFi network. This works.
However, when iOS device A and iOS device B are physical devices that are not connected to a WiFi network, I encounter the following behavior:
The Bonjour service is correctly advertised, and iOS device A and iOS device B are able to observe the advertisement of the service.
In both cases, iOS device A and iOS device B, while able to resolve an NWEndpoint for the Bonjour service, are not able to connect to each other, and the connection attempt hangs.
My setup for the listener side of things looks roughly like:
let opts: NWParameters = .tcp
opts.includePeerToPeer = true
opts.allowLocalEndpointReuse = true
let service = NWListener.Service(name: "aux", type: BONJOUR_SERVICE_TYPE, domain: "")
try bootstrap.withNWListener(NWListener(service: service, using: opts)).wait() // bootstrap is an artifact of using SwiftNIO
Similarly, my setup on the discovery side of things looks like:
let params: NWParameters = .tcp
params.includePeerToPeer = true
let browser = NWBrowser(for: .bonjour(type: BONJOUR_SERVICE_TYPE, domain: BONJOUR_SERVICE_DOMAIN), using: params)
browser.browseResultsChangedHandler = { (searchResults, changed) in
// save the result to pass on its NWEndpoint later
}
and finally, where I have an NWEndpoint, I use SwiftNIO's NIOTSConnectionBootstrap.connect(endpoint:) to initialize a connection to my TCP service ( a web socket server ).
The fact that I am able to get P2P networking (presumably over an awdl interface?) between the simulator and the iOS device suggests to me that I haven't done anything obviously wrong in my setup. Similarly, the fact that it works over the same WiFi network and that, in P2P, I am able to at least observe the Bonjour advertisement, strikes me that I'm somewhere in the right neighborhood of getting this to work. I've also ensured that my Info.plist for the app has a NSLocalNetworkUsageDescription and NSBonjourServices for the Bonjour service type I'm browsing for.
I've even attempted to exercise the "Local Network Permission" dialog by using a hacky attempt that sends data to a local IP in order to trigger a permissions dialog, though the hack does not appear to actually force the dialog to appear.
Is there some trick or other piece of knowledge regarding allowing the use of P2P w/ Network.framework and TCP connections to services?
netshade.