1. ## ScreamerNet on linux

I own a very small company. We use linux to render everything because it is free, and subsequentially we won't use any apps that won't work on a linux render farm.

I heard that Screamernet nodes will run on linux. Is this ture? If so what distro do they run on?

2. There used to be a port of LWSN to linux, but this hasn't been the case for a while now. However, all is not lost. The Win32 version of LWSN will run on linux under Wine; most distributions provide a version of this.

Wine translates operations from Windows programs to work with the linux system. This is different to emulation, so has near-zero impact on the execution time. LWSN thinks it is running on Windows, so it doesn't complicate your LWSN setup from that side. What is tricky is that Wine requires X to be installed and running on each node. You don't need to run a big and heavy graphical environment, but you do need an XTerm session in which to run Wine.

For an easy-to-configure variant of Wine, you could look at CrossOver Office. It puts a GUI on Wine and makes setting up drives, etc. much simpler. http://www.codeweavers.com

I keep meaning to write a tutorial on how to set this all up. Perhaps in the next week or so, life allowing.

3. I would be interested on that tutorial.

I have three linux boxes that I would like to use for rendering, they are older cpu's but hey the more the merrier, and I dont really want to install windows (if I can avoid it) on these machines just to render lw frames.

One box is running redhat 6.2, and the others i think even older os'

4. Originally Posted by Phil
I keep meaning to write a tutorial on how to set this all up. Perhaps in the next week or so, life allowing.

5. I really should get around to this, shouldn't I

Maybe this weekend...let's all pray it rains heavily so I have to stay in and get bored.

6. i really would like to see that tutorial because I am trying to build a linux renderfarm for lightwave

7. Hey folks,

I've been experimenting with lwsn and wine the last 2 days and I just got it working. I'm not using screamernet, just the standalone lwsn -3 option.

