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

Problem with the nuget package for Preview2 #1

Open
laultman opened this issue Jul 10, 2022 · 5 comments
Open

Problem with the nuget package for Preview2 #1

laultman opened this issue Jul 10, 2022 · 5 comments

Comments

@laultman
Copy link

Everything is fine in the StereoKitRemoting app until you start adding other namespaces and assemblies. It seems that the debugger can't find the StereoKitC.dll in the runtime folder.

@laultman
Copy link
Author

laultman commented Jul 10, 2022

Issue resolved. Has to do with the order in which the StereoKit is initialized in a UWP vs Windows (console) app. The call to SK.Initialize(settings) has to come very early. In my UWP app I am doing a lot of stuff to initialize from cloud resources before making the first call to StereoKit which in turn uses the StereoKitC.dll. In UWP I am showing an extended startup screen to let user know. Doesn't happen in a console app.

This code is what threw me off:
// Preload the StereoKit library for access to Time.Scale before initialization occurs.
SK.PreLoadLibrary();
Time.Scale = 1;

I thought this caused the StereoKitC.dll to be "loaded", it does not.

My new startup sequence is sort of like this:

  1. Do all my windows and cloud stuff, including getting my StereoKit app settings.
  2. Set all my locals.
  3. Call the SK.Initialize(settings).
  4. Queue up my scenes and load any long-lived objects.
  5. Run the Step()

The unfortunate thing is the user has to wait while it loads.

I am thinking about creating a "loading scene" and then go do the sequence to fetch windows and cloud resources and then kick-off my main app step.

Hope this help others

@laultman
Copy link
Author

One more thing on the load sequence. You must add the HolographicRemoting BEFORE calling SK.Initialize() or StereoKit defaults to Windows Screen display.

		// Network IP address of HoloLens Device using this instance.
		SK.AddStepper(new HolographicRemoting(ipRemoteDevice));

then...
// Initialize StereoKit, must be done very early in the process
IsSKready = SK.Initialize(startupSettings);

You can check the SKready status in your downstream code.

@maluoi
Copy link
Contributor

maluoi commented Jul 10, 2022

SK.PreLoadLibrary();
Time.Scale = 1;

I thought this caused the StereoKitC.dll to be "loaded", it does not.

SK.PreLoadLibrary() should be loading StereoKitC.dll in most scenarios. SK.Initialize does in fact call the same code path as its first step, if it hasn't already been called! However, what that means in a situation like UWP + .NET Native is a bit fuzzy to me, that may get a bit more complicated. Are you using ARM, ARM64, or x64? I'll look into that a little further to see if there's something there that can be improved on, whatever may be happening there doesn't sound ideal.

Might also be good to note, Holographic Remoting should work fine with console style apps!

I'd definitely recommend getting the application active and initializing things async in the background! This might be a good occasion for a scene system, with a separate loading scene. You can find a relatively simple scene system over in this project, ( https://github.com/StereoKit/StereoKitReleaseNotes/tree/main/v0.3.1 ) might be a nice source of inspiration!

One more thing on the load sequence. You must add the HolographicRemoting BEFORE calling SK.Initialize() or StereoKit defaults to Windows Screen display.

Skipping this would have surfaced an error in the log! UWP doesn't seem to surface the log very well though, which is kinda unfortunate. It seems to hide the log if you don't have native debugging on, which is the default :( This sounds like a good place for me to throw exceptions instead.

@laultman
Copy link
Author

It is a little strange that the pre-load does not seem to actually pre-load. I can think of several things happening that could cause this, now that you explained the execution path. The first may simply be disk load latency even with SSD drives Windows can be awfully busy doing other stuff. Another could be the runtime being lazy if you don't actually call anything that "needs" the library. Naturally it could be both. My expectation would be though, given the error reported "not found" a pointer is being lost between the time the pre-load is called and the call to Initialize.
I am testing on both ARM64 and X64. I'm thinking about making a backpack configuration. Also, the console app model in a backpack is very desirable. With a little work I can make it into a system function to load on boot. My ARM64 machine has a cellular hotspot that makes this very cool!
I'm going to be working on Azure Object Anchors, and I'm trying to use the World Locking Tool code.
Thanks for the heads up on the Scene system, I'll take a look. Right now, I'm just fighting with the simple stuff. Trying to make it more like the native HL2 themes and actions. I hope that MS continues the HL2 line. To me, customers we work with really want it - they've tried other devices. Insights appreciated? You have my em.

@laultman
Copy link
Author

General questions. Why does the bounding box respond to pinch several inches from the bounding box? I'm using the DemoMath example.
How do you or can you have a visible bounding box on a cube? This code shows a cube but no bounding box. Trying to emulate the standard HL2 behavior of a bounding box.
` bool boundsRayActive = UI.HandleBegin(Id, ref Sys.defaultPose, bsize, false, UIMove.Exact);
boundsMesh.Draw(boundsMat, Matrix.S(size), boundsRayActive ? active : notActive);

		Bounds bounds = new Bounds(size);
		cubeObject.mesh.Draw(material, Matrix.TS(bounds.center, size), colObj); //floorTransform, color); //
		UI.HandleEnd();

`

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

No branches or pull requests

2 participants