Using Zbrush on Linux

[Przemas]

32 cores.

I’ve been asking about gpu mostly to estimate how likely it is to be gpu/driver related. Doesn’t matter how much of the gpu Zbrush uses it still needs to go through it to display the image . And I had some cases with WINE where that proved to be a problem - and allowed to find a workaround (for example in MoI if you’re on Nvidia you need to set __GL_MaxFramesAllowed=1 variable to get proper display states sync).

So sadly it seems it is unlikely to be a driver/gpu problem as you’re on Nvidia as well. So the first thing I’ll check will be to see how it works under KDE/Xfce - next week I’ll have access to my old workstation with KDE so it will be good opportunity to test it out (don’t want to mess my workstation with all the display env available ).
Luckily as it is sculpting app not an action game it is nor super annoying.

[thinkit]

To do analysis by comparing is a great way to figure things out. Having your old workstation to try things out on is a smart method to use.

As for me I noticed an improvement after compiling Wine for my specific distribution and kernel. I’m not saying you have to do it, but if nothing else works then that is one thing to try.

[Przemas]

I’ve been looking at getting GoZ working. Not easy, but seems doable at first. After looking at the python scripts it looks it calls additional executable during the transfer between the apps, so this has to be run with WINE too, and all the paths have to be changed as well (mostly on a Linux app you’re using - Houdini, Modo etc). I wish there were docs somewhere explaining all the components of GoZ and how they work “internally” so it would be easier to tinker with - as at this point it seems to be a bit of a pain to do. I’ll try to figure it out once I get some more free time.

[thinkit]

What I know is that the Linux File Manager can send files to Wine Zbrush. If Zbrush can send files back to another app I do not know. I did try to get ZBrush to send to Houdini. What eventually happend for me was that a new instance of Houdini kept being launched.

For Houdini I did not find any recent version of GoZ so that made me post pone this.

At worst it should be possible to manually “tell” each app to “read” the exported GoZ data.

However, for me this is not high priority at this moment since I expect to mostly do organic assets from ZBrush and then export the data, but probably not send back very much.

However, maybe other people would like that.

[Przemas]

that makes total sense - at least judging by what I’ve seen in python scripts for Modo’s GoZ.
If I’m right, Zbrush invokes the script that launches target app instance (in your case Houdini) - and that goes normally as it is regular Python that will work no matter it is Window / Linux / OSX.
Then the script tries to use external utility (external executable bundled with Zbrush) to prepare model files for the target application. And this obviously fails as it tries to launch Window exectuable on Linux .
So my wild guess is that if we modify the python script so it will launch this extra executable via wine it may actually work.
Sadly my Python-fu is not very strong so it’s a bit problematic. I’ll try to give it a go as for me the workflow would be way smoother. Had similar setup in 3DC that I’ve used to repair 3d printable files and it saved me so much file juggling (or rather repeatable open / close cycles) .

[thinkit]

What I did was to create a symbolic link called houdini.exe a Linux binary. Then just point ZBrush to that file. This tricked ZBrush to run it. So I guess you could run anything you want that way.

Houdini 18 has SideFX Labs. For objects there is a goz_export node. It has a button in the parameter editor called “Send To Zbrush”. It is configured for Windows by default. Next step is to modify that PythonModule. Follow the error messages…

Traceback (most recent call last):
File “”, line 1, in
File “opdef:/labs::Sop/goz_export?PythonModule”, line 71, in export
File “opdef:/labs::Sop/goz_export?PythonModule”, line 44, in write_object_path
IOError: (2, ‘No such file or directory’, ‘C:\Users\Public\Pixologic\GoZBrush/GoZ_ObjectList.txt’)

[thinkit]

@Przemas

Long story short: Bought a script/hda for $25 made for Houdini 17 that did not work so well. Did some tricks and at this moment the model goes from ZBrush to Houdini.

A model can also be sent to ZBrush.

[Przemas]

