Where to find the "canonical" HoloToolkit package?

NobleRobot

I recently completed the 230 tutorial and am now excitedly applying its lessons to my own project. In my project I'm using the HoloToolkit files that are found on GitHub, and immediately faced the same problem from as the person who posted this thread.

According to the solution from that thread, it seems that the HoloToolkit files on GitHub are an older version than the HoloToolkit files in the 230 tutorial package.

I just assumed the project on GitHub was the "canonical" HoloToolkit. Is that not true? Where can I go to find the most up-to-date version of the HoloToolkit, both now and in the future when it is updated?

Thanks!

DavidKlineMS

@NobleRobot,
In the majority of situations, the most up to date HoloToolkit will be on GitHub. The example you point out (ObjectSurfaceObserver) is an exception. This component debuted in an update to Holograms 230 and should be moving to GitHub in the near future. You can feel free to use this class in your projects.

The intent of ObjectSurfaceObserver is to enable prototyping in the Unity editor with Spatial Mapping data saved from your HoloLens device (via the Device Portal's 3D View page). The FileSurfaceObserver is a bit more complicated, requiring additional scripts and establishing a connection between the HoloLens and the development PC to send the Spatial Mapping mesh data over the network, where it can be saved and loaded by the Unity editor.

Hope this clears up any confusion.

Thanks!
David

HoloSheep

@NobleRobot the GitHub version of the HoloToolkit files is the latest and greatest.

The existing Academy tutorials are based on either earlier versions, or predate the HoloToolkit (as in the case of the Origami project) or are some form of customized approach that is partially based on a prior version of the Toolkit.

The HoloToolkit is evolving, and as such I don't think the Academy courses are focused (or able) to keep pace with instructing how to use the toolkit, instead I think they focus on giving examples of how to use features of the underlying Windows Holographic platform.

The HoloToolkit is also still a long ways off of being a solid or complete toolkit layer and you can expect to encounter a need to customize the scripts that come in the toolkit for pretty much anything beyond a number of basic happy path scenarios until it matures based on numerous factors including the communities input.

So yes, a component that you might use in a particular Academy session has a good chance of having changed or had naming and other forms of refactoring occur to it since the time the Academy session was put together. But it is the versions of the toolkit in the Academy sessions that are older than the GitHub version, not the other way around.

It is less than ideal, but it is not that unusual, and is a small price to pay, to be involved with and working on a platform like Windows Holographic at such an early stage.

I hope that helps clear up some of the confusion.

NobleRobot

That's what I assumed when I chose to use the GitHub files in my project, but I've compared the code, and it looks like at least one of the Classes in the tutorial packages has improved functionality over the one on GitHub, specifically ObjectSurfaceObserver.

The thread I posted references an older version of that Class from an earlier version of the tutorial, which seems to describe the FileSurfaceObserver class that is in the GitHub package. ObjectSurfaceObserver, however, is nowhere to be found.

Of course, it seems not unlikely that I have it backwards, that ObjectSurfaceObserver has been depreciated in favor of FileSurfaceObserver, but that doesn't make sense because ObjectSurfaceObserver really seems to be the more robust implementation.

Jimbohalo10

I saw this recently , updated 11-may-2016 I think, so Download the most updated 211 Gestures code https://github.com/Microsoft/HolographicAcademy/archive/Holograms-211-Gesture.zip
The problems are noted at the top of Tutorial: Debugging with Holograms 211 with update code library

This zip contains the latest HoloLens Library

HoloSheep

@NobleRobot and @Jimbohalo10 in both of the Academy tutorial downloads that you mention, the HoloToolkit folders are only a partial subset of files and folders of that particular earlier generation of the HoloToolkit.

Here are the contents of a recent version of the HoloToolkit folder downloaded from Github:

and here the contents of the Academy 230 session:

and here the contents of the Academy 211 session:

Judge for yourselves, but I believe the academy sessions include partial collections of earlier versions of the HoolToolkit project and may in some cases have either customizations that were particular to the given tutorial exercise or have code and components that have been rethought and/or refactored with the most current git hub version of the toolkit.

NobleRobot

the HoloToolkit folders are only a partial subset of files and folders

Yes. For example, I noticed that the 320 files doesn't include the TapToPlace class or other helper classes. This is what led to my confusion in the first place, because it seemed like there was no single place to get the most up to date versions of every component in the kit.

This is particularly difficult to deal with in Unity, where prefab objects will often just break when the many component scripts they depend on are modified.

may in some cases have either customizations that were particular to the give tutorial exercise or have code and components that have been rethought

That's _exactly _my point, I guess. I'd rather not "judge for myself." I'd rather someone from MS (or a forum user who knows for certain) to let us know what's the deal.

This is all pre-release beta stuff, so all I'd like is the story. It's hard enough to manage and organize code on my own projects, so I don't expect MS to "fix" anything, just to explain why it seems this way (even if there's no problem at all).

