Log in or register to post comments

Upgrade Guidance required

January 30, 2014 - 7:02am #1

We were going to upgrade the version of Vuforia that we use in our projects, but as it stands now we cannot. By moving several scripts into the new dll Vuforia have disabled us from using some custom functionality that was core to how many of our projects worked.

This mainly involves to removal of DataSetImpl which we had extended to allow for the loading of DataSets from custom locations (we do the same with video files too).

The extended trackers is a new exciting feature that we really want to make use of, but the upgrade nightmare is currently halting our progress.

Is there a version available with the new features but still in full source code without the dlls?

Upgrade Guidance required

February 28, 2014 - 6:09am #12

I see. The ImageTargetEditor looks for the image target textures in a specific directory, these textures are used for rendering the Image Targets in the scene view of the Editor. So, you should not move the location of those "special" directories used by Vuforia,  even if in previous versions of Vuforia this was "technically" possible by modifying the editor script code to point to a custom path. 

If this is somewhat in conflict with your "desired" directory structure in your project, my suggestion is to introduce a distinction between Vuforia specific assets and other assets you use in your project, and apply your specific desired directory arrangement to the latter.

I will also bring this issue to the attention of our team, just in case there is any additional tip that they could share on this topic.


Upgrade Guidance required

February 26, 2014 - 5:23am #11

Moving the materials, for example, causes an error within ImageTargetEditor, which we have no access to. How can we update the paths?

Upgrade Guidance required

February 26, 2014 - 5:15am #10

Yes, but you should be able to do that using the public API. 

Upgrade Guidance required

February 26, 2014 - 5:09am #9

We're not wanting to customise any of the internal code. I want to have the freedom to place my ImageTargetTextures, Data Sets and Default Materials in a more sensible place within our projects without causing a load of errors.

Upgrade Guidance required

February 26, 2014 - 5:02am #8

The reason is that the Vuforia internal code is not meant to be modified or exposed to public; the Vuforia SDK offers a public API, and this is what developers should use. 

I understand that customizing the "internal code" of Vuforia can be sometimes an easy and nice shortcut to obtain specific results, however this approach does not represent the recommended way of using Vuforia API, and as such it has been deprecated with the new version of the SDK.

Upgrade Guidance required

February 26, 2014 - 4:33am #7

That is my point and my query. Why has everything been wrapped up in a DLL? WIthout access to the QCARUtilities all the paths that you have declared are now set in stone, giving us no flexability to move files about to fit in with our project structure.

Upgrade Guidance required

February 20, 2014 - 7:20am #6

OK. QCARUtilities.cs is now built into the DLLs, so the source code is no longer available.

So, you will probably need to re-write that portion of "customized" code in a way which relies on just using the public API

Upgrade Guidance required

February 20, 2014 - 5:29am #5


Namely it's GlobalVars struct which contained definitions for paths for all the materials/prefabs/shaders etc, which allowed us to change the folder structure away from the default that is imported.


Upgrade Guidance required

February 20, 2014 - 5:23am #4

Do you remember the name of the specific script you are referring to ? 

Upgrade Guidance required

February 20, 2014 - 5:14am #3

As long as we can load datasets from the application.persistantdatapath then we should still be ok. How about the script that allowed us to define paths for where Vuforia looked for certain things such as materials and webcam profiles? Where can that now be found and set?

Upgrade Guidance required

January 30, 2014 - 12:41pm #2


have you checked this article:


This illustrates how you can load a Dataset from device storage; more in general, you should be able to load Datasets from various location using the standard API;  is there some specific functionality that you cannot achieve with the API (i.e. without modifying the DataSetImpl class) ?


Log in or register to post comments