[SOLVED] Terrain Editor looking in wrong path for mask texture

[taylormorris]

We are having a problem with the Terrain Editor feature. When trying to paint a mask texture on the terrain, it is attempting to open and save the mask texture file from the wrong location. It isn't clear exactly what logic the editor is using to find this file, but it looks like the path is attempting to be relative to the exe/batch file.

 

We have our project split between two 'data' directories with different parent folders- one that manages assets and another that manages project-specific things. The exe is project specific, but the terrain files, world file, and layer node are in the other directory.

 

It is very strange that it wouldn't start with the world or node file to find its relative path of the file, please help us understand what is going on!

[silent]

Hi Taylor,

 

Could you please provide a small step-by-step guide how to reproduce this behavior (which directories structures do you have, what engine startup parameters are required, expected results, actual results)?

 

Thanks!

[taylormorris]

Directory Structure

-core

--data

---terrain files & image/mask files

-project

--bin/exe

--data

---world files & layer nodes

 

Relevant Startup options

• -data_path "../"
• -extern_path "../../../../../core/data/"
  • there are some folders i've edited out of directory structure above but everything has been loading and saving just fine except for this Mask brush in Terrain editor

 

Step-by-Step

1. Open editor
2. Open terrain editor
3. Attempt to paint with Mask Brush
4. Get error saying it can't find the load the dds file and prints a full path to an incorrect directory (reads project/data/terrain/dds, should be core/data/terrain/dds)
5. Attempt to paint with Heights Brush or Holes Brush
6. No error, loads dds file and prints full path to correct directory (reads core/data/terrain/dds)

 

This probably should have been in bug reports, sorry!

[silent]

Hi Taylor,

 

Thank you for the additional information. I will try to reproduce this behavior on my local PC too, but it might take some time. 

 

Could you please also provide small part of your project (with launchers, correct directory structure, world files and terrain masks) to us for investigation? It will surely speed up the debugging process (especially, if I would fail to reproduce the issue).

 

You can upload it to our ftp server (~15 GB free):

• ftp://files.unigine.com
• user: upload
• password: uSh3aihu0ja5

Thank you!

[taylormorris]

OK, I've managed to create a sample project with a terrain in a similar directory structure that can reliably reproduce the error. Should be uploaded now. Thanks!

[silent]

Hi Taylor,

 

You can patch editor_terrain.h (after extracting editor.ung contents) on line 1315-1316 or just replace with attached file:

BrushToolMask() {
			coarse_mask_name = savePath(terrain.getMaskTextureName());
			coarse_index_name = savePath(terrain.getIndexTextureName());

to

BrushToolMask() {
			coarse_mask_name = terrain.getMaskTextureName();
			coarse_index_name = terrain.getIndexTextureName();

We are still investigating other ways to fix this issue.

 

Sorry for the inconvenience caused.

 

editor_terrain.h

[taylormorris]

That is working for us, thank you! Looking forward to this in a future patch so we don't have to worry about the modified ung

[taylormorris]

Hello,

Unfortunately this problem has come up again but is now extended to all painting in the editor, even heights. I have tried removing savePath command from 2 other locations in editor_terrain.h but to little effect. Doing this does remove one error that uses the full path (including drive letter) to the terrain file, but we still have "can't create" errors where the path relative to the extern_path/data_path displayed is correct.

 

It also seems that the fix for masks brush no longer works and we can't edit our terrain at all with brush tools. 

 

Any ideas?

 

Taylor

[silent]

Hi Taylor,

 

Could you please modify your launch_editor.bat? Just replace -extern_path to -data_path, so it will look something like that:

<...> -video_resizable 1 -video_fullscreen 0 -sound_app auto -data_path "../" -data_path "../../core/data/" <...>

I've just upgraded your project and modified launch_editor.bat and everything is working as expected in my case.

 

-extern_path parameter was removed in 2.2 and now you can specify multiple data_paths.

 

Thanks!

[taylormorris]

Hi Silent,  

 

I should've mentioned in the previous post, we are now using data_path in our batch files since upgrading to 2.2 recently. We have it just as you do in your example -data_path "../" -data_path "../../core/data/" but still receive errors when using any brush.

[silent]

Hi Taylor,

 

Unfortunately, I can't reproduce this issue with your previous test scene. Is it possible that something changes in directories structure? Please, make sure that you don't have unpacked core and editor directories inside your project data dir (that can left from previous version if you upgraded your project with unpacked core and editor directories).

 

Thanks!

[taylormorris]

I may have found some workaround that is letting me edit terrain in most worlds, by changing the order of the data_path arguments to put external path first and the normal path last. Is it possible that the order matters when you have multiple data_path arguments? I tried a number of different things this afternoon so that may well not be it...

[ded]

Hi,

 

It's not the order but which one is goes first that matters.

When you create a new file using non-absolute path, it will be created relative to the first provided data_path.

Other than that there should be no difference.

Apparently there is a difference, which we consider as a bug, but unfortunately didn't manage to reproduce yet with your previous test scene :(.

[taylormorris]

Yes, I'm having a hard time reproducing with the test scene as well... But we have a workaround now too, removing the "project_name" argument from the batch file (which was not in the test scene) and then clearing out our cache and cfg files has fixed the problem for everyone here. It's strange but it did the job.

 

Wish I could help you guys more! Thanks for the info about the importance of the first data_path argument, that helps immensely.