Awesome! And that’s similar to direction I’m looking at. I’m searching for a Zbrush script(s) that would import/export a file from/to a specific location. This way I’d simply be able to add a simple python script in Modo that would do the same - and thus I’d recreate GoZ functionality to some extent.
Heck, it could be even cooler if I create a reasonable RAMdisk and point the scripts to read/write there.
Anyways worth investigating - yesterday I’ve been working on some simple hard surface shapes that were simply quicker to do in Modo, but the file juggling was a pita.

[thinkit]

@Przemas

Although I can not fully explain everything required to make this work here are some suggestions. Since I do not know exactly what you need or what is required to get things working I will just shoot a lot in one direction. Take whatever is helpful.

Possible requirements

• winecfg to add a path directly to your Linux app (Modo/whatever). So for example E:\ would point to the folder that has modo executable. (otherwise ZBrush will probably not find your app).
• A symbolic link for your Linux app in the same folder. So I have houdini.exe next to the houdini file. This is just to trick ZBrush GoZ to think everything is okay.
• Since I did not find any working GoZ for Houdini in ZBrush I copied the one for Photoshop and simply renamed everything “Photoshop” to Houdini. That is also inside config files.
  /home/username/.wine/drive_c/users/Public/Pixologic/GoZApps/Houdini/
• When trying to run GoZ from inside ZBrush it searched for a long time and actually found Houdini.exe in E:. It said “A version of Houdini was found” LOL!)
• However, then running “Installing GoZ for Houdini” there will eventually be some error messages, but I simply ignored them. “An error occurred during installation. One possible cause could be unsufficient permission…” (bla bla).
• However, when pressing GoZ in ZBrush it will not launch Houdini.
• What is cool is that now in “/home/username/.wine/drive_c/users/Public/Pixologic/GoZProjects/Default/” there will be output some files. Example: testgeometry_rubbertoy_object1.ztn with content “C:\Users\Public\Pixologic\GoZProjects\Default\testgeometry_rubbertoy_object1”, “testgeometry_rubbertoy_object1.ZTL” that is current subtool. Finally “testgeometry_rubbertoy_object1.GoZ” that is some GoZ binary file. Also some files in “/home/username/.wine/drive_c/users/Public/Pixologic/GoZBrush/GoZ_Config.txt” are exported such as objectlist, path to Zbrush, and what app to run.
• You should note that this will not actually get the files into the other app. However my guess is that now the other app can maybe (I am guessing here) access that “GoZ” button via scripting from externally. This I guess because now I am able to import files and updated files from Houdini without pressing GoZ at all! So all file transfer back and forward can be done entirely from Houdini.
• For Linux there is a standard package installed called wmctrl. Exactly how it is used I do not know but it can be used to talk with X. For example wmctrl -l will show a list of currently running apps and if ZBrush is running under Wine it will be listed there. However, how this is used is beyond my experience. If it is actually needed I do not know.
• If you do not get scripts doing all the work from ZBrush I think you could do all scripting from Modo side. I guess Modo support Python and I do not like how scripts are looking from ZBrush side because I prefer Python not different scripting for each app.
• From here you could download GoZ for Modo from Foundry https://www.foundry.com/products/modo/addons/goz-for-modo and first install it on Windows (trial). Then manually try to transfer whatever it does by examinating the scripts that you find.

Best of luck!

p.s. If you want tmpfs you can add that later. Also, this is funny because now there is not so much need to actually “save” file in ZBrush (except maybe using QuickSave) when you can just grab the subtool from inside Houdini. That way the tablet pressure is preserved.

Also, in the ZBrush folders there are a bunch of apps you can run from outside ZBrush. For example if you right click open with ZBrush executable this file “/home/username/.wine/drive_c/users/Public/Pixologic/GoZBrush/Scripts/GoZ_ExportFromZBrush.zsc” it will export the current subtool as mentioned above. If you run “GoZBrushFromAppScript.zsc” the same way a cube (in my case) will be opened in ZBrush. So if you get stuck my advice is that you look at the possibilities with those apps. Maybe they can take arguments also (like file names). Not sure.

[Przemas]

tested for tearing under KDE - while slightly less noticeable it is still there. I might be just more sensitive to his sort of things :D. Will play with different compositor settings and will see what happens.

Another issue I’ve found is decimation master. I’m stuck at pre-process current stage. Will test whether it happens only in project I’m currently working on, or whether it is something that happens regulary.

