Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

iOS project export bound to Arkit, itself faulty #33406

Closed
oeleo1 opened this issue Nov 6, 2019 · 8 comments · Fixed by #33759
Closed

iOS project export bound to Arkit, itself faulty #33406

oeleo1 opened this issue Nov 6, 2019 · 8 comments · Fixed by #33759

Comments

@oeleo1
Copy link

oeleo1 commented Nov 6, 2019

Godot version:
v3.2.beta.custom_build.500863859

OS/device including version:
macOS Mojave, iOS 13.1, 13.2 / iPhone SE, iPad Pro Models A1673 (1st gen) and A1980 (3rd gen)

Issue description:

  1. iOS project export : when the Arkit Capabilities option is unchecked, the export archive fails with unresolved symbols:
Undefined symbols for architecture arm64:
  "_OBJC_CLASS_$_ARSession", referenced from:
      objc-class-ref in Game.a(arkit_interface.iphone.debug.arm64.o)
  "_OBJC_CLASS_$_ARWorldTrackingConfiguration", referenced from:
      objc-class-ref in Game.a(arkit_interface.iphone.debug.arm64.o)
ld: symbol(s) not found for architecture arm64

This effectively foces Arkit inclusion in the project export to succeed, which is not wanted.

  1. When successfully exporting the project with the Arkit Capabilities option checked and deploying the game on a device, the game asks for Camera access permission on startup. Refusing access proceeds as expected. However, granting camera access crashes the game with invalid thread access in CameraIOS::update_feeds(), line 362 (AVCaptureDeviceDiscoverySession *session = ...)

Steps to reproduce:

Minimal reproduction project:

@BastiaanOlij
Copy link
Contributor

BastiaanOlij commented Nov 7, 2019

@akien-mga not sure what we can do about (1) other then compiling a copy of Godot with and one without ARKit support. Kind of the same issue as we're having with the other dependencies on iOS, you always have to include the frameworks for the bits code exists in Godot, even if you're not using it. It should definately be possible to keep the ARKit tickbox unticked while still including the framework as long as you untick it in the export settings. If you untick it in xcode, XCode tries to be too smart and removes the frameworks. Same as the other privileges btw, it gets really annoying.

I don't know what is causing the camera issues though, this one is weird. If the permission strings are omitted from the plist all together the whole camera code is skipped so why Apple is suddenly complaining about that I don't know.
When the capabilities are enabled when Godot starts up it asks iOS for a list of available cameras, why that code is crashing all of a sudden I don't know, unless XCode again has removed the required frameworks because you've toggled switches inside of XCode.

@akien-mga
Copy link
Member

not sure what we can do about (1) other then compiling a copy of Godot with and one without ARKit support. Kind of the same issue as we're having with the other dependencies on iOS, you always have to include the frameworks for the bits code exists in Godot, even if you're not using it. It should definately be possible to keep the ARKit tickbox unticked while still including the framework as long as you untick it in the export settings. If you untick it in xcode, XCode tries to be too smart and removes the frameworks.

Can we dynamically open (dlopen() or similar) the ARKit framework when initializing Godot on iOS, instead of hardlinking it? Since it seems to be part of iOS itself, I guess we can locate and load it without risk that some users might lack it?

@BastiaanOlij
Copy link
Contributor

BastiaanOlij commented Nov 8, 2019 via email

@bruvzg
Copy link
Member

bruvzg commented Nov 8, 2019

With some Obj-C indirection loading ARKit dynamically should work, and AFAIK loading system libs/frameworks is OK (loading custom libs is prohibited):

Like replacing:

ar_session = [ARSession new];

with:

Class ARSessionClass = NSClassFromString(@"ARSession");
if (ARSessionClass == Nil) {
	void *ARKitHandle = dlopen("/System/Library/Frameworks/ARKit.framework/ARKit", RTLD_NOW);
	if (ARKitHandle) {
		ARSessionClass = NSClassFromString(@"ARSession");
	} else {
		//FAIL
	}
}
ar_session = [ARSessionClass new];

and so on (same for ARWorldTrackingConfiguration).

@BastiaanOlij
Copy link
Contributor

@bruvzg that looks very promising :) I need to find some time to try that.

I think if we move the code for detecting ARSessionClass and ARWorldTrackingConfiguration (and any others we need) where we register the ARKit classes, then we simply never instantiate and register the ARKitInterface if that fails.

@HEAVYPOLY
Copy link
Contributor

I'm getting the Arkit issue as well although my project does not use ArKit. Not sure if this is improper etiquette, just want to confirm this.

@akien-mga
Copy link
Member

@bruvzg Would you be able to make a PR based on your findings?

@bruvzg
Copy link
Member

bruvzg commented Nov 20, 2019

@bruvzg Would you be able to make a PR based on your findings?

I have opened PR (#33759), but it's only tested with simulator.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants