[Linux] Virtual Memory and Shortcut errors on launch

[omento]

Hello,

Every time I open the application I get the following errors:

Code: [Select]

[Main] The current paging file maximum size is too low: 16063 MB (minimum: 16384 MB).
   Substance Painter can exceed virtual memory limits when doing a high resolution computation.
   See https://support.allegorithmic.com/documentation/display/SPDOC/Crash+with+low+virtual+memory
[Shortcut settings] Conflicts have been detected in your shortcut settings.Please consult your settings to solve the issue.

There was a third error, where a QML file was looking for 'exit.svg' yet the image was actually named 'Exit.svg'. Renaming solved that one.

For the main errors, though, I don't know what could be causing these as I've reset the shortcuts many times and not once has this error gone away. I looked through the shortcuts themselves and there don't appear to be any duplicates. For the memory issue, I don't know where Substance is pulling the reduced swap size from.

Code: [Select]

$ free
              total        used        free      shared  buff/cache   available
Mem:       32702052     3977588    25610732      163200     3113732    28066076
Swap:      16449532           0    16449532

CentOS 7.4
Substance Painter 2017.4.1 Build 1981

Cheers,
Mike

[Froyok]

Hello,

could you attach your config file as well ?

[omento]

Hi Fabrice,

Sorry for the late response, been a bit busy and haven't had time to touch SP. I completely removed the previous version I had installed and updated to 2017.4.2 Build 2052. I've attached the log file here.

Some things to note: the shortcuts error is no longer there (for now). The QML error is, but the fix is either editing the file (which could be done on your end for all users) or just us renaming the image. It's all about casing

Lastly, this is a bit off topic for this thread but baking still is single threaded over here on Linux. I necro'd a thread a while back about it but it didn't garner any response, despite that thread saying multi-threading had been implemented. Any info on this would be greatly appreciated!

Cheers,
Mike

[Jeremie Noguer]

The baking should be multi-threaded. What is not multi-threaded (and cannot be at this time) is the initial loading and preparation of the high poly mesh, and that can take most of the baking time for the first bake. Subsequent bakes should be much faster thouhg.

[omento]

Hi Jeremie,

Again, apologies for the late response. I'm finally starting to get into Painter more full time, so I should be more responsive than sidetracked with other tasks.

I ran some more tests with some of my assets. On my Windows laptop, Painter will multi-thread baking no problem (as shown in Task Manager). All threads kick up immediately to 100% usage during the bake. On CentOS, however, only one thread is ever active during a bake. On a 12 thread system this is pretty disappointing as I spend quite some time waiting for bakes to complete.

I used the same meshes on both machines, one of which is 17K polygons. Both using 2017.4.2-2052.

I would like to know if the paging error (which is still present) should be a concern.

Cheers,
Mike