[SOLVED] Application data_path

[eugene.litvinov]

I have several projects: main project and some test projects for testing. Often I move some functionality between this projects. And each time I need to change include paths in script, linkages to materials, nodes, meshes and gui files. Changing data_path to my project folder is not help, cause final data path is data_path + "data", and this "data" is adding Unigine. Now in my projects used next include paths, example:

one project:

#include <source/scripts/Global.h>

another (test project):

#include <test_blending/scripts/Global.h>

 

So it isn't flexible :)

[binstream]

You can gather all location-sensitive includes in a single header and modify only that file.

[luke.errington]

Is it possible to get some modifications in Unigine to support this?

 

We have a situation where we release source scripts (and materials, etc.), from one repository, to other repositories, which then will add their own scripts, materials and so forth. It would help us greatly if we could have multiple include paths ... or effectively multiple data directories ... and where these could be specified to the Unigine engine on construction.

 

This would allow us to work with them in the natural directory structure that they arrive in, rather than copying them all to be under the data directory, which would give us multiple copies of files and also where modifying what is under data would not modify the actual source.

 

Having only one data directory also stops us from having multiple Unigine applications using their own scripts but sharing common materials (from a different, unrelated, directory). We are not sure how to achieve this at the moment without copying and moving files around, which makes configuration management difficult.

 

Is this much work? ... to add multiple 'include paths'? (... or rather, to have multiple directories on the include path?)

Thanks.

[ashwin.sudhir]

We had a similar problem, whereby we needed different versions of scripts based on the Configuration or Build.

We made different headers (which would include all files required internally) for different configurations.

Then we made a conditional #include (a #ifdef) in the "master" header file (unigine.cc for us) and passed this in as an EXTERN_DEFINE from C++ and this worls well for us.

Hope the example makes it clearer

 

#ifdef DEV
#include <..\\..\\src\\UnigineScripts\\GLibDev.cc> 	// picks up the dev version of scripts
#else
#include <GLib.cc>									// picks up scripts from the data folder
#endif

 

If you notice, the dev build scripts are outside the data directory, referenced using relative paths. I am guessing this is what you need.

 

and while initializing Unigine, we pass in an EXTERN_DEFINE as a startup commandline arg based on the config

-extern_define DEV

 

HTH,

Ashwin.

[luke.errington]

Hi Ashwin,

 

Thanks for your idea. That is interesting, and we may be able to use it. It is still a bit painful though ... I wonder if we can pass the relative path through the -extern_define too (e.g. DEV_PATH=.\\..\\src\\UnigineScripts\\). I'll have to test if this can be handled.

 

However, this is some work-around for a problem that would be nice to have solved natively. Include paths, or their equivalent, are a standard capability for source management in other languages.

 

Additionally, while this work-around addresses scripts, we would, equivalently, like to be able to distribute resources too (such as materials and nodes) and it seems as though these all need to be under the one data directory at the moment. (This is the idea behind phrasing the suggestion as 'multiple data paths'.)

 

Does anybody from Unigine have an idea if this can be supported?

 

Luke

[danni.coy]

Because of our industry we have a lot of small jobs (relatively speaking).

We use the same Unigine folder for all our projects (version controlled).

our filesystem looks something like this

 

+data+-+
      +- core
      +- demos
      +- library (all shared assets go here).
      +- jobs +-+
      |         +- job1 
      |         +- job2
      |         +- TEMPLATE (starting point for new projects)
      |
      +- ai3d +-+
                + - config (shared config files)
                + - scripts (shared scripts)

 

all our world.cpp files look like this.

#include <ai3d/scripts/main.cpp>

should I want to do experimental stuff I can change this script to point to a new location or add a new include.

 

We have a script that creates a new unigine build with only the assets we are using for the finished product.

[manguste]

Storing resources under one data directory allows to avoid name collision problems, it also means faster reloading of resources and is altogether cleaner and more transparent solution. Try creating a hierarchical data structure as Danni Coy suggested or use defines according to the example of Ashwin Sudhir.

[luke.errington]

So I gather that Unigine can't/won't support this?

 

I don't really see how having everything under one directory reduces collision problems, speeds up resource reloading, or is cleaner and transparent. I guess this will differ for each person's situation. Ultimately it is the same number of files (and probably even folders). As mentioned, breaking source code up into different directory paths supports commonality and is used a lot within programming languages.

 

Ashwin's idea wasn't so useful to us because we can't associate a string with a preprocessor 'symbol/define'. (I tried it but it didn't seem to work.)

 

Danni's structure seems mandatory and we will have to use it, but it doesn't work so well with common scripts coming from a separate repository (or install/release) and so logically arriving in a different location to the project's data structure (ignore the extern possiblity). Danni's seems to work better when all projects are managed within the one repository.

[danni.coy]

If you want to do separate release/test structures....

you can do this something like the following

 

#ifdef RELEASE

#include <ai3d/scripts/release/World.cpp>

#else

#include <ai3d/scripts/testing/World.cpp>

#endif

 

when launching the engine you will need to use the following -extern-define RELEASE to make it use the release code path.

[luke.errington]

Our situation is more like:

 

+- job1 +-+
     	+- data +-+
             	+- core
             	+- library
             	+- scripts
+- job2 +-+
     	+- data +-+
             	+- core
             	+- library
             	+- scripts
+- common +-+
     	+- scripts

... where a key point is that job1 and job2 and common are all in separate repositories, and we can't just roll them all together for numerous management reasons, not least of which is that job1 and job2 are HUGE because they contain a lot more than just Unigine-related files. job1 and job2 both need to be able to use the scripts in common. Hard-referencing file paths (like ../../common/scripts/) in script is ugly and may break if we ever rearrange the structure (such as for a release - what is shown is the development structure.) We don't want to copy the scripts in common/scripts because then development will be done on the copy, and not on the original, which produces configuration management hazards.

 

What would be neatest is just if we could add common/scripts, through a command-line argument, to the 'include path'.

[ashwin.sudhir]

@luke

How about "injecting" your paths into Unigine.cc (e.g.) just prior to initializing Unigine? By this I mean using File I/O operations to insert the correct path into Unigine.cc according to your build config.

[danni.coy]

We are investigating the use of symlinks (these appear to be available on windows via command line) in order to share assets between two projects.

Will post once I have verified that using this process works.

[binstream]

You can also use SVN externals during development: http://svnbook.red-bean.com/en/1.6/svn.advanced.externals.html

[sergey.shandar]

You can also use SVN externals during development: http://svnbook.red-b....externals.html

SVN externals are good for subprojects. For example, when Unigine references on some third-party projects. But we have projects which references on Unigine and several other frameworks. :-( It would be good to have at least one additional data_path.

[frustum]

We will provide a plugin for external data loading.

[frustum]

FileSystem plugin is ready. They support up to 16 arbitrary directories.

You should run the engine with the following command line parameters:

-extern_plugin FileSystem -file_path "C:/first_data/" -file_path "C:/second_data/" ...

After that this settings will be saved in the engine config file.