The uncertainty, coupled with the fact that the the GitHub classes are not as well documented as the classes from the tutorials (which makes sense), makes it harder (for me, anyway, a Unity non-expert) to get a project rolling.

HoloSheep

Okay @NobleRobot since you don't seem to believe/trust me or my above explanations, I will let someone from Microsoft address your concerns.

But for anyone else out there that is wondering the latest Unity version of the HoloToolkit can be found on GitHub at this location.

At the time of this post the "Latest commit" to the above GitHub repo was one day ago by @neerajwadhwa so perhaps he will clarify.

NobleRobot

@HoloSheep, it's not that I don't believe you, it's that you're not answering the question I'm asking, and implying that my actual question is irrelevant. For what it's worth, I think that what you're saying is very probably right, but I already assumed as much before I even asked my question.

I'm asking about it because if it is the case that the GitHub repo has the most up-to-date versions of everything, what's the explanation for the missing ObjectSurfaceObserver? etc.

Or maybe I just need some documentation on FileSurfaceObserver. ;-)

Jimbohalo10

@NobleRobot There is little real difference. The picture shows the two versions running side by side. The rename reflects in my opinion the fact that the default "Object Surface Observer" uses "Room Name" as parameter and in the "File Surface Observer" uses "File mesh name". These items replace the HoloLens device functionality for the HoloLens Emulator. The later version "File Surface Observer" uses "File mesh name" and reflects its function.

I have checked the script code and here are the declarations

public class ObjectSurfaceObserver : SpatialMappingSource

public class FileSurfaceObserver : SpatialMappingSource
They are basically identical. If you need to see these in further detail. Switch to using MonoDevelop from Unity Editor as when you place you mouse over a variable this shows the source and understands more than Visual Studio seems to display

NobleRobot

It's not just for the emulator, it's also for testing in the Unity editor. It's a very useful feature.

With ObjectSurfaceObserver, you pick from a previously imported .obj asset using the Unity UI, and the code in the Class reflects that.

With FileSurfaceObserver, however, you manually enter a string that is supposed to represent a file name "without extension or path." I'm sure this does work, but I haven't yet figured out what to put in there to make it work. I'm sure I'm just missing something, but it feels rudimentary compared to ObjectSurfaceObverser, and is undocumented.

From what I can suss out, though, I agree with your supposition that the actual end result of both classes are identical. Again, this is why I suspected that ObjectSurfaceObserver was "newer," because it appears to be a more robust implementation of the same functionality.

DavidKlineMS

@NobleRobot,
In the majority of situations, the most up to date HoloToolkit will be on GitHub. The example you point out (ObjectSurfaceObserver) is an exception. This component debuted in an update to Holograms 230 and should be moving to GitHub in the near future. You can feel free to use this class in your projects.

The intent of ObjectSurfaceObserver is to enable prototyping in the Unity editor with Spatial Mapping data saved from your HoloLens device (via the Device Portal's 3D View page). The FileSurfaceObserver is a bit more complicated, requiring additional scripts and establishing a connection between the HoloLens and the development PC to send the Spatial Mapping mesh data over the network, where it can be saved and loaded by the Unity editor.

Hope this clears up any confusion.

Thanks!
David

NobleRobot

Thanks! That's exactly the explanation I was looking for. Much appreciated.