By ted devlin (Eblue) (12.149.3.2) on Friday, June 14, 2002 - 10:29 am:| By ted devlin (Eblue) (12.149.3.2) on Friday, June 14, 2002 - 10:29 am: |
i have publicly sworn off ever using screamernet bc of design and implementation issues, but i needed to batch render over the weekend, so i decided to give it one more try, perhaps 7.5 fixed some of the glaring problems...
the short answer is : no.
screamernet does not in fact work.
it does not work as advertised, and it does not work like any of the many user based tutorials describe it to work. Perhaps its my hardware, but I can batch render with other applications just fine, and my hardware meets the minimum requirements quite easily, so if it is my hardware, its a Quality Assurance problem at Newtek.
basically the best I have achieved with screamernet is half a render (60 out of 120 frames)... an unbelievable feat of bugginess, that suggests that it was setup correctly, but the program is incapable of doing its job. And now with the same exact setup, it doesn't work at all!!!
here are some liner notes:
1. i am setting up the easiest type of network rendering, a network of 1
cpu :g4 500 agp
ram: 640
os X 10.1.5
LW vers 7.5 clean install-multiple clean installs, included eradicating the pref files.
2. it is actually documented that you have to force quit screamernet, doing this (over and over again) wipes out something very important in my network software, necessitating a restart for the computer, this makes me quite angry.
3. Lightwave 7.5 during a batch render (ok it never gets to the render part anymore, but it does try) now ignores when i hit the escape key, so... I have to Force quit Lightwave to stop it from "rendering" (its really only waiting for screamernet which is doing nothing). This is worse than having to force quit screamernet.
4. None of the tutorials i have found, have been any help. There is only one way to setup screamernet as far as I am concerned, and that is to allow the job and ack files to reside in the content directory and hard coding the content directory in the LWSN cmdline file. otherwise i get Many many errors... like:
SN being unable to find the support files even though it loads the source file just fine, and has reported the content directory properly, and the ever popular:
SN actually ignoring the init command because it claims to not recognize it !!!!
It doesn't seem to matter what LW is setup to do, apparently my version of screamernet cannot use any info from the LW preferences file.
I think if SN was designed better, I would have a better accounting of the bugs I am experiencing, if it was documented such that it did exactly what the documentation says (and trust me It doesn't) I would be able to work with it. If there were no bugs, and there are lots of them, I wouldn't have anything to be mad about, But i need to batch Render, and I have been left high and dry in that area. This experience does not reflect favorably on Lightwave, and frankly I am already looking at other complete 3d solutions that batch render, without this giant mess.
| By js33 (Js33) (12.237.176.188) on Friday, June 14, 2002 - 05:34 pm: |
There are some 3rd party plugins for doing network rendering. You may want to check those instead of using screamernet. Check on Flay.com. I have an iMac with 7.5 and it seems to work fine. Haven't tried to network render it with my PC yet. Also screamernet is really easy to setup on the pc. It works good to.
I don't know why it should be any harder on the mac. I used to use screamernet to render on a pc network with 5 processors and it worked really well. I think it may be harder to get the mac and the pc to network render because of the differences in the filenaming and networking.
I will try soon and let you know if I have any luck.
Cheers,
JS
| By Marcel Valcarce (Marcelval) (65.214.183.163) on Friday, June 14, 2002 - 05:52 pm: |
Well my experience with screamernet has never been good either. Sometimes I have gotten it to work, usually after an hour of screwing around with node directories and config files.
I have networked rendered using softimage, maya, eddie, after effects, combustion, and other software and never had the agrivation I get with screamernet. I think I know why they call it that and it has nothing to do with speed.
Sure some people seem to have no trouble with it, but I hate the feeling of having to pray to voodoo gods to make it work right. When I have a deadline I need to get the rendering done. At my company we have several seats of Maya and 2 seats of Lightwave. I had hoped to convince the management here to get more heavily into LW, but the network rendering lets me down almost every time.
Anyway it seems Newtek is happy to leave this to 3rd parties, unfortunately I don't think anyone has stepped up to the plate in this area on the Mac platform. Also it seems that the built in network rendering in LW is very inferior to what you get from other packages without needing to spend more on a 3rd party solution.
Newtek, are you hearing this??
| By js33 (Js33) (12.237.176.188) on Friday, June 14, 2002 - 06:07 pm: |
Well Alan Hasting (LW programmer) stated that they created the basic framework and yes they did intend for 3rd parties to pick up the slack.
I am going to try my hand at making an OSX frontend control panel for setting this up.
It shouldn't be that hard. After all you are only pointing screamernet to the proper directories.
I think the problem on the Mac lies in the networking paths (or lack of them). On the pc when you setup screamnet you simply map your harddrive as a network drive and then all your scenes must point to those network paths. On the mac i think users must be missing this fundamental concept.
Cheers,
JS
| By Ed Mag (Ed_M) (152.163.194.199) on Friday, June 14, 2002 - 07:42 pm: |
A few things...
Ted, you are absolutely right. And you aren't the only one who is unhappy with the effort NT has put into SneakerNet (phrase coined by JCW :-)
I'm sure you remember the unbelievably long discussion that took place on this very board not too long ago... Lot's of good ideas, lot's of information. Dean Dauger finally gave trying to reason with them. Dean was truly disappointed at NT's reluctance to even let him tinker with an alternative.
Marcel writes:
[[[Anyway it seems NewTek is happy to leave this to 3rd parties, unfortunately I don't think anyone has stepped up to the plate in this area on the Mac platform. ]]]
Marcel, this is only *partly* true. The part worth mentioning is that there *was* an idea presented as well as a *desire* to proceed with it, but it was turned down and fought against to the Nth degree by the NT developers. You can read the entire discussion here:
http://www.newtek.com/discus/messages/2/20109.html?1019438583
At first I was accused of bringing Mac "luminaries" into the discussion. However, these aren't just *any* luminaries... Dr. Dauger is one of the Scientists behind the AppleSeed Project over at UCLA, so I'd say he knows what he is talking about if he says he can do VASTLY better. His web site is: www.daugerresearch.com His e-mail is: d@daugerresearch.com
Similarly, John C. Welch has probably been networking and working in the networking arena before a lot of the NewTek programmers even tapped on a keyboard (the programmers dealing with network rendering issues anyway). He's worked with a multitude of systems and networks over the years. John is also FLUENT in OSX. He added immensely to the discussion that I mentioned above. It's well worth the read if you want to get a feeling of where NewTek stands on this issue.
js33 writes:
[[[I am going to try my hand at making an OSX frontend control panel for setting this up.
It shouldn't be that hard. After all you are only pointing screamernet to the proper directories.
I think the problem on the Mac lies in the networking paths (or lack of them). On the pc when you setup screamnet you simply map your harddrive as a network drive and then all your scenes must point to those network paths. On the mac i think users must be missing this fundamental concept. ]]]
I'm not quite sure that that's the entire issue. The question is... What have the 3rd parties actually been given to work with as far as a framework? Perhaps you should read the previous discussion on this topic as well. Lot's of good info there..
--
Ed M.
| By Julian Johnson (Julianjohnson) (62.49.23.72) on Saturday, June 15, 2002 - 12:41 am: |
Hi JS,
I think the idea of writing a basic interface in OSX which will automate the process of constructing the LWSN cmdline(s) is a very fine one. I'm convinced that most of the problems with Mac Screamer are related to the syntax of those cmdlines. If you'd like a template as a starting point then DStorm's OS9 LWSN Controller shows a simple way of picking the relevant strings although it's a Mode 2 controller.
http://www.dstorm.ab.psiweb.com/dslib/lwsnc/lwsnc-e.sit
I'd be very happy to test and beta anything you came up with :-)
Fundamentally, there are too many areas to debug when Screamer on the Mac seems to go wrong:
1. There is no single comprehensive tutorial or user guide out there covering networking right through to output. The pieces of information available to users are a little disparate and sometimes do the same thing in different ways.
2. Networking, path names and permissions read/write issues on OSX are quite new to people.
3. There are several different ways of constructing the LWSN cmdlines (either being very explicit in all the paths or leaving them to defaults and anything in between).
4. There's no hard and fast way to disassociate a render error because of a bug in the render engine from a bug in Screamer when a batch render fails.
I'm not sure how most PC Screamer setups work but I think the differences for Mac users are that the LWSN apps can all reside on the same machine in the same directory and you can just create new instances of LWSN for each node to use (LWSN1, LWSN2 etc.). I don't think you can do this on a PC and that program and plugin folders need to be copied over to each node. I think it's a little simpler on the Mac in this respect although, importantly, you can do it the 'PC' way if you wish. Similarly, the Mac method for controlling LWSN is via the LWSN cmdline text files whereas most PC users embed the string into the LWSN icon. Network drive mapping is simply substituted with full paths to the appropriate volumes and LWSN seems to use HFS not UNIX path conventions.
As I say, if you need any help or information in constructing this GUI please let me know.
Julian
The Mac Lightwave Resource Page
http://www.exch.demon.co.uk
email:julian@exch.demon.co.uk
| By js33 (Js33) (12.237.176.188) on Saturday, June 15, 2002 - 01:43 am: |
[[[I'm not quite sure that that's the entire issue. The question is... What have the 3rd parties actually been given to work with as far as a framework? Perhaps you should read the previous discussion on this topic as well. Lot's of good info there.. ]]]
Hi Ed,
I read most of that thread. So you are a Mac supporter that doesn't even own a Mac? You use your PC for browsing the web only. OK so I would have to assume that you don't even use Lightwave?
So what do you do? Just curious.
Anyway what Arnie said is basically what I think...that 95% of Mac SN setup problems could be avoided with a simple frontend configuration of the correct commands. I have never seen the volume of posts about SN problems on the LW newsgroups. We have to type in the same commands and save them in a bat file. No big deal. Why is it that PC users have little problem doing this and it's such a big deal on the MAC? Also how would you even have a clue as to whats needed if you
A) Don't have or use a MAC
B) Don't have or use Lightwave?
No offense. I just find it strange that you are so involved in this and don't even use the products.
Cheers,
JS
| By js33 (Js33) (12.237.176.188) on Saturday, June 15, 2002 - 02:02 am: |
[[[I think the idea of writing a basic interface in OSX which will automate the process of constructing the LWSN cmdline(s) is a very fine one. I'm convinced that most of the problems with Mac Screamer are related to the syntax of those cmdlines. If you'd like a template as a starting point then DStorm's OS9 LWSN Controller shows a simple way of picking the relevant strings although it's a Mode 2 controller. ]]]
Hi Julian,
Wow you sem to know alot about it already. Do you program in OSX? I am very new to OSX but I can setup SN on the pc in my sleep. It is really pretty simple. On the PC the only thing required on the node machines is a simple .bat file that points to the LWSN module on the host machine on the network. It is a simple text file with the job1 ack1 on the first processor, job2 ack2 on the second, etc...then you save out the text file as a .bat on the pc and then you simply double click on that .bat file on each machine and it launches LWSN on each machine. Then you simply open the network control panel in LW on the host machine,
init your processors, load your scene(s) and render. I had a 5 processor pc network running and rendering in about 5 minutes.
I guess the Mac must give you more ways to do it which adds to the confusion. Yes it usually is poorly documented. I don't see why NT couldn't have at least written the front end with a GUI for both Mac and PC. Although it seems so straight forward on the PC I guess they assumed it wasn't needed. There are 3rd party frontends available for the pc but i've never used any of them.
I think ButterFly net is working on an OSX version. But a simple front end should be enough.
Cheers,
JS
| By Julian Johnson (Julianjohnson) (62.49.23.72) on Saturday, June 15, 2002 - 09:13 am: |
Hi JS,
OSX coding? No, I'm totally code phobic :-). I think you're right about the multiple ways of configuring screamer on the Mac leading to confusion but ultimately, once you have it figured out on the Mac and set up the way you like it then it's also really simple to go round to the nodes and fire 'em up using cmdlines. Most of the time, it's getting that first working setup right that baffles most users which is where a GUI would be nice. Whilst Jonathan Baker's Screamernet Controller is great it still doesn't help in the process of configuring the network, configuring the instances of LWSN and constructing the cmdlines...
Julian
The Mac Lightwave Resource Page
http://www.exch.demon.co.uk
| By Arnie (Arnie) (65.184.20.249) on Saturday, June 15, 2002 - 09:50 am: |
I think there are far fewer differences between mac and PC LWSN setup. I don't really think running the same executables from different nodes is so great, but if it works, OK.
I actually tried to do a front-end using Applescript Studio, but found AppleScript's bizarre syntax and ultimate lack of functionality unbearable. I started on an objectiveC version w/ProjectBuilder, which is great, but got stuck when I realized that OSX Cocoa functions only want to give unix paths relative to root, and LWSN needs HFS.
Here's a little (layout Generic) lscript which either works, or will be a good starting point. On the mac, it creates the commandline file for LWSN, on the PC it creates the .bat file. It supports all the modes including the obsolete direct connection (-1) mode which was such a hit among those pundits with more networking expertise than animation production experience, and their groupies.
// Make lwsn batch/commandline file file
// by Arnie Cachelin, NewTek, Inc.
// Version 1.0 6/15/02
@version 2.1
@warnings
@script generic
mac = 0;
sep = "\";
#if platform == MACINTOSH
sep = ":";
mac = 1;
#end
protMode: val
{
if(val==3)
return(true);
return false;
}
generic
{
dir = getdir("Install");
if(mac)
fname = dir+sep+"LWSN commandline";
else
fname = dir+sep+"LWSN_Launch.bat";
lwsnFile = File(fname,"w");
if(lwsnFile == nil)
{
error("Cannot open file ",fname);
return;
}
cont = getdir("Content");
cmd = getdir("Command");
conf = getdir("Settings");
node = 1;
mode = 2;
scen = "*.lws";
strt = 1;
endf = 300;
step = 1;
reqbegin("LWSN_Config");
reqsize(415,336);
c1 = ctlfilename("Content Directory ",cont);
ctlposition(c1,25,19,350,19);
c2 = ctlfilename("Command Directory",cmd);
ctlposition(c2,25,49,350,19);
c4 = ctlfilename("Config. Directory ",conf);
ctlposition(c4,25,79,350,19);
c3 = ctlminislider("Node Number ",node,1,100);
ctlposition(c3,25,109,160,19);
s1 = ctlsep(15,384);
ctlposition(s1,15,139,384,5);
c5 = ctlchoice("Screamernet Protocol",mode,@"1","2","3"@);
ctlposition(c5,61,150,330,19);
c6 = ctlfilename("Scene File ",scen);
ctlposition(c6,28,180,345,19);
c7 = ctlinteger("Start Frame",strt);
ctlposition(c7,28,210,134,19);
c8 = ctlinteger("End Frame ",endf);
ctlposition(c8,28,240,134,19);
c9 = ctlinteger("Frame Step",step);
ctlposition(c9,28,270,134,19);
ctlactive(c5, "protMode", c6, c7, c8, c9);
return if !reqpost();
cont = getvalue(c1);
cmd = getvalue(c2);
node = getvalue(c3);
conf = getvalue(c4);
mode = getvalue(c5);
scen = getvalue(c6);
strt = getvalue(c7);
endf = getvalue(c8);
step = getvalue(c9);
reqend();
if(mode!=3)
{
job = string(cmd,sep,"job",node);
ack = string(cmd,sep,"ack",node);
cline = string("-",mode," -D",cont," -C",conf," ",job," ",ack);
}
else
{
cline = string("-",mode," -D",cont," -C",conf," ",scen," ",start," ",endf," ",step);
}
if(mac)
lwsnFile.writeln(cline);
else
lwsnFile.writeln(string("LWSN ",cline));
lwsnFile.close();
}
| By js33 (Js33) (12.237.176.188) on Saturday, June 15, 2002 - 02:37 pm: |
Hi Arnie,
That's great that you took the to do that.
But from what Julian says it seems like there needs to be a Mac FAQ just to setup the network properly before they even start launching SN. Man SN is so easy to setup on the PC I just can't believe that it is that hard on the MAC.
Cheers,
JS
| By Ed Mag (Ed_M) (152.163.201.178) on Saturday, June 15, 2002 - 04:36 pm: |
[[[I read most of that thread. So you are a Mac supporter that doesn't even own a Mac?]]]
Wrong. Not that it has anything to do with the discussion though. I used to set up and configure PC's for people. That didn't go so well. Now I set up and configure Macs for people interested in buying a computer. Honestly... I've yet to have ANY complaints. But that's neither here nor there is it? For instance, did I really have to own a Ford Pinto to know the car was a piece of doo-doo? I've worked on enough automobiles to come to that conclusion though, but that's not to say that my mom knew anything about Pintos, yet it's safe to say that her belief of it being a piece of doo-doo is still justified. Likewise I needn't know anything about how a telephone works to know that there are much better options than 2 tin cans with a string attaching them. Anyway...That isn't what we should be concerned with. However, let's remove me from the discussion entirely. That still leaves John Welch and Dean Dauger. Would you say their understanding of the model is flawed too?
[[[You use your PC for browsing the web only.]]]
Yep. you got it. Anything else and this house of cards might come crashing down. But that really isn't on topic so it makes little difference what I use it for because this adds nothing to this discussion.
[[[OK so I would have to assume that you don't even use Lightwave?
So what do you do? Just curious. ]]]
Yeah, I've used it. But does that *really* matter? If you read the previous discussion, I was ASKED by Dean Dauger to post a thread that would catch people's attention so the topic could be discussed. Ask Dean, he'll verify it. The FACT is that many people seemed to have been complaining about SN. I decided to ask around behind the scenes and talked to a few people to learn what I could. John C. Welch and Dean Daugher were actually nice enough to discuss the matter and bring *their* experience and knowledge to the table. So, I was looking for something that would be in the best interest of the *users* and I figured a lot of those users would appreciate hearing what other experts had to say about SN. I'm not an expert, but I did bring a few along and you'd be surprised at how many other people are reading these forums. (read: competition) Yeah... I was surprised myself.
[[[Anyway what Arnie said is basically what I think...that 95% of Mac SN setup problems could be avoided with a simple frontend configuration of the correct commands. I have never seen the volume of posts about SN problems on the LW newsgroups. We have to type in the same commands and save them in a bat file. No big deal. Why is it that PC users have little problem doing this and it's such a big deal on the MAC? Also how would you even have a clue as to what's needed if you
A) Don't have or use a MAC
B) Don't have or use Lightwave? ]]]
Again, I never claimed to be an expert. (you are definitely wrong on 'A' for sure lol
What I do know is that I've talked to enough people who ARE in fact experts and say SN should just be scrapped. Remember, I was looking around talking to people, reading posts and threads trying to find out what I could about SN. This was after a troublesome weekend trying to configure two systems that a friend owns. Why this is of any importance escapes me. (other than a. to try to avoid the technical issues that were brought up in the previous discussion or b.) to attack *me* hoping to discredit me in some way. Well, like I said, some of the technical details were discussed in the other thread. Ted, John, and Dean all weighed in so you can make *me* out to look the fool if you wish, but the readers of the forum have already read and digested what Dean, John and Ted tried to explain. I'll say it again... Dean asked me to start the thread. Why? Because obviously people were complaining about SN and many wondered if there were any alternatives. Marcel wasn't aware of anyone else attempting to "step up to the plate". No one here bothered to mention that someone *did* make an attempt to provide an alternative. Why did you fail to mention that if you were aware of the previous discussion? I wonder how surprised Marcel will be after reading *that* other thread?
quote:
[[[Anyway it seems NewTek is happy to leave this to 3rd parties, unfortunately I don't think anyone has stepped up to the plate in this area on the Mac platform. ]]]
Anyway, I didn't want him to think that there wasn't an attempt in the past to address this issue
[[[No offense. I just find it strange that you are so involved in this and don't even use the products.]]]
Well, It's not me that NewTek should be worried about... It's their current users. Like someone pointed out, Right now SN might be "good enough" (when you can get it to work)...However, when someone comes along with something that's superior... Now you get it?
--
Ed M.
| By John C. Welch (Jcwelch) (66.189.8.109) on Saturday, June 15, 2002 - 05:12 pm: |
[I actually tried to do a front-end using Applescript Studio, but found AppleScript's bizarre syntax and ultimate lack of functionality unbearable. I started on an objectiveC version w/ProjectBuilder, which is great, but got stuck when I realized that OSX Cocoa functions only want to give unix paths relative to root, and LWSN needs HFS. ]
Um...the syntax is only bizaare if you've never used it, and since AppleScript Studio allows you to hook into any of the Cocoa frameworks, I don't see how it's not functional. As well, you obviously can do HFS paths from within Cocoa and project builder, otherwise you would not be able to run Cocoa applications on HFS+ systems. That's not a problem, so I think you may want to get on some of the Cocoa lists. If AppleScript Studio is giving you fits, there's a mailing list for that as well.
[ It supports all the modes including the obsolete direct connection (-1) mode which was such a hit among those pundits with more networking expertise than animation production experience, and their groupies.]
Well, gosh, how silly of me to think that a user level connection done solely to keep NT from having to do any real TCP/IP coding is silly. Despite the fact that RPC (an open, cross-platform networking standard) works across Mac OS X, windows, and Unix, (okay, so the Mac OS 9 people don't get to play there.), and that it's lightweight, simple, and well documented, which would make it far easier to set up a simple front end that would work, NT insists that it's far better for the customer, (you know, the animation specialists) to have to do all the work to set up networked rendering, so they don't have to.
Actually, I think it's a point to just how bad SN is implemented that an application that does no network operations whatsoever can take longer to set up than the network it supposedly is rendering across.
john
| By js33 (Js33) (12.237.176.188) on Saturday, June 15, 2002 - 05:19 pm: |
Hi Ed,
I'm not trying to discredit you. I just wanted to know where you were coming from.
[[[Now I set up and configure Macs for people interested in buying a computer. Honestly... I've yet to have ANY complaints.]]
What setup and configuration is neccessary on a Mac? That is the beauty of the machines that they don't need any setup or configuration. It seems like you are trying to be a middle man where none is needed.
[[[You use your PC for browsing the web only.
Yep. you got it. Anything else and this house of cards might come crashing down. But that really isn't on topic so it makes little
difference what I use it for because this adds nothing to this discussion. ]]]
Well sorry to disappoint you Ed but I and lots of other people use pcs for Lightwave, Photoshop, After effects, Director, Music apps, Video editing, and other heavy duty apps on w2k/XP and it is a real workhorse. You can run most of these apps at the same time and w2k can and does handle it very well. If you are using w95/98/ME than I agree with you about the house of cards. Those consumer OS's aren't well suited to industrial strength useage and are being phased out by XP which is built on the NT core. By comparison Mac OS9 and earlier are like Win95/98/ME whereas if one program crashes it usually requires a reboot.
Mac OSX on the other hand is more like WinNT/2k/XP where if an app crashes you just restart that app and keep working.
[[[What I do know is that I've talked to enough people who ARE in fact experts and say SN should just be scrapped.]]]
Ok enough about you.
There is nothing wrong with screamernet itself.
But I definately agree that it should ship with a GUI frontend that is easy to use and within a few minutes you are ready to network render. I have no problem at all listening to other viewpoints on the subject but it got off on a tangent about clustering which sounds cool but isn't needed to make SN work properly. Also Arnie graciously answered all the questions that were posed to him. Noone on that other discussion has the same knowledge of the app that Arnie does since he actually programs for Lightwave. I certainly appreciate the effort of anyone to improve the product but most of them are somewhat misguided.
Cheers,
JS
| By Ed Mag (Ed_M) (152.163.201.179) on Saturday, June 15, 2002 - 06:21 pm: |
[[[What setup and configuration is necessary on a Mac? That is the beauty of the machines that they don't need any setup or configuration. It seems like you are trying to be a middle man where none is needed. ]]]
Yeah? Well, I know a bunch of windows-converts who were a little uncomfortable at first. These weren't very technical people mind you. But, let's not loose sight because everyone isn't an egghead and that being such is not a requirement.
[[[Well, sorry to disappoint you Ed but I and lots of other people use pcs for Lightwave, Photoshop, After effects, Director, Music apps, Video editing, and other heavy duty apps on w2k/XP and it is a real workhorse. You can run most of these apps at the same time and w2k can and does handle it very well. If you are using w95/98/ME than I agree with you about the house of cards. Those consumer OS's aren't well suited to industrial strength useage and are being phased out by XP which is built on the NT core. ]]]
Spare me -- please. I can do cross-platform work (mostly Photoshop) just fine. I choose the Mac because it simply works better. I don't want to work *on* my computer. I want to get work DONE *with* my computer.There is a difference. Anyway, what do *you* know about the NT core? Ah, let's forget it... It really has nothing to do with the current conversation and the *NT core* isn't anything to get excited about...
[[[Mac OSX on the other hand is more like WinNT/2k/XP where if an app crashes you just restart that app and keep working. ]]]
Yes,... I know. However, you'll have to explain to me how my cousin's Dell at work (he's AutoCAD engineer) seems to lockup on Win2k from time to time; locks pretty good sometimes. I can get the build-sheet that came with the box if you want. Oh, and the machine came with an $800.00 graphics card that he says isn't worth spit... But that's way off-topic.
Anyway... back to the original discussion. What I want is to see people getting their $$ worth. It wasn't until I started asking around and reading threads that I noticed how many people were displeased with the whole implementation of SN.
[[[But I definitely agree that it should ship with a GUI frontend that is easy to use and within a few minutes you are ready to network render. ]]]
OK, let's see if you can understand what I'm trying to get at... Let's say someone develops the *perfect* front-end solution for SN, does that correct any of the underlying problems and limitations inherent to the current implementation? From what's been conveyed about SN, the whole process just seems cobbled together. If memory serves me right, wasn't NT charging like $2000.00 for this implementation for a limited number of boxes? The point is -- Having a kick-ass front-end is only a Band-Aid. It only treats the symptoms and does nothing to help heal or cure the actual ailment. I'm sure others would agree. Look, I'm just trying to help. One of the ways is to introduce alternative viewpoints from individuals willing to help with SN implementation. Both JCW and Dean would LOVE to help NT. John is a bit of an AppleScript master. I'm sure he could whip-up any implementation Arnie needed. All he has to do is collaborate with him. However..it's the underlying issues that people will ignore if a great front-end is developed. Is that what users *really* want? Another "Windows"?? Has anyone at NT bothered to have a poll asking users if they are happy with the current implementation? Oh, BTW, I've been wondering... What would be a better tradeoff, having say -- a "Mac-specific" render-farm solution that can take advantage of the unique advantages associated with the Mac platform or maintaining cross-platform render-farm functionality that is mediocre at best? Seriously. Has anyone bothered to ask the *users* whether or not they preferred a "platform specific" solution? I wouldn't be surprised if competing applications start to release superior implementations and I can't imagine who's lurking on these boards anymore.
--
Ed
| By js33 (Js33) (12.237.176.188) on Saturday, June 15, 2002 - 07:16 pm: |
Hi Ed,
[[[ Spare me -- please. I can do cross-platform work (mostly Photoshop) just fine. I choose the Mac because it simply works better. I don't want to work *on* my computer. I want to get work DONE *with* my computer.There is a difference. Anyway, what do *you* know about the NT core? Ah, let's forget it... It really has nothing to do with the current conversation and the *NT core* isn't anything to get excited
about... ]]]
Well I use a win2k system and really stress it almost everyday with the already mentioned apps and I haven't had a crash in months. Also NT/w2k/XP have had pre-emptive multitasking, mutlithreading, memory protection, and solid memory management for years (since 1993). And the Mac is just now getting these capabilites with OSX. So it is only 9 years behind NT but better late than never.
[[[ Yes,... I know. However, you'll have to explain to me how my cousin's Dell at work (he's AutoCAD engineer) seems to lockup on Win2k from time to time; locks pretty good sometimes. I can get the build-sheet that came with the box if you want. Oh, and the machine came with an $800.00 graphics card that he says isn't worth spit... But that's way off-topic. ]]]
Well any app on any platform can lockup. Don't use AutoCad so I don't know about that app. Sometimes people will load up their computers with alot of free software that is poorly written. Could be an issue with the graphics card/drivers. These things change fast and are updated frequently. There is also a lot of hype (like in the Apple world) regarding highend graphics cards. Most people have standardized on nVidia GeForce cards (as have Apple) as the most bang for the buck.
[[[OK, let's see if you can understand what I'm trying to get at... Let's say someone develops the *perfect* front-end solution for SN, does that correct any of the underlying problems and limitations inherent to the current implementation?]]]
OK Ed I'm not saying SN is perfect or can't be improved upon. But it simply is not broken as you insist it is. Sure it needs a good frontend for the less technically inclined but it works very good actually (once you get it working). I have networked rendered hundreds of thousands of frames with it over the years with no problem. I would like to see what Mac specific improvements are possible now that OSX is coming along.
Cheers,
JS
| By Beam Tracer (Beamtracer) (210.50.30.4) on Saturday, June 15, 2002 - 08:28 pm: |
Is OS9 a weight around our necks here? As Mr Welch points out, using systems like RPC is only possible when OS9 doesn't "have to play". Also, if we stop using OS9 and Classic applications, we could format our hard drives in the UNIX UFS format (rather than HFS or HFS+). UFS works with Carbon and Cocoa apps, but not Classic.
| By Julian Johnson (Julianjohnson) (62.49.23.72) on Sunday, June 16, 2002 - 01:19 am: |
On the complexity (or not) of setting Screamer up in OSX, I think a lot of initial configuration options (apart from the GUI) are probably a significant factor. I don't know how it works on a PC but on the Mac you have three basic structures:
1. Copy the program and plugin folders to each node.
2. Create separate directories on the host machine which contain the program folders for each node (activated remotely).
3. Create 'instances' of LWSN (LWSN1, LWSN2 and the LWSN1 cmdline, LWSN2 cmdline etc.) in your normal Program folder and then activate remotely.
In each of those scenarios you have the option of copying your Lightwave Layout 3 Prefs and Lightwave Extensions 3 Prefs to the appropriate Preferences folder on the node or to direct LWSN to pick up the Prefs from the host.
The potential to 'mix up' is compounded when the existing tutorials use different methods - most of the early tutorials suggested copying the software and prefs to the nodes which was a nightmare if you updated the prefs. Lately, tutorials have concentrated on the last two methods - Method 3 being by far the easiest to set up and administer.
So, certainly using Method 3, Mac Screamernet seems as simple as using the .bat method on a PC. What's been missing are the kind of definitive setup instructions that PC users have enjoyed over the years. I know, for example, that it's taken me three years (!!) to realise that you could specify the location of the jobx and ackx files in the cmdline to LWSN - I always assumed LWSN would read the Command Directory from Lightwave Layout 3 Prefs! It never did, of course...
Julian
The Mac Lightwave Resource Page
http://www.exch.demon.co.uk
| By ~@~ (Phong) (66.52.180.36) on Sunday, June 16, 2002 - 07:40 am: |
A little over a year ago I offered to provide a source snippet from my little render farm and suggested a background rendering solution be created in one of the alternative unices.
http://www.newtek.com/discus/messages/2/422.html?#POST10769
(added to show I was willing to help at one time).
In the meantime...
Arnie, here's some 'stuff' you might want to read:
"Accelerating the convergence of film and real-time rendering"
http://firingsquad.gamers.com/hardware/cg/default.asp
on nVidia's Cg technology and here is a quote:
"Cg will do for GPUs what C and C++ did for CPUs" -Jen Hsun Huang, CEO NVIDIA Corporation
| By John C. Welch (Jcwelch) (66.189.8.109) on Sunday, June 16, 2002 - 08:40 am: |
[Is OS9 a weight around our necks here? As Mr Welch points out, using systems like RPC is only possible when OS9 doesn't "have to play". Also, if we stop using OS9 and Classic applications, we could format our hard drives in the UNIX UFS format (rather than HFS or HFS+). UFS works with Carbon and Cocoa apps, but not Classic.]
First, I would not use UFS on Mac OS X unless you have a clear requirement to do so. The Mac OS X implementation of UFS is slow, because it has to manage to act like HFS+ for things like metadata, creation dates, etc. HFS+ is an excellent file system, and is only now being used right in Mac OS X. The problem with Mac OS 9 is that while it's really stable once you set it up right, once something goes wrong, it rolls downhill until you reboot. I've had 9 servers running with 18+ month uptimes, so you can get them stable.
The biggest advantage to Mac OS X is that it supports a much larger set of standards, like the aforementioned RPC, which is just a lightweight way to kick off processes on other machines, and be notified of the results. Quite nice for distributed computing. Every copy comes with secure ways to converse with other boxes at a low level, via SSH. Every copy comes with a lightweight, albeit insecure way to transfer files, namely FTP. As well, most of the major Mac vendors are Mac OS X only, so it's not like NT would be breaking a lot of new ground there, and in fact, it would make their life far easier by reducing codebase complexity.
But then, I'm just a network maven keeping my groupies happy. ;-P
| By Ed Mag (Ed_M) (64.12.102.47) on Sunday, June 16, 2002 - 09:00 am: |
[[[Well I use a win2k system and really stress it almost everyday with the already mentioned apps and I haven't had a crash in months. Also NT/w2k/XP have had pre-emptive multitasking, mutlithreading, memory protection, and solid memory management for years (since 1993). And the Mac is just now getting these capabilites with OSX. So it is only 9 years behind NT but better late than never. ]]]
We are getting a little off topic, but in short, that's what M$ tells you on the side of the box when you buy their OS. But is it *really* the case? You say that Macs didn't have memory protection until the advent of OSX. That implies that there must have been a *need* for it. And I'm not convinced there was a need. There is obviously a need for it in the Windoze world simply because there are a LOT of bad programmers and sloppy code being written. In short, Micro$oft took something that was essentially unneeded or something silly and turned it into something they could "market to the masses" and people bought into it as if was this great feature! Anyway, now that OSX has a solid UNIX foundation, I'd guess that it's particular memory protection schemes are further along and more robust than anything from Redmond simply because UNIX as been maturing for over say-- 30 years now? You might want to take some time and read Dave Every's article here:
http://www.mackido.com/Myths/memoryprotection.html
So, Windows memory protection and management have not been *that* solid... It's how it was marketed.
Likewise, you should also read his article discussing multithreading (which Macs have always had) and multitasking. Here is the link:
http://www.mackido.com/Myths/mt.html
I'm sure those two articles will clear up a few myths that have been propagated over the years regarding Windows systems. Anyway, the point is that it's the "underbelly" that users should be concerned with. Putting a pretty paint-job over an old jalopy (or poor implementation) does nothing but conceal the true nature of the beast.
I'm glad that these issues continue to be discussed. And to get the best possible experience from the technologies that the Mac and OSX have to offer, I think a platform-specific approach is definitely needed. I haven't heard from Dean in a while. Perhaps I should e-mail him. He seemed pretty excited at the time of the first discussion. What he wanted to do was provide a Mac-exclusive clustering solution that would handle rendering jobs easily, quickly and efficiently. People are aware of AppleSeed and that was just the start. AppleSeed is maturing at a rapid pace. Dean has the numbers and he can show that the throughput will rival the best PC/LINUX setups and to top it off, it isn't fragile like the LINUX implementations or as tedious to set up. You can e-mail him and discuss any of the specifics if you wish. Again, throughput is the thing to focus on here; a pretty face can come later. And Dean *wanted* to bring his to Lightwave. Arnie hit the nail solidly on the head too... He was going to utilize AppleScript to form the front-end. I bet that would be great and fit well in to the Dean's plan. Well, if it has to do with AppleScript or networking, then John Welch is the guy to talk to in that regard. I bet if Arnie asked him.... ;-) Similarly, Dean would have been the man to handle the underbelly of the project. Would have made for a great collaborative effort.
The first step is to forget about OS9 completely. NewTek should already be working on a version of Lightwave that is written in Cocoa. The OmniGroup could probably handle the task if NewTek decided to outsource the job. They have many years of cocoa experience. On another note, I'd be curious to know if Chris Cox has had a chance to sit down with the NewTek guys yet to go over their G4 optimizations yet. I haven't heard from Chris in a while either... Anyway, that makes 3 individuals willing to help rebuild the some of the problem areas of Lightwave. Again, it's not *me* that NewTek has to cater to (what do I know), It's people like you, the ACTUAL, professional users that use these wares to make a living with your Macs. If someone isn't developing the best possible applications to allow you to get the absolute most from your tools then what is the point of using your favorite tool? The Mac has LOT of untapped potential. Now with OSX there is even more. Sometimes what's *easiest* or cheapest isn't always in the best interest of the customers. People loath change.
I think if developers continue to cling to old practices and current models (read x86/Wintel), we are all missing out. More focus is needed on OS X. Have you ever wondered if the G4 is actually being used to it's fullest capabilities? I have. I talk to a bunch of programmers and engineers and I've gotten a lot of good (and sometimes surprising) information regarding the G4. For instance, apps that increase the amount of parallelism in their data processing will get a LOT more bang for the buck. You want to let the processor do MANY things at once. And this is just for scalar units. The same approach applied to a multiprocessing environment (and AltiVec) would show even greater performance. The scalar units, by virtue of their pipelines, are capable of doing three to five operations simultaneously! However if you don't give them those 3-5 things to do at EVERY given moment, that power goes unused; which is why Mac users are a little disappointed when they compare their benchmark times to PC folk. It has a LOT to do with how the code takes advantage of particular features of a given CPU.
I'd venture to bet that most (as in: a lot) of these 3D apps just do one thing at a time (for the most part), and are probably wasting 60-80% of the CPU cycles and thus a lot of potential computing power. Of course I'm only guessing here...but it does make you wonder. Anyway, the AltiVec unit is also pipelined, so it is important to do a lot in parallel things with AltiVec too. OK, sorry for getting a bit off topic. I'd much rather read threads specific to SN implementation. After all, SN is what the discussion is *supposed* to be about :-)
--
Ed
| By js33 (Js33) (12.237.176.188) on Sunday, June 16, 2002 - 01:56 pm: |
Hi Ed,
I agree completely with most of what you said except for the Windows stuff. You have to make the distinction between NT/2000/XP which are good and solid and W95/98/ME which are not. Those old weak consumer versions are going away just like OS9 is. So this will be better for everyone. Especially people like me that use both systems.
Anyway back to topic.
I would hope that render speed can be improved on the g4 as right now its no faster at rendering than my P3 800 Mhz when I was told a G4 equaled the speed of a P4 1.7 Ghz. This is truely not the case at this point in time at least with Lightwave.
Also it doesn't seem like building a cocoa frontend to screamernet would be a big deal. I saw that Arnie started on an Applescript version of it but gave up due to the weird syntax. I don't know if its just that he's not familiar enough with it or he found a better way. He also posted code for an Lscript (haven't tried it yet).
I believe OSX will get better and faster as we go forward but Apple seriously needs better and faster hardware. All this Altivec stuff is largely overblown and does little to nothing to improve render speeds. I don't know if like you say its not being fully implemented or the kind of things it optimizes are not used in 3d calculations.
Cheers,
JS
| By Ed Mag (Ed_M) (138.89.167.110) on Sunday, June 16, 2002 - 04:06 pm: |
[[[Apple seriously needs better and faster hardware. All this Altivec stuff is largely overblown and does little to nothing to
improve render speeds. I don't know if like you say its not being fully implemented or the kind of things it optimizes are not used in 3d
calculations. ]]]
You really have no idea what you are saying, do you? As for AltiVec being overblown... I suggest that you check out the
distributed.net marks and then get back to me. Apples hardware slow? In what regard? be specific. I strongly suggest that you read
the comments made by Chris Cox (Adobe) here:
http://www.newtek.com/discus/messages/2/16932.html?1013655265
Mac hardware is NOT slow. Don't fall for the numbers that seem to be thrown around liberally these days. It's how the hardware is
being utilized that makes all the difference. So, what types of calculations are absolutely necessary (and used everywhere) in
Lightwave that AltiVec isn't good for? Again, I've been doing some snooping and asking certain people some obvious questions. I'd
be interested to hear what *you* believe is holding back the Mac, AltiVec and OSX from taking full advantage of apps like Lightwave.
If you want, reopen that particular thread or better yet e-mail Chris for the facts about Apple's hardware. BTW... Chris, Adobe, Intel
and AMD do far more work optimizing for Wintel then they do for the Mac. If I'm not mistaken there are something like 4 Intel
engineers that must look at the code before it allowed to ship. Anyway, that's an entirely different discussion.
--
Ed
| By ted devlin (Eblue) (12.149.3.2) on Monday, June 17, 2002 - 11:43 am: |
i have to say,
most of this thread has very little to do with my original post.
I appreciate the interest,
the mentions of work in progress by arnie,
ed mag's interest,
julian's positive outlook,
and the many assertions that screamernet is simply understood, not buggy,
etc...
but frankly,
I still hold that mac screamer net, is not in fact reliable. It IS buggy, and not documented. So, when it worked, I have no clear idea why it did work, and when it failed... in the middle of a ridiculously simple render, there is no clear indication from the Non-existent documentation, why that is either. And the networking issues? Non existent In my setup, bc its a 1 node farm and the farm is the same cpu as the controller.
In addition, I have found that Screamernet isn't even consistent in its failures. Sometimes it can find the support files, while other times (most of the time) it can't find Any support files, all of this occurring under the same setup!!! So it is safe to say that a controller app, for Screamernet, will do nothing to fix that problem, I'm sorry arnie, I appreciate the value of the work you have done, but it just doesn't address any of the problems.
btw: Arnie, if you are serious about making a go at a render controller in one of Apple's other dev environments, please, take a closer look. it sounds like you are used to doing things one way, and because say: Cocoa for instance, doesn't work the way you expect, you have written it off. Cocoa indeed can and does deal with HFS+ paths, and in addition it has multiple ways in which you can translate hfs+ to unix paths and back, as well as an even more powerful engine to deal primarily with the abstraction of such data, and making the differences trivial for programmers. This engine can be used to generate single paths, to specific locations on particular machines anywhere they are accessible, and its available in almost all of the frameworks you mentioned. look for URLServices, NSUrl, or any references to URL in the Dev Help center.
I'm sure i haven't exhausted the possibilities, in debugging Screamernet, in fact I am positive that there are literally hundreds of things i could try. The fact that:
A. getting screamernet to work is not obvious.
B. there are no instructions for screamernet.
C. and when it does run, it doesn't work.
really makes me question if it is even appropriate to have released this product. I mean, it should be trivial to write a panel that allows the user to load and hit render for multiple animations, without forcing the user to bend over and kiss himself on the rear. I have already shared my point of view about the viability of Screamernet as a network renderer, and as far as it goes that aspect has little impact on me, but now it has eliminated a very important feature that I expect in any modern, offline content creation application... the ability to batch render.
so here it is:
Screamernet for mac os X Lightwave vers. 7.5, is not up to the task of batch rendering. It is very hard to setup (while by all accounts shouldn't need to be setup at all for this), undocumented, and very buggy. whether due to coding errors, design flaws, or simply that it hasn't been updated properly bc the proper way to do it hasn't come to light yet, is all immmaterial. its buggy. O and btw, just bc someone else is used to the quirks of Screamernet, does not mean that it isn't buggy.
| By ted devlin (Eblue) (12.149.3.2) on Monday, June 17, 2002 - 01:51 pm: |
now i am going off-topic,
o well... ;)
why is it, that the screamernet interface is part of the lightwave application, and the screamernet application is not a part of the lightwave application? I'm talking about the network rendering panel. Shouldn't that be in the same application that does the network rendering?
it doesn't make any sense, to leave it in Lightwave.
the network rendering panel inside Lightwave should be the front end to screamernet, or... screamernet should be inside lightwave, which is incredibly redundant, and not a good idea to begin with, since you can't work while you are network rendering anyway.
If the network rendering panel was the front end to screamernet, then it would obviously need a few cosmetic changes, to accomadate the different modes(-1,-2,-3), and the nodality (node = true/false) of the renderer, as well as render feedback.
then configuration would be a breeze, lightwave could be Doing Something Else during a render, and all of the problems that have cropped up because of the wierd, counterintuitive, split of features among LW and Screamernet, that necessitate complex setups, would be almost wiped away.
anyway, its a thought.
| By Marcel Valcarce (Marcelval) (65.214.183.163) on Monday, June 17, 2002 - 05:12 pm: |
I agree with Ted that this is a runaway thread. I can tell you what would be really nice to be able to do with LW
#1 Batch Render on a single machine. I think this should be a separate app to avoid the overhead of having LW loaded but not rendering since LWSN is doing the rendering. This simple gui would allow me to specify a list of scenes I want rendered, the content path for each scene, and the output path, file type, and frame range for each scene. Clicking a "render" button should let me go home and know that in the morning my 20 scenes will be rendered. Oh, and how about a log file to tell me if there were problems and why.
#2 Network rendering on multiple machines:
We are living in the TCP-IP age, and it is inexcusable that network rendering not take advantage of this. To the application I just mentioned add a tab which allows me to enter a list of machine names in the form gandalf.pactitle.com, elrond.pactitle.com, aragorn.pactitle.com, etc. (I have now given away my work place, and our naming sceme). The program should then launch the rendeing engine on those machines (assuming it has been installed and setup by the techies) send the data (perhaps to be cached locally if that makes sense) and then be done.
I don't want job files! I don't want ack files!
Rant Over.
| By Ed Mag (Ed_M) (205.188.200.145) on Monday, June 17, 2002 - 05:20 pm: |
[[[really makes me question if it is even appropriate to have released this product. ]]]
This product cost U.S. $1995.00 at one time. It supported up to 8 machines.. ;-)
http://www.fhi-berlin.mpg.de/amiga/ar/ar223.guide
Hmmmm....
--
Ed
| By js33 (Js33) (12.237.176.188) on Monday, June 17, 2002 - 08:15 pm: |
[[This product cost U.S. $1995.00 at one time. It supported up to 8 machines.. ;-) ]]
Yeah. Remember the Lisa. A $10,000 flop.
I read that but I don't ever remember a standalone software product that came out at that or any price. It was always part of the Video Toaster LW then later standalone LW. We used to have what was called a Screamer render station that had two Mips 4400s running WinNT. And in 1993 it was a Screamer compared to anything else at the time. It was basically a dual SGI networked to the Amiga.
Cheers,
JS
| By js33 (Js33) (12.237.176.188) on Monday, June 17, 2002 - 08:52 pm: |
Ed,
[[[You really have no idea what you are saying, do you? As for AltiVec being overblown... I suggest that you check out the
distributed.net marks and then get back to me. Apples hardware slow? In what regard? be specific.]]]
Oh my brother but I do.
Here are some render benchmarks times between my PC which is an 800 Mhz P3 and my new iMac 800 Mhz G4.
Scene iMac G4 800 Intel p3 800
Raytrace 6 m 33 sec 6 m 20 sec
Chimney_All 12 m 35 sec 8 m 59 sec
DOF 36 sec 28 sec
Textures 18 sec 14 sec
Jacks_refblur 7 m 25 sec 9 m 1 sec
RadiosityRefThings 3 m 44 sec 3 m 33 sec
Skull_Head_newest 7 m 31 sec 10 m 34 sec
| By Ed Mag (Ed_M) (64.12.102.26) on Tuesday, June 18, 2002 - 05:41 pm: |
[[[Supposedly the hype machine says a G4 800Mhz is equivalent to a p4 1.6 Ghz but my render tests show that not to be true. ]]]
Sounds like it could be the code within Lightwave.. You are assuming everything is being done to optimize for the G4 correctly. OAN, have you bothered to read opposite comments made by Chris Cox on the link I provided?... Have you checked out distributed.net yet?
[[[So I don't now if LW is just not totally optimized for Altivec or if Altivec is just a bunch of hype. ]]]
Then you should endeavor to learn a little bit more about it, no? Otherwise, check out distributed.net.
[[[Floating point.
Doesn't the Altivec only accelerate integer calculations such as the Gaussian Blur in Photoshop. Why doesn't Steve Jobs show 3D rendering speeds as a benchmark at Macworld? Because given the current hardware it would be embarassing. ]]]
You have to be specific... If I'm not mistaken, the G4 already outperforms the Pentiums in floating point calculations... Besides, AltiVec is a VECTOR processor. It can do floating point as well.
[[[1) Much faster processors to start with G5 2Ghz (how does that sound)? ]]]
Sounds sweet but highly unlikely right now.. see next comment.
[[[2) Faster memory. DDR at least with 533Mhz bus just like the current PCs are using. While this is not neccessary to improve render speeds it is good for video editing, multichannel music streaming, etc... ]]]
Again with the #'s..... Yaaaaaaaaaaawwwwwwwn. I've got a better one for you. How about forgetting about the supporting chip set/memory controller and bus all together and integrate the memory controller right onto the CPU for a direct link to DDR-SDRAM? There is talk about Motorola integrating the memory controller right onto future PPC's. They are already doing it on the Book-e 8540's This will effectively eliminate any bottlenecks since you could now feed the processor as fast as it needs to be.
You and your larger *numbers*.. Sheesh! How about understanding what they mean? And if you don't understand them or *care* to understand them, how can you dare make reference to them? Here do some reading on future Motorola offerings:
http://www.eetimes.com/story/OEG20010828S0091
http://www.eetimes.com/story/OEG20011024S0055
(note when the articles were written and note that the 8540's are already out. Also note the designation of what Motorola calls a "G5". Technically speaking the 8540's are in fact G5 microprocessors, but they aren't desktop cpus. However, you would be wise to read up on that processor because it is likely that a LOT of that technology will make it's way into the next iteration of an Apple-utilized CPU. Oh, and I think it would be better that you reopen the particular thread where all of this was discussed once before. This is ScreamerNet discussion.
--
Ed M.
| By Beam Tracer (Beamtracer) (210.50.30.3) on Tuesday, June 18, 2002 - 05:55 pm: |
The ScreamerNet thread is now lost
| By js33 (Js33) (12.237.176.188) on Tuesday, June 18, 2002 - 06:55 pm: |
Hi Ed and Beam Tracer,
Sorry to have dragged this thread off topic.
This will be the last post regarding the hardware.
Ed I will read the links you provided about Altivec. Also I really hope Apple does start beefing up the hardware because they are going to need it to run all these highend film production apps they've been buying not to mention Lightwave.
The memory controller on the chip sounds cool but I expect we will be seeing similiar technology on all processors. Apple and Motorola don't live in a vaccuum. Progress happens constantly on all platforms.
Also I want faster Macs for lightwave but at this point, no matter what you say the PPC chip is capable of, the rendering times do not lie about the current speed.
Now where was that Screamernet controller plugin...
Cheers,
JS
| By Ed Mag (Ed_M) (64.12.103.27) on Wednesday, June 19, 2002 - 06:33 am: |
[[[The memory controller on the chip sounds cool but I expect we will be seeing similiar technology on all processors.]]]
Do you really think they will attempt to integrate even MORE added complexity into the Athlon and Pentium designs? I doubt it. They have enough problems developing supporting controllers and chip sets from 3rd parties. Riddled with bugs and incompatibility issues. Then there is the problem with die size... How big do these already monolithic processors expect to get? How complex? More parts, the more likely hood for more bugs and an exponential increase in the amount of time required to troubleshoot them. Add in the factors of power consumption and HEAT and the mix doesn't seem likely at all. In other words, AMD and Intel will have just about everything going against them. Design complexity, support, testing, bugs, troubleshooting, heat issues, power consumption etc.... And besides, the PowerPC is designed to be modular. The AMD chips and Pentiums are not. You can think of them more like a bowl of stew and the PPC a meal that will have all the courses separate. And just like stew, the more ingredients that you add will likely foul the *taste* before long.
[[[Also I want faster Macs for lightwave but at this point, no matter what you say the PPC chip is capable of, the rendering times do not lie about the current speed. ]]]
Then why blame the CPU? How do you know it isn't the code? I'd lay odds that it has more to do with the code than it does the hardware.
--
Ed
| By Ed Mag (Ed_M) (64.12.105.166) on Wednesday, June 19, 2002 - 12:03 pm: |
If anyone is interested:
http://developer.apple.com/hardware/ve/performance_memory.html
Perhaps the NewTek guys would also be interested.
--
Ed
| By js33 (Js33) (12.237.176.188) on Wednesday, June 19, 2002 - 07:41 pm: |
Hi Ed,
Well I just hope you are right about the PPC capabilites but I think if it was as easy as you think it is to boost the performance then why is the PPC lagging so far behind cheaper computers when it comes to rendering speed? Apparently all the heat, bugs, incompatibilites, of the AMD/Intel have not kept them from steadily decreasing render times over the years. Lightwave has been available since version 5 on the Mac and it is still lagging behind. I do think Apple is in serious catch up mode but time will tell if it bears any fruit (no pun intended) hehehe.
Cheers,
JS
| By Ed Mag (Ed_M) (64.12.102.38) on Wednesday, June 19, 2002 - 10:17 pm: |
[[[Lightwave has been available since version 5 on the Mac and it is still lagging behind. ]]]
That doesn't mean anything; especially if the port was from x86 code. If I'm not mistaken, Lightwave uses a common code base. If that is the nature of the beast then it is highly likely that it's a bit x86 biased without even realizing it. As mentioned in another forum, the best thing NewTek could do is hit the lists and forums where experienced Mac developers reside. I sure hope NewTek sets something up with Chris Cox soon. It's likely that he can show them a thing or two. I still feel that it has a lot to do with the code and the *understanding* of it in relation to the platform. Still, it begs the question... What the heck is NewTek doing with rendering that portrays AltiVec as more or less insignificant? Seriously, I'd be interested in the areas (and it seems like an awful lot) of their code that will not benefit from AltiVec and of course the reason. Yes, this thread has gotten off topic. if it continues in this direction, I will end up reopening the original post that dealt with this issue. As a matter of fact, I just might do that in the AM. Going to sleep now...
--
Ed
| By ted devlin (Eblue) (12.149.3.2) on Thursday, June 20, 2002 - 10:25 am: |
the exact text of my command line, as saved in my LWSN cmdLine file:
-2 -c"baka:Users:ted:Library:Preferences" job1 ack1
i doubt that this is wrong, but feel free to debug it.
steps i follow to start a Batch render...
1. launch screamernet
2. launch lw, open file, check the save path, save file close it. check the content directory* and quit LW
3. launch lightwave, init cpus in network render dialog.
4. depending upon the response, if a cpu is found then i load the scene file(s), otherwise i must start all over again.
5. hit the render button
6. watch as Screamernet reports many different and interesting problems, or doesn't respond at all after being told to load a scene.
* i frequently change my content directory, I keep them small(as small as possible) and uncluttered. They have simple short names, without special characters or spaces. they exist in paths that have no special characters or spaces. the render target path is in the content directory, in an additional directory called: Render. I use only the targa format for my images, i stay away from image sequences (screamernet has a huge problem with image sequences). In short, there is no way i have knowingly put files anywhere they can't be found, by screamernet.
I worked my a$$ off trying to bend so that i could batch render, and screamernet still doesn't work! Please, I appreciate the advice, and the opinons, but I am as certain that i am not doing anything wrong here, and without a handbook, or a reference guide, I am as much of an expert as anybody else.
| By Arnie Cachelin (Arnie) (65.184.20.249) on Thursday, June 20, 2002 - 10:37 am: |
If you launch LWSN before setting the content directory in layout, and without specifying the content directory on the LWSN commandline, it is quite possible that the content directory used by LWSN is incorrect. Can you be more specific about some of the problems reported?
| By Julian Johnson (Julianjohnson) (62.49.23.72) on Thursday, June 20, 2002 - 11:12 am: |
Hi Ted,
I think you know that trying to debug Screamer remotely is a real headache but from the detail you've posted it's hard to see anything wrong - especially as you're not trying to wrangle any networking to a node. I assume that you're not actually changing your Content Directory after you launch LWSN, just *checking* it as you say in your post otherwise Arnie's right - there's no way LWSN would understand what you're up to if you change the Content Directory after you launch LWSN and don't specify a Content Directory in the LWSN cmdline.
In that context, your -2 line looks absolutely right assuming you keep your preferences in their default location and you're directing your Command Directory to your Content Directory in the Network Rendering control panel. I noticed in your first post that you said you 'hard coded' your Content Directory in your LWSN cmdline. In the cmdline you've posted the only thing you've hard coded is your config directory (the whereabouts of your preference files).
How about explicitly stating *all* of the paths directly in the LWSN cmdline to eliminate any uncertainty and help you debug:
-2 -c"baka:Users:ted:Library:Preferences" -d"baka:yourcontentdirectory" "baka:yourcontentdirectory:job1" "baka:yourcontentdirectory:ack1"
That way you can be sure you have absolute control over where LWSN is looking for stuff.
You also mention that you're force quitting LWSN a lot and having trouble using the Esc key. Is it possible that you've got some corrupt Job1 and Ack1 files sitting in the Command Directory (which in your case is the same as the Content Directory). Sometimes, if you force quit these files can hang around and wreak havoc. A normal quit from Screamer will remove them cleanly. Before you start make sure there are no old ones.
Not sure what else to suggest.
Julian
The Mac Lightwave Resource Page
http://www.exch.demon.co.uk
| By ted devlin (Eblue) (12.149.3.2) on Thursday, June 20, 2002 - 02:41 pm: |
sorry for the confusion arnie, julian.
my dyslexia has apparently kicked in...
numbers 1 and 2 are reversed.
re: hard coding, yeah that didn't work at all for me, so i have cut away at the problem trying to make it as simple as possible. hence, the very simplistic version i posted today.
arnie:
some of the more interesting errors:
with the job and ack files' path's set in the LWSN launch command, even if it only points to the content directory (the default location...), and my network rendering panel points to the same path... no cpus are detected, or if they are... the support files are not found.
at some point when i was positive that:
LW at least had the right content dir,
job and ack files were working, and LWSN had no problem finding the scene file,
it could not load the scene bc it couldn't find the Objects. Needless to say Lw had no problem finding the objects, as they were all in the appropriate directories.
several times, LWSN was ignoring the "init" command because it claimed that it didn't understand it. this is when i started to suspect job and ack files and began tossing them in the trash at my leisure.
we assume LWSN is setup correctly bc LW has made a connection and issued and gotten responses to 2 commands (init and wait) then i load a scene and hit the render button.... LWSN puts this word up on the screen: "load" and then nothing happens. Nothing happens for at least 16 hours, I went home. I was terribly dissapointed in the morning.
LWSN is apparently setup correctly, and it actually renders something, but the render stops halfway through (60 frames out of 120). It doesn't report any failure, and it sits there like its running just fine. Like a madman i tear apart my scene file thinking I set it improperly, but no, it still says end frame : 120. so i try to render the same thing again, after restarting both lw and LWSN, and LWSN couldn't load the SCENE, the object files are missing.
rendering to no file at all, yeah i've seen this one before in these forums, and the gist of it is this : LWSN doesn't do any checking to see if it will save the file so if you don't set it properly in LW (check the image sequence box, give it a name, a type, and a path), it will render and then not save. But i have a new twist... i opened the scene after this occured, and it was set properly, ie: hitting f10 rendered to the file path that was set before the batch render.
now each and every one of these problem is impossible to reliably duplicate for many reasons. The biggest reason is that i was making changes in an experimental way in order to find the setup that worked, what didn't work was not what I wanted, so I can't be positive what setup I was using when these problems occurred.
as if I needed more problems.... LW itself just tanked. I've been noticing some instability since around the mac os 10.1.5 update and the LW 7.5 update. I am suspicious of a memory leak.
| By Arnie Cachelin (Arnie) (65.184.20.249) on Thursday, June 20, 2002 - 05:29 pm: |
>numbers 1 and 2 are reversed.
You don't mean you are using the old LWSN -1 protocol... that would be an error in itself.
Also, obviously the save path in the scene must match a path available to the node(s). Clean up the old ack and job files.
| By ted devlin (Eblue) (12.149.3.2) on Friday, June 21, 2002 - 11:22 am: |
>>numbers 1 and 2 are reversed.
>You don't mean you are using the old LWSN -1
>protocol... that would be an error in itself.
this is like an abbott and costello bit... ;)
uhhh... not using the -1 protocol, checking the content and network control directory Before launching screamernet.
>Also, obviously the save path in the scene must
>match a path available to the node(s). Clean up
>the old ack and job files.
yes i agree, and appreciate your thoroughness, here, but the problem usually associated with access are mostly moot in my setup, my single node is my controller, so the paths and the permissions are really easy to debug, they should all be the same. what i find striking is that screamernet is Less capable than Lightwave itself, at finding support files, in the same scene, and across time.
Theres alot i would suggest for the development of a newer network rendering protocol, but i think that that is a side issue, Batch rendering should be a feature of Lightwave, sans Screamernet.
| By Arnie Cachelin (Arnie) (65.184.20.249) on Friday, June 21, 2002 - 12:43 pm: |
It is strange that LWSN can't find the 'support files', since it is just layout without the UI.
The scene doesn't need to be loaded into layout for LWSN to handle it, naturally. Maybe one could make an lscript that loaded and rendered a series of scenes into layout.
| By ted devlin (Eblue) (12.149.3.2) on Monday, June 24, 2002 - 10:31 am: |
It is strange that LWSN can't find the 'support files', since it is just layout without the UI.
i agree with that. It is indeed strange, but...
Its not "just layout without the UI".
theres some other stuff in there that might be getting in the way. Such as SOUIX, which i believe is the command line system thats been hacked onto the top of Screamernet in order to issue commands to it. And its quite possible that the very way commands are issued, is problematic, especially in OS X which by all accounts is a very new animal, and could perhaps not work the way a "Carbon" programmer might expect, after years of Mac os development.
I think that screamernet is a very old design, and it relies too heavily on old assumptions, and old tools built upon those assumptions. I would like to encourage you, arnie, to continue with cocoa, because thats where a real kick a$$ network rendering solution will be assembled, and not because of any of the catch phrases being tossed around today, but because of its absolute compatibility with mac os X, and our lack of familiarity, and therefore lack of problems with assumptions about how it works. Network communication is necessarily a fragile thing at best, which demands compatible and robust tools that are flexible and strong enough to be easy to use.
btw: is there a unix version of Screamernet?
I would bet dollars that the port would be straightforward, and might yield some benefits, in the long run.
| By Ed Mag (Ed_M) (64.12.102.51) on Wednesday, June 26, 2002 - 11:18 pm: |
So, the question is... What part does SIOUX play in relation to SN?
--
Ed
| By ted devlin (Eblue) (12.149.3.2) on Thursday, June 27, 2002 - 09:43 am: |
ed,
if Screamernet was only lightwave without a UI, then Lightwave itself could not talk to it. So it cannot have "no UI" it has to have something bolted onto its front end so that LW can interface with it. This Proto_UI needs to be able to open, read, and write to text files, give feedback for the render, and accept commands (ala unix, or DOS). NT wisely decided to use an off the shelf product (my assumptions, don't confuse this with fact) named SOUIX, on the front end of Screamernet.
SOUIX is a flexible command line utility that works much like the DOS application in the modern Windows OS, but it does it on the mac, and did it way earlier than windows 95's release date. This tool is very useful for beginner programmers ( printF "hello world" etc... ), and in porting stuff to the mac (when it didn't have a command line of its own) that needed a command line interface.
NT did themselves a big favor if they did, in fact use SOUIX in the original implementation of Screamernet, bc it saved alot of dev time, and did a great deal of things that Screamernet needed to do that wasn't otherwise available on the mac previous to Mac os X. And Souix was designed from the ground up to be a modular component of an application.
But Souix's days are numbered, mac os X easily outstripped the capabilities of the aged command line utility, and the redundancy of Souix may be a liability. I'm not asserting that its slow, I am however saying that Souix is an unnecessary layer on the top of many other unnecessary layers, in the chain of communication in the os, for what amounts to a facesless app, and that any bug or subtle change in the timing or order of commands in any of the layers, could alter the effectiveness of Souix.
Off the top of my head....
heres what Souix must rely on to work...
souix's application level code,
carbon,
carbon support systems,
os level stuff,
the underlying unix layer.
This is all ok, but when compared to the more robust, tested, and complete command line utility that runs below the OS level of os X, one has to start wondering why NT isn't salivating over the "*nix" aspects of X.
but this is all a side issue isn't it? I advocate Cocoa development of screamernet, which sounds like its juxtaposed from *nix development of Screamernet, right? wrong. The interesting thing about Cocoa is the way it was designed. Its an open system. From inside a cocoa app one can make calls to or through any of the other programming environments, for example : Java, Carbon, C, C++, to the unix layer of the OS. So on one hand you can build a command line tool, that sits at the bottom of the os, getting prime processor time, and having little or no overhead, while on the other hand, you could build a tightly integrated flashy modular controller app, that uses all of the latest in UI and networking communication to control the low-level rendering engine. Best of both worlds.
word of caution though, its much easier to say it than to do it, and it would take either someone who is already versed in Unix, cocoa, apple networking communication concepts (very specific areas spread out all over the os), or someone who really likes to research, and a lot of time.
Personally, I don't think Screamernet is at a critical junction, NT just doesn't appear interested in the development of a kick a$$ network rendering solution, but I am very interested in seeing an active developer/user ongoing discussion/design process.
There are many hurdles ahead in such a discussion, and i have seen several interesting and clever ideas as well as outlandish and over-kill ideas. But I am of the opinion that Every idea can only add to NT's knowledge base and bag o tricks for the next revision of SN.
| By Ed Mag (Ed_M) (205.188.200.31) on Thursday, June 27, 2002 - 11:01 am: |
Ted, thanks for the info. I've always wondered what you were talking about when you mentioned Sioux. I'm still checking around for other info on it and even asked John Welch for any info or knowledge he has with it. This is the type of discussion that I aimed for; believe it or not.
[[[This is all OK, but when compared to the more robust, tested, and complete command line utility that runs below the OS level of os X, one has to start wondering why NT isn't salivating over the "*nix" aspects of X. ]]]
Cold this be because they probably don't have any knowledgeable *nix people working for them?
[[[But this is all a side issue isn't it? I advocate Cocoa development of screamernet, which sounds like its juxtaposed from *nix development of Screamernet, right? wrong. The interesting thing about Cocoa is the way it was designed. Its an open system. From inside a cocoa app one can make calls to or through any of the other programming environments, for example : Java, Carbon, C, C++, to the unix layer of the OS. So on one hand you can build a command line tool, that sits at the bottom of the os, getting prime processor time, and having little or no overhead, while on the other hand, you could build a tightly integrated flashy modular controller app, that uses all of the latest in UI and networking communication to control the low-level rendering engine. Best of both worlds. ]]]
Yes, This makes perfect sense. Add Apple's 'Rendezvous' technology and there seems to be even greater potential. I received some feedback from Dean Dauger BTW. He continues to monitor this forum.
[[[word of caution though, its much easier to say it than to do it, and it would take either someone who is already versed in Unix, cocoa, apple networking communication concepts (very specific areas spread out all over the os), or someone who really likes to research, and a lot of time. ]]]
Well, it seems that you are pretty knowledgeable. Keep in mind that John C. Welch has already offered NewTek assistance and Dean Dauger has certainly made his case. Those are the two guys I'd like to see work on this project. I think the three of you could come up with something that's far superior.
[[[But I am of the opinion that Every idea can only add to NT's knowledge base and bag o tricks for the next revision of SN. ]]]
Most definitely ;-)
--
Ed
| By John C. Welch (Jcwelch) (18.174.0.40) on Thursday, June 27, 2002 - 11:29 am: |
[Off the top of my head....
heres what Souix must rely on to work...
souix's application level code,
carbon,
carbon support systems,
os level stuff,
the underlying unix layer. ]
Incorrect...Carbon is really misunderstood by a lot of people...more like:
SIOUX Code
Carbon Frameworks
Low - level OS
Hardware
even as a BSD application, it would look like:
SIOUX code
BSD layer
low - level OS
Hardware
[This is all ok, but when compared to the more robust, tested, and complete command line utility that runs below the OS level of os X, one has to start wondering why NT isn't salivating over the "*nix" aspects of X.]
The BSD CLI doesn't run *below* the OS. It runs below Aqua. The BSD application environment and the Unix plumbing are not the same thing, in fact, you don't have to even install the BSD application environment.
[but this is all a side issue isn't it? I advocate Cocoa development of screamernet, which sounds like its juxtaposed from *nix development of Screamernet, right? wrong. The interesting thing about Cocoa is the way it was designed. Its an open system. From inside a cocoa app one can make calls to or through any of the other programming environments, for example : Java, Carbon, C, C++, to the unix layer of the OS. So on one hand you can build a command line tool, that sits at the bottom of the os, getting prime processor time, and having little or no overhead, while on the other hand, you could build a tightly integrated flashy modular controller app, that uses all of the latest in UI and networking communication to control the low-level rendering engine. Best of both worlds.]
Actually, Cocoa and mach-O carry quite a bit of overhead, and would be of no advantage to building a lightweight improved version of SN. You could write a really nice UI that was scriptable in either Cocoa or Carbon, depends on what language you prefer really. Carbon is pretty much locked to C++, Cocoa is happier with Obj-C, Java, or AppleScript. You can use C(++) in Cocoa, but it's not a really good way to do it, as C++ is a really crappy OOP language. Capability - wise, for the little interface a better SN would need, it's a tossup as to Carbon or Cocoa.
[word of caution though, its much easier to say it than to do it, and it would take either someone who is already versed in Unix, cocoa, apple networking communication concepts (very specific areas spread out all over the os), or someone who really likes to research, and a lot of time.]
THere's a network programming list, various Carbon and Cocoa lists, and I'm pretty sure that NT has a few support options as part of their developer program membership...the help is out there.
[Personally, I don't think Screamernet is at a critical junction, NT just doesn't appear interested in the development of a kick a$$ network rendering solution, but I am very interested in seeing an active developer/user ongoing discussion/design process.]
That's a shame, as the value and usefullness of distributed computing is a fact, not a theory.
john
| By ted devlin (Eblue) (12.149.3.2) on Thursday, June 27, 2002 - 11:48 am: |
two quick things:
1. launch screamernet in a mac os, and check out the "about panel" for it...
2. which dovetails nicely into the next thing, my spelling sux... its SIOUX not SOUIX, for those of you who want to look it up.
| By Ed Mag (Ed_M) (205.188.200.36) on Thursday, June 27, 2002 - 02:05 pm: |
So the conclusion (once again) is that NewTek would be wise to rebuild ScreamerNet into a really sweet distributed rendering solution that works seamlessly within Lightwave. The real question is "What is NewTek going to do about it?"
--
Ed
| By ted devlin (Eblue) (12.149.3.2) on Thursday, June 27, 2002 - 02:34 pm: |
ummmm....no,
My conclusion is... I have an interest, in weighing in, on what I want in a network rendering solution. Further, I would like to openly discuss this with other users, and developers in a civilized manner, with the hopes that, when NT is ready to focus on Network rendering, they have a rich library of ideas, inspiration, and a clear idea of what the "user" needs.
;)
I've already vented my frustration, and i was happy to share my issues with arnie. Now, i am trying to focus on the things that will make LW better. Hence, me being Off Topic ;)
| By Trey Harrell (Droog) (66.157.232.85) on Friday, July 26, 2002 - 02:26 am: |
Ok. I've FINALLY Found a solution to the ScreamerNet on OS X issue. Your mileage may vary, of course. It is, in fact, an EXTREMELY ass-backwards way of doing things, but it's fairly reliable, at least.
A little about me, I'm a freelance artist/programmer/animator, and a local Post suite paid me with my Mac expertise to get it up & running. I was also Apple certified for a while, years ago, for what it's worth.
It took me 3 days of trial and error and reading instructions online to no avail before I decided to use scientific method and make tiny tweaks for hours on end until it worked.
My reasoning behind all of this is that Newtek wouldn't ship LWSN for the Mac if it didn't at least KINDA work. The lack of documentation lead me to believe that it only KINDA works, and then only under very strict, controlled circumstances. So that's the route I'm taking with this tutorial. Some of the processes outlined below may not be necessary, but they are VERY controlled ;)
I finally got it working!
At any rate:
1. On your HOST machine (MacOS X), create a folder called "Render" at the root level of the main hard drive. In this example, I'll use "HostHD". No spaces in the name. This seems to work out slightly better overall, or maybe it's just me being paranoid with command line issues. I've been working on this long enough to get slightly schitzo, so bear with me.
To recap, you create "HostHD:Render"
2. On your HOST machine, within the Lightwave Programs folder (this example is "HostHD:Applications:LightWave 3D 7.5:Programs), duplicate your LWSN application (file -> duplicate) for each render node you plan on using, including the host (why waste cycles?). Name each copy LWSN1, LWSN2, LWSN3 and so on for each node ID. Then delete the original LWSN so you aren't tempted to click it.
3. On your HOST machine, duplicate the LWSN cmdLine file for each node. Name them "LWSN2 cmdLine" etc.
4. On your HOST machine, open each cmdline file in BBEdit, or your favorite text editor. Use the following init while changing out the "You" in the first portion to your short username, capitalized, and the number after each job and ack to match the node number. All of this has to be on one line with the exact spacing you see here:
-2 -c"HostHD:Users:You:Library:Preferences:" -d"HostHD:Renders:" "HostHD:Renders:job1" "HostHD:Renders:ack1"
**********WARNING!!!!***********
Every time you open and re-edit these files in a text editor, it will add a new line break to the end of the file. You must manually delete this each time you edit the file -- ie, delete everything in the file up until the last letter -- or LWSN will generate "ack" files with an extra space at the end, and they will stay there forever saying "init" or "waiting".
If you're troubleshooting, look in your renders directory and highlight the filenames. If there's an extra space on the end of your ACKs, you've got trouble and need to re-edit your cmdline files and get rid of it.
5. Delete any existing job and ack files from the Renders directory. Every single time you start a new job. Really. LWSN's error checking is terrible (I think non-existant actually, but "terrible" is the benefit of the doubt), and we're doing this the really, really methodical and safe way, right?
6. Move (not copy -- MOVE) all your scenes, images and objects into the renders directory. At this point, it may be helpful to temporarily rename the name of your Lightwave:Content directory or wherever you've been storing files temporarily.
**********WARNING!!!!!***********
This is the biggest headache that I found. If a scene (or object) references scenes or objects outside of your "render" path on a REMOTE machine, it'll crash. But not on the local node (odd, no?).
At this point in my life, I've just made the "renders" directory my main content directory within lightwave layout and modeller and use that folder only and religiously for everything.
You could theoretically set the "render" directory to be your content directory, but that's just a way way long path name with a lot of spaces.
7. Fire up terminal on the HOST and type this command:
sudo chmod -R 777 /Renders/
And enter your admin password. This fixes any permission issues you may have, recursively down the directory structure. You do have admin access on this account, right? ;)
8. Mount that hard drive (root level, not your user folder) over the network from each node, then navigate to the Lightwave:Programs directory and fire up the particular node's LWSN. Make sure you log in using your account name that you're running lightwave under. You can do this under both classic and OS X for render nodes under this method. Classic is faster, but chokes on really big scenes. OS X is much more stable, it seems, for render nodes.
9. On each node screen, make sure that it can't find the job yet. If it can, quit out, and delete all the job and ack files from the render directory. Then re-fire up the nodes.
10. Load your scene file into Layout, and update the paths when it asks. Be very suspicious if it doesn't ask, because the scene will probably crash.
11. Set all of your render, scene and camera options. Make sure to save your output files under the "Render" tree, and make sure that quicktime (or whatever format) options have been set.
12. Re-save your scene under the renders directory, and also do a "File --> Save all Objects" just to be on the safe side.
13. Open the network rendering interface, and click "screamer init"
14. If the nodes aren't recognized, check their LWSNx files and LWSNx cmdLine files to make sure everything's ok. Also make sure that each machine has a unique id# for both the LWSN file and LWSN cmdLine file. Post-it notes with the number on the monitor can help immensely -- trust me!
15. Add your scene to the list.
16. Click "Screamer Render"
17. Cross fingers, and go grab a beer. It'll go faster next time.
18. If it doesn't work, go over each step again from the beginning, and don't skip ANYTHING. Particularly if you're inclined to barrage me with email help requests. Try it a few times, first ;)
Hope this helps,
Trey Harrell
trey@fishleg.com
| By js33 (Js33) (12.237.176.188) on Friday, July 26, 2002 - 07:28 am: |
Hi Trey,
Wow it looks like you put alot of work into that.
Why is it so hard to get things like this working on a Mac. It is so easy to do it on a pc.
Anyway is there a way to have a pc as your control machine and a Mac as a node?
That will be my challange soon unless of course you already worked it out.
I guess it is easier on the pc because it has drive mapping which is what Screamernet was designed around.
I guess that would be like an alias on the Mac.
You simply map your C drive (or whatever drive lightwave is installed on) as the Z drive.
Then load your scenes from that drive so all the paths are mapped to z:.
Change the paths in your config files to point to z instead of c.
Create a bat file for each render node and away you go. Takes about 5 minutes on a pc.
It would seem like a Unix command line sequence would be easy to do as well.
Cheers,
JS
| By ted devlin (Eblue) (12.149.3.2) on Friday, July 26, 2002 - 12:01 pm: |
JS,
yeah, that sounds easy.
look, the latest incarnation of screamernet for PC is Highly documented, tested, and predictable. the mac version of the same product is not. Trey has nicely written everything he did to get this house of cards to stay up.
Why is it that difficult? Well you hit on one of the themes. Screamernet is a Pc program, it was written to work with the Windows OS, and it was shoehorned one way or another to mac os 8, and now, with os X there are monstrous differences in the OS that directly affect how Screamernet Can work.
lets see... os X is now a Multi user system, unlike both windows (in the way multi-user is implemented) and the earlier mac os, to a point that file permissions has now become a very important thing, its not a set it and forget it thing anymore. Screamernet can easily choke on these issues.
What else?
Well networking, is now done by an entirely new engine so-to-speak. the networking has much more in common with unix than it does with os 9. any little thing that screamernet relied upon in os 9 and below, could quite possibly be broken.
in addition to all of that, screamernet is now at a higher level in the operating system. That means that there are more pieces of software that get priority over screamernet. This is due to the fact that screamernet is a Carbon application, and not a cocoa application or unix tool (which would be ideal).
add to all of the above, that screamernet was never really finished, documented, tested, or proven to work, in os 9, and you wind up with many questions, and almost no solutions. screamernet is supposed to be basically Lightwave without an interface, but I have seen several instances where Screamernet cannot render the same files that Lightwave can, on a PC network. Some issues include:
image sequences and quicktime movies in textures, ray traced transparency with refraction, large image files (in excess of 4 megs). All of these issues cropped up on a small PC rendering network.
I'm interested in the extra spaces remark, i'll be checking into that, but i do feel that Trey went a little over-board with his networking/permissions setup. But, hey if it works then i guess he did just enough.
re: pc controller with mac nodes, about 2-3 years ago, i found an article about it, and although it was very confusing, it stated that it is workable. The issues involved were...
1. sharing resources to the mac (s)
2. you need to generate new preference files from a mac for a mac (which means you need mac LW to do this, in addition to all of your 3rd party plug-ins!!)
3. you need to make sure you understand the protocols that macs use... one example: mac screamernet substitues : for / in a path
4. Lightwave has a little gotcha when opening a scene file cross platform... Mac LW saves the scene with mac line endings, PCs cannot read these line endings, and choke on the file. I don't think its an issue with rendering, but its something to note. BBedit is great for fixing this problem.
-good luck
ted
| By js33 (Js33) (12.237.176.188) on Friday, July 26, 2002 - 06:14 pm: |
Hi Ted,
I was so used to doing SN on a pc and I was always surprised when I saw Mac users were having such a hard time with it.
Your info sheds some light on the issues.
The fact that it was developed for pcs is not quite accurate as it orginally was designed on the Amiga. But I'm sure when the PC version came out it was rewritten to work with the PC.
I'm still trying to work through the Mac networking schemes and I can see where it is troublesome.
Maybe Rendevous in OSX 10.2 will make SN setups easier?
I'm looking for a good reason to upgrade.
Cheers,
JS
| By ted devlin (Eblue) (12.149.3.2) on Monday, July 29, 2002 - 08:16 am: |
js,
SN setups can only be easier if...
SN is re-written to take advantage of the many, many new and easy to use features of mac os X.
which is the major gripe about screamernet isn't it? On the mac it has always been very difficult to use, because it was never re-written with the mac os in mind.
if you want a good reason to upgrade, it is quartz Extreme. This is not only the most clever way of getting hardware acceleration of graphics for the os that i have ever seen (a feat that took 12 years for the original mac os, and still is somewhat lacking in the pc world)... but it also speeds up openGL, which LW relies on... Heavily. the iapps are cool, and i will use the calendar to some extent, but I see the new kernel, and quartz extreme as the big winners here. well worth the price of admission.
what about Rendezvous? Boy wouldn't that be nice, if screamernet could configure itself? But they don't need rendezvous for that, all it takes is a much more careful look at how networks work, and then a complete re-write of screamernet. Which I can't believe will happen any time soon. Rendezvous isn't really a good match to screamernet, simply because it doesn't make SN any easier. it replaces appletalk IP, and still leaves you with all of the config problems inherent in SN's design.
I'm hoping that the linux port of SN makes its way to mac os X. X has a real command line, its time to free up some of the superfluous complexity in SN, as a stopgap, to the next major revision. I'm sure Apple would be very interested in helping with that port.
have a nice day,
ted
| By Trey Harrell (Droog) (66.157.232.85) on Monday, July 29, 2002 - 12:19 pm: |
I did go a bit overboard on the permissions setup -- but that was kinda the point, wasn't it?
There are literally hundreds of "gotchas" on Mac screamernet. A million ways you can get it up wrong, or reasons for it to crash, etc.
For example, even with all my caviats in the message above, sometimes LW won't update texture paths -- then it'll render for hours with no visual feedback and you'll be stuck with 10 (the low side) hours of flat renders.
As I said before, I'm a freelancer. I'm not strictly a Lightwave guy -- although I know my way around it alright (better now than before I got this gig, that's for sure!) -- I'm much more of a Cinema4D user (Lightwave only for freelance work at a post shop or two -- same for Maya).
Newtek should take a long, hard look at the way the network rendering works in C4D (which is getting increasingly more aimed at the "Pro" market). It's slick as all-get-out and the standard I judge everything else by.
The "server" can be any machine -- and it's an actual server application that operates as a standard Web server.
You log in to the Web server and upload your project files via a web-based form, and click render.
Each job can have multiple priorities, etc, and rendering between Mac OS X, Win, and MacOS 9 hosts is seamless (as long as hair, particles and dynamics are baked ahead of time -- but realistically you really need to do this even between G3 and G4 processors).
Each render node looks out over TCP/IP via a config file to find the server.
Render nodes (and even the server) can be shut down and started back up at a whim, and they automatically resume when they come back up.
You can also see the progress of each machine via the server, and download result files from anywhere -- while the rendering is in progress.
It's possible to use every DSL and Cable-connected friend on Earth to be a C4D render node as it uses TCP and is easy to set up -- it also runs as a background service and is smart enough to give priority to the user instead of the job when the user starts utilizing the CPU.
At any rate, to me, that's the gold standard to judge network rendering.
* Doesn't require the server machine to be tied up with a modal dialog -- you can keep working after you submit the job
* Client machines can come and go as they please
* Immediate feedback if files are missing
* Immediate feedback if floating point functions aren't baked
* TCP/IP capable rendering
* Status can be checked from any machine
* Thumbnails of renders in progress on each node are available on each machine
* If the server goes down, it'll relaunch and pick up where it left off
--Trey
| By js33 (Js33) (12.237.176.188) on Monday, July 29, 2002 - 02:57 pm: |
Hi Trey,
I've always thought the TCP rendering in C4D sounds interesting but how can it deal with large image maps over the Net if people have dailup connections? I mean sometimes the image maps in a scene can exceed 100 megs or more. Wouldn't each node have to download the entire scene to be able to render anything?
Cheers,
JS
| By dann stubbs (Dann_Stubbs) (65.35.44.212) on Monday, July 29, 2002 - 04:46 pm: |
well in most situations you don't make your machine the server and thousands of other computers across the world your render clients - unless you know for a fact that they all are on fast lines - then it technically would work fine. it would work over a dial up just slow - and you would have to adjust the timeout to account for slow dial up response.
you have to manually set the clients to point to the server - so you could easily do this, say, if you and your friends across the country/world want to - and you give them the ip address/login name/password of the render server.
normally though you can log into a remote server and upload your files to it, then it doles out the render to it's local clients who render it - then return their results to the host server - which you can then log back into and download your rendered frames.
...and if someone is actually working with 100mb source files on a project and cannot justify the small cost of a line other then a dial up - well that is another issue altogether. not really cinema's fault...
http://www.renderking.com
go here, look at the "demo" walk through and see how it all works. smooth and easy...
dann
| By js33 (Js33) (12.237.176.188) on Monday, July 29, 2002 - 07:00 pm: |
Hey Dann,
The renderking site looks impressive. Now if there were only something like that for LW users.
Cheers,
JS
| By dann stubbs (Dann_Stubbs) (204.128.192.72) on Tuesday, July 30, 2002 - 07:08 am: |
i've considered LW, but right now i'm looking into the "user controlled" aspect of it - since i think that is what really makes it valuable.
i think i'm more inclined to add maya at the moment...
but if people email and i get enough feedback i will focus on those priorities
dann
ww.renderking.com
| By ted devlin (Eblue) (12.149.3.2) on Tuesday, July 30, 2002 - 08:07 am: |
"I did go a bit overboard on the permissions setup -- but that was kinda the point, wasn't it?"
yeah.
and let me be the one to tell you, experience does not make Screamernet any easier.
I have been very clear in these forums about the apparent vacuum, when it comes to network/batch rendering. And the impressions i get from the Newtek people who frequent this site, is that Newtek doesn't get network rendering. Newtek doesn't get Mac os X. Newtek doesn't get the idea that the user creates demand, not Newtek.
Now that sounds a bit more harsh than i intended, but its fairly accurate.
Time and time again, my ideas have been shot down as being unreasonable, or technically difficult. But frankly I Never intended to do the leg-work for newtek, I was printing up a list of the features I want in a Network Rendering engine. (just search for eblue, screamernet or my original login name... ted) Nobody at newtek seems to feel that Screamernet is a lame horse. Screamernet = they don't get network rendering. In their minds, it works (which i disagree with) so why waste valuable resources re-inventing it? They don't get that the user creates demand. And I have been appalled at some of the "less than knowledgeable" statements about the state of software technology in mac os X. Lack of understanding of the tools != poor tools. Newtek doesn't get Mac os X, and its all a shame.
I hate to admit that any one feature of c4d is superior to any feature in LW, and i have fought real hard to see that Newtek is not at a loss of ideas, or out of touch with the level of user demand. I wish I could say that i was confident that newtek listens, but in this instance I have to say that I feel i have wasted my time and energy.
Trey, i appreciate the work you did and i hope the system continues to work for you. Thankyou for sharing your ideas and comments.
peace,
ted
| By John C. Welch (Jcwelch) (18.174.0.40) on Wednesday, July 31, 2002 - 09:06 pm: |
actually, Screamernet isn't a network renderer at all. It's a local app that works on local paths. They happen to be able to work across the network at a user level. But doing local reads and writes, and hoping the network doesn't go down so your paths don't get pooched isn't a networked renderer.
john
| By ted devlin (Eblue) (12.149.3.2) on Thursday, August 01, 2002 - 10:41 am: |
good point,
not sure if that is good or bad, but it is a clear distinction. I guess since it isn't a network renderer, I am expecting too much from it (and now wondering what good it serves, its almost completely redundant with LW itself).
maybe i should put a feature request in for a Network Renderer?
| By Ed Mag (Ed_M) (205.188.209.103) on Thursday, August 01, 2002 - 12:34 pm: |
[[[maybe i should put a feature request in for a Network Renderer? ]]]
That is exactly what Dean Dauger wanted to help NewTek with -- only it would be more than that. I wonder if Dean is still monitoring these boards.
--
Ed
| By Ladd Ehlinger (Lehlinger) (206.166.224.226) on Tuesday, February 11, 2003 - 06:37 pm: |
Well while you guys are busy writing screamernet controllers and network controlers, we've already written one that you can use over the internet.
We've got more than 200 computers hooked up to it, so if you get tired of waiting you can always use us 24 hours a day, seven days a week.
http://www.respower.com