The gardeners came this morning and when I went to check the coop on my way out to work the chunks of skin, feathers and the head were gone form the lawn. I'm guessing they mowed over the feathers and they got sucked up with the grass. They either mowed over the head and it was sucked up also or they cleared it. Anyway, there is much less evidence of what happened as of this morning. I'm glad I did the rounds last night because it would have been harder to figure out what happened otherwise. All that was left today was few feathers.
My concern now is that whatever hit Duchess now knows a good place to get chicken easily. It will be back at some point for seconds. Even if I DO lock the chickens up at night I'm going to have to make sure the coop is predator proof because whatever it was that got them is probably going to be more persistent next time. (Especially if it really likes chicken)
The sad life of a prey animal... At most it's only been a few days since she died and already there is almost no evidence that she ever even existed. Well, I mean, I have the chicks at least, so she lives on though them. But her body is pretty much totally gone.
I'll be much more careful with her offspring.
Tuesday, July 17, 2007
Monday, July 16, 2007
Duchess is dead
I was away for four days at a family reunion. A friend of mine was taking care of my chickens but since she could only come by once a day she couldn't open and close my chicken coop (The "Chicken Breasts 2000") I decided it would be OK to just leave the coop open the whole time I was gone. I usually close it up at night to keep the chickens safe from nocturnal predators. Chickens are very vulnerable at night because they really don't put up much of a fight when they are sleepy. It wasn't the smartest move, but I felt it would be better than leaving them cooped up, especially considering how hot it is right now.
Enough back story... I got back home today to discover my loss. After settling in I headed back to the CB-2000 and check on the hens and lock up the coop. Duchess was nowhere to be found. But I noticed some feathers scattered about. I widened my circle to include the lawn in the back yard only to find more feathers, chunks of flesh attached to feathers, and a chicken head. The chicken head was pretty beat up, so it's not like I can give a positive "ID", but I'm pretty certain it is (was?) Duchess.
Right now I'm thinking it was either a skunk or a raccoon that did her in. But you never know, a dog might have gotten in there during the day and gotten her. That's never happened before so I'm really leaning toward skunk or raccoon... something nocturnal. Considering that she seems to have been consumed almost entirely, I really doubt it was a domestic animal. ( Who knows, it might have even been a hard up chupacabra)
I'm pretty bummed about this. I would have been a little upset if one of the new hens was the one that got it but for Duchess to be the one to buy the farm is a real upset. IMHO she really deserved to live after giving me so many chicks and putting up with the two roosters for so long. The thing that really has me scratching my head is why that skunk or raccoon didn't ever eat any of the eggs in the past. Duchess was laying eggs in the bushes at one point for nearly a month before I noticed and as far as I could tell no pests ever bothered to eat any. Not even rats.
It was stupid of me to leave the hens unlocked at night. I probably should have moved them into the garage while I was away. Now I know there is SOMETHING that will attack and kill them at night so I will be more careful in the future. I just wish it didn't have to be duchess that was the first to go.
R.I.P. Duchess You will be missed.
Enough back story... I got back home today to discover my loss. After settling in I headed back to the CB-2000 and check on the hens and lock up the coop. Duchess was nowhere to be found. But I noticed some feathers scattered about. I widened my circle to include the lawn in the back yard only to find more feathers, chunks of flesh attached to feathers, and a chicken head. The chicken head was pretty beat up, so it's not like I can give a positive "ID", but I'm pretty certain it is (was?) Duchess.
Right now I'm thinking it was either a skunk or a raccoon that did her in. But you never know, a dog might have gotten in there during the day and gotten her. That's never happened before so I'm really leaning toward skunk or raccoon... something nocturnal. Considering that she seems to have been consumed almost entirely, I really doubt it was a domestic animal. ( Who knows, it might have even been a hard up chupacabra)
I'm pretty bummed about this. I would have been a little upset if one of the new hens was the one that got it but for Duchess to be the one to buy the farm is a real upset. IMHO she really deserved to live after giving me so many chicks and putting up with the two roosters for so long. The thing that really has me scratching my head is why that skunk or raccoon didn't ever eat any of the eggs in the past. Duchess was laying eggs in the bushes at one point for nearly a month before I noticed and as far as I could tell no pests ever bothered to eat any. Not even rats.
It was stupid of me to leave the hens unlocked at night. I probably should have moved them into the garage while I was away. Now I know there is SOMETHING that will attack and kill them at night so I will be more careful in the future. I just wish it didn't have to be duchess that was the first to go.
R.I.P. Duchess You will be missed.
Thursday, May 17, 2007
Film Making
Lately I've been involved in a group at work that makes movies. We make little movies as practice for making big movies.
My little brother is also an aspiring film maker. He asekd me for some advice about doing a full feature. I thought the info might be interesting to others so I'm re-posting a more generic version of it here:
Even though I haven't ever done a REAL (i.e. money making ) feature project my self (Uh, outside of my job, but I'm just rank and file there) I have a few pieces of advice from my exposure so far.
There are two important factors: Story and Performance. Everything else serves those things, no matter how artistic it is ( i.e., lighting, cinematorgraphy, etc.) The story is what people walk away with but it's the performance that keeps them engaged moment to moment while they are watching the film. I'm sure you can imagine how a bad performance could kill the whole project.
Your are on the right track by wanting non-suck talent. The actors will bring a HUGE amount to the project. Be very picky about your casting and make sure you audition everyone. If they don't have a good resume and can't do the audition than forget it. You'll never get a good film out of them. (There are plenty of trained actors to work with so why work with amateurs?) Make sure that you are a non-suck director as well! You might want to take some acting workshops yourself, so you can learn how to spot "false" performances and get the best out of your actors. There are several books out there on directing. I'm reading one now called "Directing Actors" which is quite good.
In that same vein, you don't want your script to suck either. I'm not sure who's doing the writing for you, but make sure the script is solid before you start shooting. The right script with the right take can definitely turn heads. Napoleon Dynamite may not have made big bucks at the theater, but it definitely put those guys on the map. Much of that script seemed like it was simply accommodating the resources they had. But it did it in such a fantastic way! Don't forget the local resource you have when coming up with your script.
As for getting crew, I suggest you try to put non-students in the key positions on your crew. Get as experienced a DP/Cinematographer as possible. Same for the sound guy. Everyone else on the crew can be more green. They are basically just moving stuff around after all. But they'll still be learning by watching the pros work, and you film will be much better for it!
From a technical stand point, sound quality is more important that picture quality. Give sound proper attention. Bad sound will drive the audience crazy while poor picture will only bother them a little. "Bad" picture can sometimes even be justified as a stylistic choice... for example, skip bleach, cross processing, or shooting Super 8 will definitely have a detrimental effect on the image "quality" but given the correct stylistic intent the loss of "quality" might actually be desirable! Bad sound is just, bad sound. Make sure you have a good sound recorder and mikes with someone who knows what they are doing running them.
You can't over-prepare. Scout out locations and have a solid game plan at the very least. I personally would board everything out. I'd probably even do a 3D animatic to figure out what shots you can actually get. (Depending on the lenses you have, It might be physically impossible to place the camera for certain shots in a small room) If you have all your shots planned out in advance, you also wont have to shoot too much "coverage", which will save a bunch of time and tape/film. (The side effect is that it might make editing a lot easier as well) If you want to do any dolly shots, I would definitely do an animatic because they can be a huge time suck. Maybe you don't need that technocrane shot? The animatic will tell you in advance for a lot cheaper! The animatic could be just you working. Once you have your cinematographer, you can bring him in on it also. If you get a cinematographer who says he doesn't like to plan like that I wouldn't trust him. He should know there is room for improvisation and improvement on the set and should feel comfortable with planning. But the idea here is the get a really solid basic plan down so you can be honest about your schedule and get the best stuff on the day. When you are actually shooting, you, as the director, should be totally absorbed in getting the best performance from the actors. You don't want to have to worry too much about shot planning etc.
When you are working cheap like this the main problem is getting the commitments you need from the various cast and crew members to "go the distance". That's another reason why planning is so important. You need to be able to tell everyone exactly what the schedule is and how long a commitment you need from them. The shorter the commitment, the better the odds of getting a seasoned cast/crew. If the script is solid enough you might be amazed at the talent you can attract... assuming the commitment isn't too long.
My little brother is also an aspiring film maker. He asekd me for some advice about doing a full feature. I thought the info might be interesting to others so I'm re-posting a more generic version of it here:
Even though I haven't ever done a REAL (i.e. money making ) feature project my self (Uh, outside of my job, but I'm just rank and file there) I have a few pieces of advice from my exposure so far.
There are two important factors: Story and Performance. Everything else serves those things, no matter how artistic it is ( i.e., lighting, cinematorgraphy, etc.) The story is what people walk away with but it's the performance that keeps them engaged moment to moment while they are watching the film. I'm sure you can imagine how a bad performance could kill the whole project.
Your are on the right track by wanting non-suck talent. The actors will bring a HUGE amount to the project. Be very picky about your casting and make sure you audition everyone. If they don't have a good resume and can't do the audition than forget it. You'll never get a good film out of them. (There are plenty of trained actors to work with so why work with amateurs?) Make sure that you are a non-suck director as well! You might want to take some acting workshops yourself, so you can learn how to spot "false" performances and get the best out of your actors. There are several books out there on directing. I'm reading one now called "Directing Actors" which is quite good.
In that same vein, you don't want your script to suck either. I'm not sure who's doing the writing for you, but make sure the script is solid before you start shooting. The right script with the right take can definitely turn heads. Napoleon Dynamite may not have made big bucks at the theater, but it definitely put those guys on the map. Much of that script seemed like it was simply accommodating the resources they had. But it did it in such a fantastic way! Don't forget the local resource you have when coming up with your script.
As for getting crew, I suggest you try to put non-students in the key positions on your crew. Get as experienced a DP/Cinematographer as possible. Same for the sound guy. Everyone else on the crew can be more green. They are basically just moving stuff around after all. But they'll still be learning by watching the pros work, and you film will be much better for it!
From a technical stand point, sound quality is more important that picture quality. Give sound proper attention. Bad sound will drive the audience crazy while poor picture will only bother them a little. "Bad" picture can sometimes even be justified as a stylistic choice... for example, skip bleach, cross processing, or shooting Super 8 will definitely have a detrimental effect on the image "quality" but given the correct stylistic intent the loss of "quality" might actually be desirable! Bad sound is just, bad sound. Make sure you have a good sound recorder and mikes with someone who knows what they are doing running them.
You can't over-prepare. Scout out locations and have a solid game plan at the very least. I personally would board everything out. I'd probably even do a 3D animatic to figure out what shots you can actually get. (Depending on the lenses you have, It might be physically impossible to place the camera for certain shots in a small room) If you have all your shots planned out in advance, you also wont have to shoot too much "coverage", which will save a bunch of time and tape/film. (The side effect is that it might make editing a lot easier as well) If you want to do any dolly shots, I would definitely do an animatic because they can be a huge time suck. Maybe you don't need that technocrane shot? The animatic will tell you in advance for a lot cheaper! The animatic could be just you working. Once you have your cinematographer, you can bring him in on it also. If you get a cinematographer who says he doesn't like to plan like that I wouldn't trust him. He should know there is room for improvisation and improvement on the set and should feel comfortable with planning. But the idea here is the get a really solid basic plan down so you can be honest about your schedule and get the best stuff on the day. When you are actually shooting, you, as the director, should be totally absorbed in getting the best performance from the actors. You don't want to have to worry too much about shot planning etc.
When you are working cheap like this the main problem is getting the commitments you need from the various cast and crew members to "go the distance". That's another reason why planning is so important. You need to be able to tell everyone exactly what the schedule is and how long a commitment you need from them. The shorter the commitment, the better the odds of getting a seasoned cast/crew. If the script is solid enough you might be amazed at the talent you can attract... assuming the commitment isn't too long.
Sunday, April 29, 2007
Put a chicken to sleep
I know of a method for "hypnotising" chickens. You do it like this:
But this trick for "putting a chicken to sleep was new to me:
But this trick for "putting a chicken to sleep was new to me:
Friday, April 20, 2007
Chicken 2.0
As of April 18th I accomplished my second goal for for my chicken project. I bred chickens that I hatched from eggs (first goal) then bred and hatched the eggs from those chickens (second goal). The dam is definitely Dutches and I'm almost certain the sire of most of them is Black Beard. But it's impossible to say for sure since all three chickens, Dutches, Samson and Black Beard, were penned together. One thing is certain, any chick with tufts must be Black Beards since they can only get tufts from a tufted parent.
Things went amazingly well in the hatch. Every single one of the 10 eggs I put in the incubator hatched. 5 of the 10 chicks have tufts. Based on regular Araucana hatch statistics and taking into account the "lethal" nature of the tufts gene, my results are nothing short of miraculous. ( It's considered "normal" for 25% of an Araucana hatch to die in the shell.) They all seem to be doing pretty well now on day two also. With any luck most of them will grow up OK.
In addition to the Araucanas that I hatched from my own eggs, I acquired some "Araucana" pullets from the feed store. They are actually some type of Easter-Egg chicken. I purchased them since I wasn't sure I would be able to get any of my eggs to hatch and I wanted more hens. Now they are somewhat redundant but at least they'll add a little color to the yard.
Here is a close up of one of the new Araucana chicks.
I use the highly advanced cardboard-box-and-hand-me-down-lamp brooding method. Yeah. Only finest for my chicks.
You can see a movie of the chicks in action here: http://www.mediamax.com/lordtangent/Hosted/Chicks_2.0_day_old.MOV
I'm hatching another couple of batches before getting rid of my adult roosters. I'll decide if I want to do another generation later and figure out what to do for roosters at that point.
Things went amazingly well in the hatch. Every single one of the 10 eggs I put in the incubator hatched. 5 of the 10 chicks have tufts. Based on regular Araucana hatch statistics and taking into account the "lethal" nature of the tufts gene, my results are nothing short of miraculous. ( It's considered "normal" for 25% of an Araucana hatch to die in the shell.) They all seem to be doing pretty well now on day two also. With any luck most of them will grow up OK.
In addition to the Araucanas that I hatched from my own eggs, I acquired some "Araucana" pullets from the feed store. They are actually some type of Easter-Egg chicken. I purchased them since I wasn't sure I would be able to get any of my eggs to hatch and I wanted more hens. Now they are somewhat redundant but at least they'll add a little color to the yard.
Here is a close up of one of the new Araucana chicks.
I use the highly advanced cardboard-box-and-hand-me-down-lamp brooding method. Yeah. Only finest for my chicks.
You can see a movie of the chicks in action here: http://www.mediamax.com/lordtangent/Hosted/Chicks_2.0_day_old.MOV
I'm hatching another couple of batches before getting rid of my adult roosters. I'll decide if I want to do another generation later and figure out what to do for roosters at that point.
Wednesday, April 11, 2007
My RAW Workflow
Since I "Edit" 100% of my final photos in one way or another anyway, RAW workflow doesn't add much hassle to things. At the very least I color grade the images. (Either making them "accurate" or not accurate... it's a creative choice) I use Photoshop "Adobe Camera RAW" loader.
Some people are critical of the quality of the CS2 RAW loader . I find it good enough for my uses. And the convenience of doing everything in one place outweighs any minor quality differences there might be.
JPEG / 8 bit doesn't have the bandwidth for slamming the color around too much so I usually work in 16 bit from the RAW files. "16 bits" really isn't as "accurate" as you might think simply because of how the linear output of the sensor is mapped up to your gamma corrected working color space / display. But it does carry a little extra data that would otherwise get thrown out. It's nice to hang on to that as long as possible. One good thing about working in larger color spaces like ProPhoto RGB is that less of the data is likely to be "rounded out" of even the 16 bits. Keep reading and it might start to make some sense... or none at all.
Here is break down of my process.
0. When shooting, "Expose to the right"
1. Copy RAWs to the computer on a card reader
2. Open RAW in CS2 RAW loader as 16bits/channel, ProPhoto RGB color space (it is the widest gamut color space that ships with Photoshop)
a. While in ACR (Adobe Camera RAW) I do the basic white balance and if required (as is usually the case when exposing to the right) exposure compensation.
3. Image is now in CS2
4. Edit image as required (Still in 16bits/channel, ProPhoto RGB)
5. After image editing is done I direct the output images as required.
a. Save a Photoshop format image with all data if required for later editing
b. CONVERT to sRGB THEN 8 bits per channel for web / modeles proofs
c. Convert to AdobeRGB or CMYK as per printers requirements (for print) You can leave it at 16 bits if you want. Or not. It depends on the printers pref.
The important thing to remember when working in a more advanced color space like ProPhoto is to make sure you re-map it to something usable by the target audience. The ProPhoto color space wont render correctly on 99% of most image viewers because they have no concept of color spaces. Also, 16Bits/Channel is complete overkill for almost all displays. You only need it as a working space to help reduce rounding error. And, depending on your camera, exposure, etc. the signal to noise is WAY worse the precision of 16bits anyway. You are sampling "noise" for no reason. You keep the extra bit depth around as long as possible mostly for the benefits to image processing. (less rounding error) And the slight improvement in capturing actual precision from the RAW file it gives. (There is some signal buried in that noise after all) It's often ok to throw out the extra bits once you are done with your editing. But not until you are done. It's a one way street. There is not much point in promoting 8 bit images to 16 bit because the precision is already gone.
Basically, I try to do all editing in 16bits/channel, ProPhotoRGB and only convert to the smaller gamut / bit depth as the very last step.
There you have it. All my secrets.
Some people are critical of the quality of the CS2 RAW loader . I find it good enough for my uses. And the convenience of doing everything in one place outweighs any minor quality differences there might be.
JPEG / 8 bit doesn't have the bandwidth for slamming the color around too much so I usually work in 16 bit from the RAW files. "16 bits" really isn't as "accurate" as you might think simply because of how the linear output of the sensor is mapped up to your gamma corrected working color space / display. But it does carry a little extra data that would otherwise get thrown out. It's nice to hang on to that as long as possible. One good thing about working in larger color spaces like ProPhoto RGB is that less of the data is likely to be "rounded out" of even the 16 bits. Keep reading and it might start to make some sense... or none at all.
Here is break down of my process.
0. When shooting, "Expose to the right"
1. Copy RAWs to the computer on a card reader
2. Open RAW in CS2 RAW loader as 16bits/channel, ProPhoto RGB color space (it is the widest gamut color space that ships with Photoshop)
a. While in ACR (Adobe Camera RAW) I do the basic white balance and if required (as is usually the case when exposing to the right) exposure compensation.
3. Image is now in CS2
4. Edit image as required (Still in 16bits/channel, ProPhoto RGB)
5. After image editing is done I direct the output images as required.
a. Save a Photoshop format image with all data if required for later editing
b. CONVERT to sRGB THEN 8 bits per channel for web / modeles proofs
c. Convert to AdobeRGB or CMYK as per printers requirements (for print) You can leave it at 16 bits if you want. Or not. It depends on the printers pref.
The important thing to remember when working in a more advanced color space like ProPhoto is to make sure you re-map it to something usable by the target audience. The ProPhoto color space wont render correctly on 99% of most image viewers because they have no concept of color spaces. Also, 16Bits/Channel is complete overkill for almost all displays. You only need it as a working space to help reduce rounding error. And, depending on your camera, exposure, etc. the signal to noise is WAY worse the precision of 16bits anyway. You are sampling "noise" for no reason. You keep the extra bit depth around as long as possible mostly for the benefits to image processing. (less rounding error) And the slight improvement in capturing actual precision from the RAW file it gives. (There is some signal buried in that noise after all) It's often ok to throw out the extra bits once you are done with your editing. But not until you are done. It's a one way street. There is not much point in promoting 8 bit images to 16 bit because the precision is already gone.
Basically, I try to do all editing in 16bits/channel, ProPhotoRGB and only convert to the smaller gamut / bit depth as the very last step.
There you have it. All my secrets.
Saturday, January 06, 2007
Running Lightwave Screamernet ( lwsn ) under Wine on Linux
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!
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:
Posts (Atom)