Still super stoked that I can sculpt on Linux. It’s so close to perfection.

[lithorus]

About losing pressure sensitity when using the file manager. If the pen doesn’t touch the tablet and you only use the mouse when opening and navigating the file manager, you don’t lose pressure sensitivity.

[thinkit]

Yes, decimation currently works for lower resolution meshes but not for 1M ones. Then the process will get stuck. There are some settings under preferences (dll) and maybe there is a workaround, but I do not know.

Thanks for advice to use a mouse for the Wine file manager. Since I do not have ability to use a mouse, only Cintiq, maybe it is possible to do some settings for the erazer (unused back of pen) or make a script that will temporarily turn the tablet into a “regular” mouse. My workstation is in another room with long cables to it and there is no table.

[Amir]

Hi guys,
really interesting read! I’m new to the linux world and I’m using Pop! os current version. I followed ThinkIt wine methods and everything worked good except the same issues that you all already ran into. Also thanx to Przemas for his Vimeo tutorial. It’s nice to see that there are also people like me who wish to use their daily appz on a different plattform than Win or Mac. Unfortunately I’m not a big help in solving the problems with zBrush in linux but I will follow you guys and see if we can get it to work fully and with no limitation (ofcourse it would be great if Pixologic would create a linux installer by themselves)

Cheers

[thinkit]

@Amir

Hi Amir.

More and more I’m using the native Linux file manager to control ZBrush also. One example is the default materials with icons. To do this I had to render out each material to an image.

[Amir]

@thinkit

Hi Thinkit,

wise words! I feel the same and probably a lot of other who have decided to move to Linux. I’ve tried some distros ( Pop! Os , Linux Mint and Manjaro) and I’ve decided to go with Pop! Os for now because like I said I’m new to linux world and I rather work visually.
I must say that I’m really impressed from what I saw untill and I think I will spend a lot of my time with it from now on.

Unfortunately as much as I love to do everything in linux from now on, as a 3D freelancer my jobs requires me to have fully functional and reliable appz. I was so happy when I saw that I can get zBrush running in Linux (thanx to your and Przemas efforts) but not being able to use all the required features specially the file manager without workaround, it keeps me hasitating from completely moving to the linux world. Unfortunatly zBrush is just one of the appz. There a lot more programms which I need to use (even if I don’t want to but the lack of alternative forces me to use them) and they don’t run natively or very unstable or buggy on linux systems.

Never the less I share the same ideas and I’m also amazed to see how much is possible already in linux, if you put a lot of time and efforts into. I hope one day I can also be free from all those companies

cheers
Amir

Ps. it’s amazing to see you Material-Library. Love it

[fenglelyng]

hello。I take your ways,and I can running zb on the opensuse leap 15.1 verywell.
but I used wacom ctl471 ，the Pressure sensing is does not work in the wine and zb.
is that you take other settings?thanku

[thinkit]

@fenglelyng

Yes other settings. Please try one of these methods (A or B) first before experimenting.

Two published methods to install and configure Wine ZBrush

A) With the overrides in the guide from “Apr 8”

B) Przemas video is another method to install and configure: “Zbrush on Linux with WINE and Lutris” (Apr 10)

Wacom pressure should work when you start Wine ZBrush. You can read about related problems in this thread.

Please note: We do not have official support for Wine ZBrush or ZBrush for Linux, so there will be issues.

[fenglelyng]

the Wacom pressure was working.bug it was some problem,the Wacom pressure is very big.and I guess it was a problem with wine driver.do you know crossover?IS a very nice software,I think I can report that problem to them.but mine english is not ok.

[thinkit]

Now it is maybe time to mention that ZBrush on Wine is working well for me at the moment by using ZScripts and other scripting. I can not spend time with the remaining problems because there are other ones with higher priority.

Crossover by Codeweavers is somehow related to Wine. I am not sure if the user base is large enough for them to support ZBrush with Wine. So for now I will just use Wine and workarounds like ZScripts.

This image is just a quick test with the bug from ZBrush

[fenglelyng]

oh,a nice little bee. actually I don,t know what that in English.