Executive summary:
Yes, it is possible to run lwsn.exe (v9) under the influence of Wine. Even multithreading works! Running lwsn.exe in "-3" (batch mode) is pretty trivial, which means it would be possible to control it with most Linux render queues.
Forward:
Recently I've been doing a bit of R&D on the possibility of running Lightwaves network renderer Screamernet ( lwsn.exe ) under Linux. While Googling around to try to find some pointers I found several people claiming to have had success but no real "How-Tos" explaining how to actually do it. These are my notes to myself. Maybe you'll find them useful as well.
How-To:
The basics...
1. First of all, you need to install Wine and get it configured. This isn't a Wine How-To, so you are mostly on your own in that department. Fear not! Wine is easy to set up. I have one tip for you: winecfg
winecfg is a GUI that makes setting up Wine trivial. You can use winecfg to easily create "fake" drive letters like C:, etc. It's also possible to create fake drive letters for network mounted Linux volumes, similar to the way one can map network shares in Windows to a drive letter. For my examples, I'll be using the C: drive, which Winetools sets up under ~USERNAME/.wine/drive_c/
Another tool you might consider is Winetools. It has a few extra functions that might come in handy once you have Wine setup. Like doing "virtual reboots" of Windows.
2. Once you have Wine installed and some fake drive letters created, it's time to install Lightwave. Lightwave keeps all it's configuration info in plain text files stored under the users directory in the "C:\Documents and Settings\Default User". That's just the default path. LW has a command line switch that allows you to point it to any config dir. As a result, it's possible to copy the LW install dir and config dir anywhere as long as the config files are updated to reflect the new paths to the plug-ins and LW is pointed to the correct config dir.
You only need these parts of your LW install for for LWSN to work:
c:\LightWave\Plugins\
c:\LightWave\Plugins\Programs\
Create a temporary staging DIR on your hard drive and copy all the required parts of LW to it being careful to not mess up the paths.
c:\tmp\LightwaveStagingArea\
c:\tmp\LightwaveStagingArea\LightWave\Plugins\
c:\tmp\LightwaveStagingArea\LightWave\Plugins\Programs\
It also makes sense to create a DIR for the configs under your intended Lightwave install dir and copy the configs there:
c:\tmp\LightwaveStagingArea\LightWave\config\
At this point, you might want to clean things up the and remove other things lwsn doesn't really need from your staging area. The Presets under the Programs DIR are a good example. Screamernet doesn't need those. You might have some other junk you recognise lwsn wont need. This step isn't required, but it will save some space and reduce clutter.
Now Zip up everything in you your staging area being careful not to mess up the paths.
Get that archive over to your Linux box in whatever way makes most sense to you and expand it under your "virtual" C: drive.
TIP: It's important to understand that the paths to all the plug-ins are hard coded in the LWconfig files. If you copy your LW to a "virtual path" under Wine that disagrees with the config, LW wont work. You'll either need to go though the config files and "find and replace" the paths to fix them, or just make sure you copy LW to the same path under Wine as what you are using in Windows. For testing, the easiest thing to do is just make a fake drive and install path under Wine that mirrors your Windows setup. (This will be C:\Program Files\LightWave\ and ~$USERNAME/.wine/drive_c/Program Files/Lightwave/ for most people)
3. Using the above simple case of basically copying LW from C: to Wines "virtual" C: drive, you should now have a working LW on your Linux machine. Here is an example of how you invoke lwsn.exe in "-3" (batch) mode.
wine "C:\LightWave9\Programs\lwsn.exe" -3 -q -c"C:\LightWave9\config" -d"C:\LightWave9\test_content" "C:\LightWave9\test_content\scenes\test_scene.lws" 1 10 1
Wow. That looks pretty overwhelming. Let's examine each part. You'll see it's not so complex. First of all, the quotes help us escape the back slashes. If you are familiar to Linux, you know \ IS the escape character. You can escape back slashes by using a SECOND back slash like so \\. I personally prefer to just use quotes :
wine "C:\LightWave9\Programs\lwsn.exe" -3 -q <--- This is the command -3 puts lwsn in batch mode -q reduces it's verbosity -c"C:\LightWave9\config" -c <--- points lwsn.exe to the config dir -d"C:\LightWave9\test_content" -d <--- points lwsn.exe to the content "C:\LightWave9\test_content\scenes\test_scene.lws" 1 10 1 <--- the last argument is the scene FIRST LAST and STEP Details... During my tests, I noticed that LW and/or Wine dumped some junk error messages out to the console. They did not seem fatal. Everything rendered just fine. But the errors were repetative and annoying. The error messages can be safely redirected to /dev/null , but keep in mind that by doing this you might potentially loose any genuine error messages in the bargain. In my experience, when lwsn DOES fail it does so silently anyway. Redirecting the error output will probably never be a problem. Redirecting stderr (Standard Error) to the "no where" dustbin "null" is done like this in Unix/Linux: [command] 2> /dev/null
So, just add that to the end of your command string to suppress those errors.
Another issue is that Wine wants Xwindows to be running (even though it never actually opens any windows) when lwsn is invoked. This can be a problem if you try to run lwsn on a headless machine (not running X) or on virtual console where the DISPLAY variable isn't defined. It's easy to set DISPLAY for a single invocation of lwsn, or you can set it for the entire console session with setenv. The advantage of making Wine use a remote Xserver is the ram saved by not running any Xserver at all on the rendering machine. But if that's not an option you can always just right X with a really basic Windows Manager or even no WM to keep things light weight.
To redirect X to 0.0 on a remote machine at 192.168.1.10
setenv DISPLAY 192.168.1.10:0.0
or, if you have a name server or entry in your hosts file, you can do the remote machine by name:
setenv DISPLAY giggles:0.0
It's handy to just define the DISPLAY variable right on the same line that you invoke Wine and lwsn with.
redirect for a single invocation like this:
# DISPLAY=fishbait:0.0 [lwsn_command_string_here]
# DISPLAY=192.168.1.13:0.0 [lwsn_command_string_here]
If wine complains that it can't find a local Xserver you KNOW is running, you might need to define DISPLAY for it just to get it to run locally. I had this problem when I attempted to run lwsn on a virtual console. Just set the DISPLAY variable to the local display like so:
# DISPLAY=0.0 [lwsn_command_string_here]
that's all for now!
Subscribe to:
Post Comments (Atom)
3 comments:
This is a fantastic post. Very helpful!! I have setup up a linux renderfarm before but am interested in going headless. I am doing a new farm at the mo, and was stuck on the DISPLAY issue when I came accross your post here, and was wondering if you could shed some light. I have my debian server booting to console (actually it waits for login). Is there a way I can setup the DISPLAY variable so when I virtual console in that it displays the lwsn process? or even better, the console it was opened in? I am not sure how the whole thing works, i'm pretty new to the headless and xserver thing.
Thanks!
I'm pretty sure the text output goes to the console. For some reason though, Wine wants Xwindows.
So if you just set the DISPLAY var as I mention in the article it should work ok.
Post a Comment