Both my Windows and Linux workstations can read and write to a common lwsn folder on my file server. Both Windows and WINE map this folder as Z:\lwsn (I checked WINE's mapping with winefile). The configs are in Z:\lwsn\configs and the project folders are in Z:\lwsn\content. I copied the Lightwave Programs and Plugins folders to /home/user/.wine/drive_c/Program Files/Newtek/Lightwave_3D_9.2/, then ran Layout (in discovery mode, plenty of gl issues) to check that I could set the content directory, load scenes, and render frames.

Here's the actual render command I used:
/home/user/.wine/drive_c/Program Files/Newtek/Lightwave_3D_9.2/Programs> wine lwsn -3 -cZ:/lwsn/config -dZ:/lwsn/content/sphere scenes/sphere.lws 1 1 1

LightWave x86 ScreamerNet Module (Build 1165)
CPU number: 82

sendack: Initializing
x86
Current directory is now "Z:/lwsn/content/sphere".
Clearing scene
Pre-processing scene
Validating scene
Preparing "Z:/lwsn/content/sphere/objects/sphere.lwo"
fixme:heap:RtlCompactHeap stub
Allocating frame buffers.
Allocating segment buffers.
Updating geometry.
Moving sphere.
Transforming coordinates.
Removing hidden polygons.
Sorting polygons.
Rendering frame 1, segment 1/1, pass 1/1.
Rendering opaque polygons.
Integrating pixels.
Writing RGB image to Z:\lwsn\content\sphere\output\sphere0001.tga.
fixme:heap:RtlCompactHeap stub
Frame completed.
Last Frame Rendered: 1.
Rendering Time: 8.5 seconds.
Freeing segment buffers.
Freeing frame buffers.

I do see a lot of WINE messages like "fixme:heap:RtlCompactHeap stub". They're not errors, just warnings. If you want to suppress these stderr messages, end the lwsn command with "2> /dev/null".

I hope this helps. Holler is you see any glaring mistakes or omissions.

-Kevin

8. LWSN on Linux (version 1)
(Tested on Ubuntu something.something)

YMMV, etc. blah

The fileserver

First up, you'll need a fileserver to connect your nodes to. This can be running Windows, Linux, OS X - whatever supplies a fileshare via Windows SMB/CIFS. You'll need to configure the fileserver - this is beyond the scope of this tutorial.

The node

Sounds exciting. You'll want Wine installed. Or CrossOver Office. This probably works with Cedega, but since I don't like subscription software, I haven't tried that one.

You'll also want smbfs installed, along with samba and samba-common.

Important Note #1

What you cannot do is simply use the GUI to connect to the fileserver. At least under GNOME, it does not integrate the mountpoint in any kind of way with the underlying system. You can check this by going to :

Places -> Connect To Server

Choose 'Windows Share' and enter in the relevant details (folder is optional). Once the fileshare is on the desktop, double click it and you will be asked for your password. The file browser will then show the contents of your share.

If this doesn't work, you'll need to explore why you cannot connect to the fileserver. Check the filewall on both sides and ensure you can access the fileserver. Check also that you have the share set up properly and have the right user details to access it.

If you now go to the terminal, via Accessories, and type mount....you'll see no mention of your fileshare. Bit of a bugger. Perhaps KDE is better, but we'll do it the hard way.

Important Note #2

You'll need to have superuser privileges to mount filesystems. 'sudo' is the tool to use here. Under Ubuntu, you'll be asked for a password. This is your user password. OpenSUSE, etc. will expect the root user password.

Keeping the terminal open, let's mount our fileserver manually. We'll unmount the GNOME one for now (right click the desktop icon and choose to unmount the volume).

All this talk of mount and unmount might have given you a clue already, or perhaps you already have some knowledge of command line voodoo. All the voodoo is available in the system documentation, accessible via :

info mount

from your terminal. Be aware that this is not particularly enjoyable to read, but contains all the magic values and syntax you need to make it all work. In particular, you need to pay attention to the switches (-t -o), the syntax (what goes where in the command line) and then the 'filesystem specific mount options'.

To save you some work, the command line structure looks like this :

sudo mount -t (type of filesystem) -o (option1=something,option2=anything) (thing to mount) (place to mount it)

Type of filesystem

If you remember the output of the mount command from earlier, or simply type mount and hit enter now, you will see entries like 'ext3' or 'tmpfs', or 'sysfs' in the output. These are filesystems. If you have a Windows NTFS partition, it will appear in the output with 'ntfs'.

For a Windows fileshare, the type is 'smbfs'. There is a newer implementation called 'cifs', but this has problems with the credentials file we will use later for security. smbfs is therefore the better choice.

So we have the value to put behind -t now :

sudo mount -t smbfs

The options are filesystem specific. Tracking them down can be awkward, especially if the documentation is unhelpful. For smbfs, the main ones are :

username = this is the user name on the fileserver (e.g. Bob)
password = this is the password on the fileserver (e.g. [email protected])

These two are important. They are also the riskiest to leave lying around world-readable in scripts and /etc/fstab. So we are going to put them into a credentials file (e.g. /home/lwsn/lwsncred) that is only readable by the user 'lwsn'. You can use nano or pico to create the file :

nano /home/lwsn/lwsncred

You only want two lines in this file :

[email protected]

Save and quit the editor. By default, this will be readable to everyone, so fix that with :

chmod o-r /home/lwsn/lwsncred

To use this credentials file, we will use the 'credentials' option in our command line.

Now, let's check those other mount options :

workgroup = this is the workgroup for the fileserver (e.g. farm1)
uid = this is the user name to assign access rights to on the local machine (e.g. lwsn)
gid = this is the user group to assign access rights to on the local machine (e.g. lwsngroup)

If you have any special characters (e.g. symbols) in any of these fields, they *have* to be escaped using a preceding '\', otherwise things will likely break. This doesn't appear to be necessary in the credentials file, probably because it is handled differently.

Using our example values, we have :

sudo mount -t smbfs -o credentials=/home/lwsn/lwsncred,workgroup=farm1,uid=lwsn,gid=lwsngroup

What's left? We need to still define what we are mounting and where we want to have it available in the local filesystem. Only then can we get to Wine.

For a fileserver and fileshare accessible under Windows as :

\\192.168.2.2\LWSNContent

to be available under /mnt/LWSNContent, we simply do the following with our existing command line :

sudo mount -t smbfs -o credentials=/home/lwsn/lwsncred,workgroup=farm1,uid=lwsn,gid=lwsngroup //192.168.2.2/LWSNContent /mnt/LWSNContent

The destination /mnt/LWSNContent needs to exist.

Hurray! Now we can get to Wine setup.

This is where it gets easy.

If you have more than one version of Wine installed, you need to find out which one runs by default : use 'which wine' at the terminal. For regular Wine, you will see something like :

/usr/bin/wine

You need to be logged in as your LWSN user for this next step. Run 'wine' and if necessary, it will create a folder called .wine in your home directory. For our example of the user 'lwsn' on the node, this will be /home/lwsn/.wine

In the .wine folder, you will see a dosdevices folder. This is where you hook Wine into your mounted LWSNContent folder. In this example, we will assume that you have set everything up to reference content located under Windows drive X:. 'cd' into the dosdevices folder and type :

ln -s /mnt/LWSNContent x:

If you look in dosdevices now, you'll see an entry called x: has been created. 'ls -l' will show you that it is referencing /mnt/LWSNContent.

You can now write a script file, based on the startlwsn_node.bat file that ships with LW :

e.g.

#! /bin/bash
wine LWSN.exe -2 -dx:\\Documents\\LightWave_3d\\common\\Projects -cx:\\Documents\\LightWave_3d\\LW_Win32\\9.2\\lw9.c fg x:\\Documents\\LightWave_3d\\common\\wsncontrol\\j ob1 x:\\Documents\\LightWave_3d\\common\\lwsncontrol\\ ack1

Basically, you just prefix the entire LWSN command with 'wine' and replace all single \ with \\. Paths, etc. work just like under windows (with this minor \\ change).

To make the script launchable, you'll need to :

chmod a+x startlwsn_node.sh

Run it as ./startlwsn_node.sh

9. Hmmm. The advanced editor seems to have mangled some of the paths. Oh, well. You should get the idea

10. Nice stuff Phil. You do several things differently than I would on SUSE, but it's quite interesting. I'm reading through a second time to pick up some new ideas.

One thing that I haven't figured out quite yet is why I need to specify an absolute path for the rendered frames rather than being able to use a relative content folder path. Which are in your scene files?

Cheers.

-Kevin

11. Apologies, there is an error. Replace all '\\' with '/' in the command line to launch LWSN. This addresses some path referencing oddness. In my documentation, I forgot to update this and didn't check closely enough before posting it.

12. I have my render path set up as a mapped drive in windows (so everything renders to R: ). In my ~/.wine/dosdevices dorectory I've put a simlink to the render drive called r:

For newbs: to do this I used
Code:
ln -s /media/<render drive> ~/.wine/dosdevices/r:
Testing a scene which I rendered on my windows render farm I found that it saved just fine to "R:\". My content directory and my render directory are all represented by appropriate simlinks (oh I also have a mapped drive for my configurations (using the -c switch), this is helpful in maintaining my render farm in windoze too)

Originally Posted by kmacphail
Nice stuff Phil. You do several things differently than I would on SUSE, but it's quite interesting. I'm reading through a second time to pick up some new ideas.

One thing that I haven't figured out quite yet is why I need to specify an absolute path for the rendered frames rather than being able to use a relative content folder path. Which are in your scene files?

Cheers.

-Kevin

13. oh the command I used was
wine "Z:\Programs\lwsn.exe" -3 -c"Z:\config9" -d"Y:\Content" "Y:\Content\scenes\<path\to\my\scene>.lws" <first frame> <last frame> <step>
with the obvious replacements. Note that the the z: drive is a mapped drive pointing to the lightwave folder, and "config9" is my configurations folder. I just hoovered up all the lightwave settings in "my documents" and plonked them in there, and then changed the shortcuts to lightwave (we're talking about windows here) to include the -c switch. So my windows shortcuts look like
z:\programs\lightwav.exe -c"z:\config9"
There is lots of documentation available about the -c switch, but I thought I'd post it again here.

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•