PDA

View Full Version : ScreamerNet on linux



Stingslang
04-12-2007, 08:15 PM
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?

Phil
04-16-2007, 04:40 AM
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.

inquisitive
04-16-2007, 05:57 AM
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'

MooseDog
04-16-2007, 10:48 PM
I keep meaning to write a tutorial on how to set this all up. Perhaps in the next week or so, life allowing.

yes please, allowing of course:thumbsup:

Phil
06-22-2007, 03:34 AM
I really should get around to this, shouldn't I :D

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

Stingslang
06-27-2007, 01:46 PM
i really would like to see that tutorial because I am trying to build a linux renderfarm for lightwave

kmacphail
07-04-2007, 05:17 PM
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".
Loading "scenes/sphere.lws".
Clearing scene
Loading settings
Pre-processing scene
Loading "Z:\lwsn\content\sphere\objects\sphere.lwo"
Loading plug-in
Validating scene
Preparing "Z:/lwsn/content/sphere/objects/sphere.lwo"
fixme:heap:RtlCompactHeap stub
Scene loaded.
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

Phil
07-06-2007, 12:23 PM
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

So what about the options?

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 :

username=Bob
[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

Phil
07-06-2007, 12:29 PM
Hmmm. The advanced editor seems to have mangled some of the paths. Oh, well. You should get the idea :)

kmacphail
07-07-2007, 12:42 AM
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

Phil
07-09-2007, 01:33 PM
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.

stib
09-25-2007, 06:17 AM
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
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)


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

stib
09-25-2007, 06:32 AM
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.