Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Graphics Software Hardware Technology

Building a Render Farm? 75

Posted by Cliff from the a-task-for-that-beowulf-cluster-in-the-basement dept.
Dark Bard asks: "What is the best configuration for a rendering machine. Given the variety of chips and components what are the best options balancing cost verses speed. I've been running Lightwave and plan to shift soon to Maya. AMD chips seem to be rated as a bit faster for rendering and they cost less, as well. Given the number of types of RAM available, what are the advantages of each verses cost? Should ECC be considered? What about motherboards? Integrated video would be ideal but it would have to be adequate to run the software. Is there any advantage to running the new 64 bit processors? Should you consider dual chips? What about operating system? Lightwave won't run on Linux but Maya will. How well do the major operating systems compare when used for this purpose?"
This discussion has been archived. No new comments can be posted.

Building a Render Farm? More

Building a Render Farm?

Comments Filter:

  • Reindeer Farm (Score:5, Funny)

    by MountainLogic ( 92466 ) on Wednesday December 17, 2003 @09:03PM (#7749969) Homepage
    What a great seasonal question. The most important thing in a Reindeer Farm is plenty of snow.

    Oh, wait. Never mind.

    • Re:Reindeer Farm (Score:2, Funny)

      by {8_8} ( 31689 )
      I imagine the most important thing in a Reindeer Farm would be the reindeer, followed by reindeer food. http://www.deerfarmer.com/ appears to have reindeer farming information, but IANARF so I have no idea how accurate the information is.

      Um, something on-topic. Correct me if I'm wrong, but isn't a render farm essentially a cluster of machines for distributed rendering? If so, then why would the video card for each node matter? Hell, the original article asks for advice on "a rendering machine", not a r
    • One thing to watch out for is reindeer with red noses. They can be trouble makers.

  • now or later (Score:5, Interesting)

    by aminorex ( 141494 ) on Wednesday December 17, 2003 @09:15PM (#7750013) Homepage Journal
    If Maya came in an amd64 native linux binary,
    it would kick some serious booty, but assuming
    that you need your pipeline filling up NOW
    rather than later, go for 4-way Athlon MPs
    with all the ECC DDR you can cram into them.
    More than 4-way, and you're paying premium
    prices for the chipsets. Less than 4-way,
    and you're wasting cycles that could be
    amortized over wait states. ECC is de rigeur
    just because you don't want to be chasing
    down defective dimms all the live long day.
    Similarly, I can't see any reason for paying
    the 10% performance tax of Windows 2000 Pro
    (the best of the Windows lot for SMP use)
    or suffering its 2-way limitations, unless
    theres some Lightwave feature that is
    critical to your operation.
    • Just out of curiosity: does Maya scale?
      • Sure it does. It's also excellent at rotating, translating, and (I'm sure) shearing. Plus, all of these transforms can be anmimated over time. ;)
      • If you are asking does it do well on many processors, the answer is yes. Maya's renderer was written with the large SGI boxes in mind, working many many procs. It renders in regions, where each proc gets a region, and the regions are sized based on a guess at the complexity, so each region should take the same amount of time.

        A few years ago, the linux port was a little unstable with threaded rendering, but since 3.x it has been good.

        -Tim
        • I was just thinking that memory bandwidth performance is pretty poor in the x86 SMP world, so if rendering is memory bandwidth limited that might be a problem. Memory bandwidth is less of an issue on the O2k/O3k style machines since there tends to be more of it. :) OTHO, if Maya-style rendering is compute-bound, then I figure it ought to scale OK.
    • First, if you could buy a 4 way Athlon MP it would not be as fast as a 4 way amd64 based system becauge the Athlon MPs do not have nearly as good a frontside bus as the amd64. Just get the amd64 system and run it in 32 bit mode. It will still be faster, for most things, than any other x86 system on the planet.
    • the premium on 4 way systems is rediculous.

      i built my dual 2500 barton system for under $400. you couldnt buy one processor socket on a 4 way board for that price.

  • Dear Slashdot... do my work for me please... (Score:3, Insightful)

    by foooo ( 634898 ) on Wednesday December 17, 2003 @09:27PM (#7750082) Journal
    At times like this it's hard to resist kharma whoring... so I won't.

    Dear Slashdot,
    Please do my research for me. I can't possibly use google and look up the 309830983 gazillion studies on cluster/render farm configurations.
    I won't/can't give you any specific information related to budget, my personal experience with hardware, the team to be working on the project (it could be just me... or 500 people) and the importance of data integrity (if I lose a week of work it might end my life... or I might not care).

    -clueless reader

    Dear Clueless,
    Well, if your budget is a billion dollars why not just buy Pixar? They have the whole render farm thing figured out.

    If your budget is any thing less than that try looking for open source, GNU, freeware, shareware, free for non-commercial use renderfarmy stuff and run it on AMD based Linux boxes.

    Hard drives aren't so important on the individual machines. Get a decent raid on a server machine that will support the number of computers in the render farm. Use 100-1000 mbit ethernet (unless you want to spend a fortune). Get at least 256 mb of ram in each box rendering is memory intensive.

    If noise is a concern, build a seperate room or building even.. cause the more computers you have the more it's going to start sounding like a server room and less like a place hospitible to human life.

    Take a look at learning Blender instead (or in addition to) Maya. Learning to use special rendering software like BMRT would also be cool. BMRT, which is free for non-commercial use, churns out very good images but is very slow. Renderman is the most popular and the most expensive. It's fast too but there are some things it can't do such as global illumination, which BMRT can do. (I'm not sure about the new release of Renderman, though.) There's also Entropy, a fast BMRT, but not free.

    All software I've mentioned works for Linux.
    For more resources, check out these links:

    http://www.blender3d.com
    http://www.aliaswavefr ont.com
    http://www.linux.org/apps/all/Graphics/3D _Modellin g.html
    http://www.linuxmovies.org

    By the way it took me 5 minutes to find this on google and I know jack shit about animation... my only limited experience was fooling around with good 'ol POV-RAY.

    For god sakes! If your'e going to ask a bunch of very smart people questions that demand detailed answers... provide detail on your questions.

    It makes me if moderators have any standards at all for ask slashdot items. (Why do I ask when I already know the answer!!)

    ~foooo

    • Re:Dear Slashdot... do my work for me please... (Score:5, Insightful)

      by Atzanteol ( 99067 ) on Wednesday December 17, 2003 @09:59PM (#7750230) Homepage
      Yes ladies and Gentleman, you too can be a pretentious slashdot asshole! All you need to do is:

      1) Bitch about "easy" ask-slashdot questions. After all, you *do* know everything don't you?
      2) Answer the "easy" question with vague mumblings about "google", "open source", and a few links to stuff that won't answer the question (but it looks like you really know your stuff if you do).
      3) Bitch (there's a lot of that if you're going to be pretentious) about the "stupid" moderators and editors. They are, afterall, morons aren't they?

      Yessir, just follow these three simple rules, and you too will find yourself modded +5 insightful whereas all your detractors will be -1 troll!

      • Actually, parent said: ...knows nothing about animation ...specific packages and products

        You are kinda off-base in your criticism. Attitude aside, parent had a good point.
        • But the questioner wasn't asking about *software* so much as experience with hardware. That's the *point* of asking questions. To get others experiences with things. Sure, I can google for what runs under Linux, but which is the best way?

          • Without considering budget issues one can't even begin to discuss what the best hardware solution is.

            Show me any software program and give me a budget. I will probably be able to analyze the performance needs of the application and fit *something* into budget. But unless I have some money number I'm operating completely in the dark.

            If the question was about hardware then budget is the number one concern. Until that question is answered any advice given is without context and therefore useless.

            I'm not jus
    • A few corrections...

      Hard drives are important. You never ever want to render to NFS. Bad things happen. Trust me.
      Also, its best if the files are local that its rendering. So having a 20gb scsi drive speeds things up... cache the scene file local, render local, copy the result back.

      And 256 mb ram... hmm.. try 4bg of ram. I have hit the 2gb limit for renders many times, and if you want to have two renders going at the same time, you need that extra memory.

      Software wise, as for 3rd party tools, renderman
      • I agree in many configurations good harddrives would be important, but this person isn't talking about a single machine rendering op. He wants some sort of render "farm" implying multiple machines. In which case my first reccomendation (to save money) is to ditch as much cluster "client" storage hardware as possible, after all the cluster clients don't exist to store, they exist to render. Rendering images to a ram drive might be a good thing, or get a small fast hard drive for the images and OS, rememberin
        • Maya has a real cheesey remote render tool. Its not really worth the time.

          I built a 500 node/1000 proc render farm. Maya is a beefy application. We had scene files that were easiy 500mb. You can not chop up a scene file like that, it all needs to be loaded so that lighting can be done correctly.

          Rendering to ram doesn't make much sense. You need all of that memory for the OS and the application.

          A local hard drive makes a world of difference. I have seen night and day differences between rendering off o

    • Re:Dear Slashdot... do my work for me please... (Score:4, Informative)

      by KewlPC ( 245768 ) on Thursday December 18, 2003 @02:33AM (#7751837) Homepage Journal
      Nope nope nope:

      I wouldn't consider anything less than 512MB of RAM. Get as much RAM as you can afford, but spread the wealth; each machine on the renderfarm should have the same amount.

      As others have pointed out, being able to cache the files locally is important. The individual rendering machines' disks need not be enormous; an 18GB SCSI disk would suffice. Each render node should have a 100Mbit ethernet card, and all should connect to a gigabit switch, which then connects to your file server and rendering job server.

      As for actual software, Blender is the last thing he wants if he's trying to upgrade from Lightwave. Maya's animation, modelling, and dynamics are much better than Lightwave, but the stock Maya software renderer is worse.

      When it comes to rendering software, there are a few options. When it comes to RenderMan-compliant renderers, there's BMRT, Entropy, 3Delight, RenderDotC, and, of course, Pixar's own PhotoRealistic RenderMan which, as of version 11, supports raytracing and global illumination. The problem with these is that Maya's built-in RenderMan exporter sucks, so you'll need a 3rd party one (Liquid is a good, open-source one that was written by a Weta employee and used on the Lord of the Rings trilogy).

      However, Exluna, the company that made Entropy and owned the rights to BMRT, is no more. They were sued by Pixar on some bogus patent issue, and ended up getting bought by nVidia, who promptly discontinued development of Entropy. BMRT is no longer officially available.

      3Delight seems to be fairly fast, but has limited raytracing abilities and no global illumination. It's available as a free download from 3delight.com [3delight.com], but only for private and limited-commercial use.

      However, Maya versions 4.5 and up ship with mentalRay, the same ray-tracing global illumination renderer that comes with SoftImage, and unless I'm mistaken Alias has been kind enough to allow unlimited render nodes. This means you can buy one copy of Maya for doing your modelling and animation, and install Maya's software renderer or mentalRay on your renderfarm.

      Also, unless you plan on using Maya's hardware renderer on the renderfarm (not really all that necessary; it's fast enough that you can do it on your workstation), not a single machine in your render farm needs a video card. Once they're set up and configured, there's no need for you to access them directly. Maya can do rendering without a GUI, and RenderMan renderers don't have GUIs.
    • "Dear Slashdot, Please do my research for me. I can't possibly use google and look up the 309830983 gazillion studies on cluster/render farm configurations."

      Don't be an asshole. You can go read a gazillion Google pages on setting up a network farm, but what this guy really wants is to hear from somebody who's gone through the trial and error and can offer their sage advice.

      Google isn't everything, nor does it give you the right to be an ass.

      • Don't be an asshole. You can go read a gazillion Google pages on setting up a network farm, but what this guy really wants is to hear from somebody who's gone through the trial and error and can offer their sage advice.

        Google isn't everything, nor does it give you the right to be an ass.

        Pfft.

        If you want expert advice from experienced people, go lurk in the appropriate mailing lists or Usenet groups. Once you get up to speed, you can ask specific questions and get help.

        If you "Ask Slashdot" a hop

    • Well said. There ought to be a higher threshold for "ask slashdot". Maybe something like the kuro5hin queue could send these questioners back to the drawing board before wasting everyone's time. The thing is, it's an interesting question (it usually is) but without some basic facts we're just blowing smoke. On second thought, most slashdotters would be blowing smoke anyway.

      Too bad your comment was modded as a troll.

  • Bang for bucks (Score:5, Informative)

    by quinkin ( 601839 ) on Wednesday December 17, 2003 @09:34PM (#7750113)
    64 bit still isn't cost effective in terms of bang-for-bucks unless you have access to 64 bit binaries.

    Even if 64 bit binaries are available you will probably get greater performance at a lower cost by using "cheap as chips"(sic) chips in SMP configurations.

    Future proofing is another issue however. Many clustering technologies rely upon a common denominator. For instance with OpenMOSIX running on varied hardware, your code must be compiled for the lowest common denominator. So if you have 20 P4's and one P2, you will only be able to run software compiled for P2 on the cluster (at least without errors).

    YMMV - It's been a while. :P

    Q.

  • wtf?! (Score:4, Insightful)

    by Beatbyte ( 163694 ) on Wednesday December 17, 2003 @09:38PM (#7750133) Homepage
    Should ECC be considered?

    If you're in charge of building a rendering farm, your company is in trouble. If you haven't even figured out that the RAM MUST be ECC, you shouldn't be even aloud near the farm.
    • This is where I show my ignorance and not for the first time, I might add.

      ECC is just error correcting ram is it not.

      Rendering is adding light to an image that is going to be displayed for a small part of one second.

      Most ram is pretty good only one or two errors per year as I recall.

      My question is why is ECC so gosh darn important if the chances of an error is minimal and the consequences of the error is neglegable?

      I always speak a loud near the farm when I'm allowed near the farm.

      • wtf?!-Shag the error monster. (Score:1, Interesting)

        by Anonymous Coward
        "Rendering is adding light to an image that is going to be displayed for a small part of one second."

        Rendering is math. Think error accumulation.
      • mandatory. for stability and quality of the rendering.
      • My question is why is ECC so gosh darn important if the chances of an error is minimal and the consequences of the error is neglegable?

        Because the negligable cost increase for ECC RAM is more economically digestable then having to delay a project because umpteen-thousand frames of your movie all have an error in them and you have to reschedule a week's worth of rendering time and hope it all renders out correctly on the second attempt.

        • Yeah, but if you go with non-ECC RAM, then the performance increase could allow you to re-render the frame or two that was damaged due to something wrong with the RAM. :) ECC is a performance penalty, and a memory error is not likely to cause anything noticable in an animation.

          However, if data integrety is *the* most important factor, the DIMMs should be ECC *and* should be registered. As long as the memory's buffered, may as well take full advantage of the buffering delay, eh?

          While I'm on the subject,
          • But the frame isn't damaged it is just wrong. So unless you have someone go back and examine every frame and every calc you wont know there was an error until you start to view things.

            Other advice: Dont spend any money on soundcards, video cards etc. In fact if ytou can just run them headless. All the boxes need is a nic, boot drive, ram, PSU and mobo/proc. I built a small farm for a company in 2001 we used C4d and so i went with a bunch of commodity vanilla athlons. Worked great. Today I would use xserves
            • Someone needs to check out the frames regardless of how super-accurate everything else in the system is.

              This is largely moot, as most boards will require registered DDR in order to use pile of memory, and therefore it'd be foolish to not go ahead and include ECC at the same time. :)
          • If you're not worried about doing something perfectly correct the FIRST time, then your product is going to reflect that.

            Even with ECC, you will render something and want to change it. TRUST ME. You don't want to render something 4 times because of no ECC, find out you have to change something (artistic, not flawed influence on this decision), then render it another 8-12 times before its final.

            TIME IS MONEY.
          • On that note, what exactly is registered ram? Yes, I buy it for my dual athlon system because the specs on the mobo tell me to, but I'm wondering exactly what it means when it says "registered".

            • Re: registered ram (Score:3, Informative)

              by cloudmaster ( 10662 )
              It's essentially a buffer that boosts the clock signal so that the edges of the clock appear more sharply defined to the memory (the clock gets weak when it's directly driving a bunch of memory modules). The buffer tries to isolate the motherboard chipset from the pile of chips on a large DIMM, which is why lots of motherboards require registered DIMMs in order to use lots of memory. That buffer also delays data transfer by one clock cycle.
    • I disagree.
      I think he should buy it. *rimshot*
    • You know, I don't know if I have ever seen memory cause a problem. But if I had, I don't know if I would have figured out that was what it was, and I have done some extremely heavy renders before.

      But at the current cost structure of ECC vs non, it is a good idea to be safe.

      -Tim
    • I don't understand why ECC memory is worth more than ordinary Parity memory in this case. ECC memory is slower (CAS2 behaves as CAS3) and simply parity checking is enough to inform you in the event you have an error, at which point one part of the batch will have to be discarded, but that's the whole point of clusters, they're redundant and job-oriented. If one job fails, you just reprocess it somewhere else. A node causing too many errors gets rotated out. If this were about a single machine to do renderi
    • If you haven't even figured out that the RAM MUST be ECC, you shouldn't be even aloud near the farm.

      Why? Will he wake up the animals?

      I agree with your sentiment, but maybe you shouldn't be allowed to post on Slashdot until you've done your research (in a third grade grammar text).

  • RenderDrive? (Score:2, Informative)

    by jhubbard ( 4916 )

    Have you looked at RenderDrive [art.co.uk]? The company that my wife works bought one of these recently. The guy that uses it loves it. It does the job much quicker.

    It's a general pupose computer that has special hardware that is used to do the rendering. The OS is linux. In order to get it on the newtork you setup a floppy with your config file. There's a plug-in for your system that is used to do the rendering on he computer.

    • When I looked at them, they seemed a tad pricey for me.

      It has been over a year though, they may be more competitive. I also don't know if it scaled well.

      -Tim
  • Go and use full scale professional tools, like Houdini (http://www.sidefx.com/), that offer free linux versions as well (small watermark on the output), and export to Renderman and use existing Renderman cluster stuff (BlueMoon Render Tools IIRC).

  • My ideas (Score:4, Interesting)

    by FueledByRamen ( 581784 ) * <sabretooth@gmail.com> on Wednesday December 17, 2003 @11:31PM (#7750758)
    I just built up a workstation on which to run Maya 5, and have been using the hell out of it for a week or two, so here's what I have to say about Maya render stations (which are basically workstations minus the Quadro or FireGL card):

    Motherboard: Because Maya's renderer is SMP-enabled, you'll probably want to get dual-processor boxes. I suggest AMD machines based on cost - they're a hell of a lot cheaper than their Intel counterparts. A good motherboard is the Asus A7M266-D (760 MPX chipset) - it supports upto 3.5 GB of RAM, and has been rock-solid stable under Linux for me, but it doesn't have onboard video or networking. A good board with onboard video/LAN/SCSI/etc is the Tyan S2466 dual-Athlon board. Keep in mind, though, that these things suck a LOT of power; a good (think Antec) 400 watt (or better) PS is a MUST, or you're going to fry it. I had a Tyan S2460 (2466 minus SCSI, NIC, and onboard video) that fried an off-brand 400 watt power supply because it was sucking so much juice. Don't worry about the specs of the onboard video, because Maya's batch renderer doesn't even bother setting up an OpenGL context; it's completely software rendering from the command line.

    Processors: Currently, the Athlon MP 2600+ is at a good price/performance point (approx $150 ea, and the next one up is $200 ea). I'd load every box with a pair of those. If you're looking to save some money and don't mind furiously voiding the warranty on each and every CPU you buy (like me), you can grab some conductive paint, a paintbrush, and a bit of tape, and convert Athlon XP processors into MP-capable processors simply by connecting one of the bridges on the top of the CPU. [cluboc.net] I did that to a pair of XP2000+ processors, and it worked great; they're still churning away together just fine after almost a year. The price difference is about $70 - if it's worth the savings to you, go ahead and try it. If the chip won't run in SMP mode (rare), you can always stick it into a cheap motherboard and make a desktop workstation for your favorite manager.

    Memory: Maya is HEAVY on RAM usage. If you're not planning on having a disk in every machine with plenty of swap space (for those larger scenes), I'd go with at least 1.5 GB (and probably 2 GB) of registered DDR RAM. You should be able to get away with only putting in 1 GB per machine if you have swap space. If you can afford it, spend the extra for ECC memory, because it's nice not to have to worry about memory errors. I did a quick test render (Maya software, 640x480, draft quality) of a 350,000-poly object I'm currently working on, and its average memory usage was right around 600 MB (peak arena size 1186.25 MB, as reported by the renderer). Don't underestimate the amount of RAM that you'll need! My workstation has 1.5 GB of RAM, and it still hits swap.

    If you're not booting over the network, I'd throw a fast 18 GB drive in every machine. Make a swap partition of at least 2 GB, and install the OS (I prefer Debian stable, use whatever you want) on the rest of it. You shouldn't have to go overboard on disk; a 7200 RPM IDE drive will be more than adequate.

    Networking: Depending on how your scene data is distributed (central fileserver? every node gets a copy beforehand?), I'd go with 100mb switched or full GigE. It basically depends on whether or not you're willing to pay the premium for the faster interconnect. If you put GigE cards in all of the nodes (which doesn't cost much more than putting a good 100mbit card in anyway - I recommend the Netgear GA302 and GA604 gigabit cards), you can always replace the switch if you find things are too slow.

    Power and cooling - you'll need plenty of both. One Athlon puts of quite a bit of heat, but pack two into a small box and put 20 of them in a rack (assuming 2U), and you're talking about serious overheating possibilities. You're going to need one hell of an air-conditioning system. If you've already got a datacenter set up, then y
    • I say spend the money on ram instead of more machines. Hitting swap kills a job.

      I have maxed out the 2gb limit many many times. Had it been in swap it would have been much worse.

      I also like to cache scenes local as well as render local, so a fast local drive can make a difference.

      In some of the servers we had 2 20 gb scsi that were striped.

      Another good trick is if you have 2 drives, put swap on both of them at equal priority. That can lower some bottle necks as well.

      -Tim

  • IAARF (Score:4, Informative)

    by tolldog ( 1571 ) on Thursday December 18, 2003 @12:54AM (#7751333) Homepage Journal
    I am a render farmer... and this is what I have gathered.

    If you are doing single frames, get good systems.
    If you are doing animation, get many systems.

    You need a scheduler or batch queueing system.

    I suggest building one off of LSF like I have in the past and it is what I use now -or- get a nice prebuilt one like what pipelinefx has. This is extremely important. Without a good job scheduler, your cpu utilization will be less than optimal and it will cause you to get more machines than needed.

    I have worked both with inhouse and 3rd party renderers. Maya doesn't do that bad of job, and the license for rendering is free. Big plus.
    Inhouse is great too, but if you don't have a good sized company, you probably won't have one and probably wouldn't be asking this question.

    As for the machine. Most products are only speced for RedHat and for only certain releases. This is important when suport becomes an issue, and it will, when things don't work for a shot. I suggest a dual proc Pentium 4. I do not know if AMD's chips have been blessed by the vendors or not. I know when last I looked it was being investigated. Go for a dual system, even if you don't have a mutli-threaded renderer. Also max out the system ram at 4gb.

    As for hardware vendors, I have used VA-Linux, HP, Compaq and SGI linux boxes as well as white-boxed. Hardware support is a big deal when you are a small shop. Go with a name brand unless you want to buy a ton of hot spares.

    Storage is a big deal too. You obviously need a place to put the images, but you also need a server beefy enough to serve up a couple hundred mb to several boxes at the same time. When you get 500+ boxes, it gets to be an even bigger deal.

    Other administration software i found usefull...
    SystemImager and gsh ( a distributed shell ) they allowed me to manage the 500 boxes as well as develop code and debug renders... I can not imagine what it would have been like without it.

    -Tim
    • I suggest a dual proc Pentium 4.


      Saying stupid things like this really ruins credibility; P4s are not SMPable, Xeons are. This is the 3rd time in as many days I've seen somebody talk about dual P4 systems.
      • Or... Some people could be talking about the P4 version of the Xeon chips instead of the PIII Xeons.

        If somebody is doing hardware specs they should be aware of the P4 vs Xeon and what is SMP capable.

        Its like calling a G5 a ppc970. In context people know what you mean.

        -Tim
  • Maya render farms are notoriously hard to manage on Intel/AMD/windoze/linux hardware. You should check out Apple's XServes and their new QMaster software, it can manage huge render queues for Maya and Shake. Nobody uses just Maya on a render farm, you need compositing software too, like Shake. You can't beat Qmastered Xserves for a render farm. And Shake comes with unlimited licenses for OS X (but not for linux). The cost savings in licenses alone will astonish you. Even their XServe RAID products are less
    • I don't know of any studios taking that aproach. Maybe for Shake, but not for rendering. Every studio I have worked with or talked to has had all inhouse software or Maya or some combination on linux/x86.

      I would love to see more information about this and how it scales and compares to other commercial offerings.

      -Tim
      • Qmaster is relatively new, so it's not like it has a lengthy history in the market with lots of high-profile customers, except maybe Pixar. If you can find a copy of Shake (it's floating around out there) the Qmaster docs are all in there, including detailed render farm configs, IIRC there's even some discussion of Maya in the Shake docs, but I can't check now because I haven't reinstalled Shake since I upgraded to Panther last week.
        Qmaster manages remote systems through Rendezvous(ZeroConf) and AFAIK it ca
        • I will ask my contacts at Pixar if they know anything about it. I imagine they are using something a bit more robust.

          All the render farms I know use LSF, one I know of uses qube! and maybe a few have in house tools, so the market is open for a good product still. I don't know how many studios will jump on getting Apples after just switching to Linux a few years ago.
          Also, with the Apple/Pixar connection, some may not want to switch ever.

          A good render pipeline has a ton of features that need to be added to
  • Just last week I set up my first Lightwave render farm. Unfortunately all the systems in the rendering farm were over 5 years old. The main problem I ran into, beyond our artist having placed all his files outside his content directory, and the farm being slower than some of our newer PC's, was that the systems were very short on memory (96 to 128 mb each), so we'll be upgrading them soon.

    For a rendering cluster, I'd look for the systems that provide the best price / floating point performance ratio, and m

  • This might be interesting to some readers: I just read that DrQueue [drqueue.org], free render queue management software, now has more integration with Blender [blender.org]. It also seems to have good integration with Maya, as well.

    Any other good batch process managers out there, useful for rendering, compiling, or other heavy work? (I've heard of Condor which looks great except for a few serious restrictions on I/O)

    reed

  • The best price/power processor is the G5. Right now it is only available in a tower with non-ECC RAM. The good part is the RAM they use is actually very good quality and from the testing we've done there has been very few errors. Hopefully we'll see G5 xserves show up at macworld in january. The best part is apple has one of the best storage solutions available with the xserve raid. About middle of the pack as far as cost, but with top-end performance and integrity. There is no need to bother trying l
    • "The best price/power processor is the G5."

      Sadly, power is not everything. I personally wouldn't build a Lightwave render farm based on G5 processors. Don't get me wrong, I like Macs, but most Lightwave plugins are compiled for x86.

      (Directed at Dark Bard) Me personally, I'd go with dual athlon boxes. I have one at home and one at work, I run Screamernet on both, and they work wonderfully. Would I be better off with 4 single processor machines? Well honestly, that kind of depends on a few factors. Y

  • Render Smarter, Not Harder (Score:4, Informative)

    by NanoGator ( 522640 ) on Thursday December 18, 2003 @04:42AM (#7752295) Homepage Journal
    Just wanted to drop off a tip that has boosted my productivity tremendously. Multi-Pass rendering. My company got me a copy of After Effects, Adobe's compositing package. With it, I learned how to break up a scene into smaller elements and put them back together in After Effects. This has allowed me to do all kinds of things to save on rendering time. For example, I recently rendered an animation of a machine that has a fast moving piece on it. Motion blur is an expensive feature of a scene to render. However, it can be a waste of render time if only one element of the scene really really needs it. I was able to render the static elements of the scene sans motion blur, and render only the moving bits with the motion blur, thus saving a great deal of render time that could be dedicated to other things.

    I just wanted to throw this bit of advice. If your animators don't have a compositing package, it would be a worthwhile expenditure, even if it costs a machine or two from the render farm. I can't speak for other compositing packages, but I can tell you that After Effects is a damn cool, useful app for rendering. Me personally, I'd rather have 1 machine in my render farm with After Effects, than 2 machines in it without AE. If that gives you an idea.
    • I agree. Everybody renders in layers or passes.

      The thing is, most shots don't need a compositing package, they can get by with simple A over B composites, which is fairly simple to write.

      Now people like to use compositing for fx work as well, but that should be the exception, not the rule.

      -Tim
  • it makes no sense to pay top dollar for state of the art hardware and then spend a year learning to use it. go get yourself 3 or 4 cheap pc's (i've seen piii 700mhz boxes for around $100) and experiment with them.
  • you've got to pin down exactly what you're trying to do. for instance, rendering is embarassingly parallel, so if you have lots of frames, don't even think about parallelism within a frame. rendering is not particularly memory-intensive, so you might well get away without ECC, since the expected failure rate for non-ECC memory depends primarily on how much you have, and how hard you use it. if you're talking more than a handful of boxes, you definitely want to make them diskless/netboot. going SMP is pr
    • In my experience, memory and file server will be a bottleneck.

      Any decent sized rendering job (usually from people who do not know how to optimize scenes or are creating really complex shot) will use over 1gb memory. All the work is done in the memory, it is memory intensive.

      Gigabit is almost free, but the gigabit swtiches are not. If you have a rack of systems, a few odd desk tops and two servers, you want to have a 10/100 rack switch with 1 or 2 gb to the backbone switch. Have the same setup for the d
  • We've done quite a bit of experimenting with renderfarm hardware. Don't know quite as much about the software aspects of it, as I'm heavily invested in 3dsMax, knowledgewise, so that's what we've been sticking with. The best solution we found as far as bang for buck was getting whatever AMD chip was fastest at the $100 or less price point, and adding motherboard, powersupply, and memory, 512 meg per unit. no cases, we just have all the motherboards in a custom built case (an old server rack that we gutte

Slashdot Top Deals

"Money is the root of all money." -- the moving finger

Close