Just remember that a human scientist walking around on the surface of Mars would most likely be able to learn more about Mars than all our previous landers and rovers combined. Instead of spending days deciding which rock to look at and the best route to get to that rock, sending the commands to do it, and then waiting for the results, a human could walk over and pick up a rock that looked interesting in a matter of seconds, and would know almost immediately if the rock warranted further inspection or was just like all the other rocks he or she has looked at so far. No problems with pesky airbags not retracting fully; a person can decide right then and there whether to walk over or around them. No worrying about the soil at Sleepy Hollow being so soft that the rover's wheels sink in and get stuck; as long as it wasn't quicksand (not possible without liquid water, blah blah blah) a person would be able to get out of it on their own.
Nevermind the technologies we'd develop during the process of designing the mission, and the useful offshoots they'd have. The Apollo missions did more than show up the Russians and prove that the Moon wasn't made of cheese.
While anti-nuclear sentiment most likely plays a part, a big reason is probably because of the weight. It doesn't matter for a craft that is going to stay in one place once it's on the surface, but for a rover I imagine they want as little weight as possible, hence the solar cells.
Probably because it isn't guaranteed to work (try running the windshield wipers on your car when the windshield is dirty and you have no wiper fluid, and see how effective it is), is weight that can be better used for things like more science equipment, and is one more moving part that can malfunction.
Also, the only time it's going to be worth it to run the wipers is when the dust is significantly cutting into the solar cells' effectiveness, but running the wiper would probably scratch the hell out of the solar cells, which will also cut significantly into their effectiveness. Remember, the wiper would be running across the solar cells while dry (no wiper fluid), dragging the dust and dirt across them as it goes.
And you could give it some wiper fluid, but again, that's less weight and room for science equipment (liquid is heavy, and you'd need to keep it under pressure or have a pump) and more things that can go wrong. What if the fluid sprayer gets clogged by the dust? What if the fluid's container or plumbing springs a leak and shorts out a critical system? The chances of a leak happening somewhere increase if you decide to keep the fluid under pressure instead of using a pump. How would you test the fluid sprayer? The gravity on Mars is a good deal less than on Earth, so if the sprayer's aim was spot-on here on Earth, it would overshoot the solar cells once the lander gets to Mars. You could try to compensate, but it'd be hard to be sure you had it aimed right, especially since the atmosphere on Mars is thinner than on Earth, so the fluid would encounter less air resistance.
In all, it just isn't worth the extra effort and added headaches, or else the rovers and landers would have a wiper for the solar cells.
Yeah, because that $400 million, extensively-tested and over-engineered Spirit rover was a disaster, while the $65 million, under-tested Beagle 2 is sending back useful data.
While I'd like nothing more than to see NASA become more efficient money-wise, cutting corners isn't the right way to do it. There's a reason NASA's projects cost a lot: they check, double-check, then triple-check everything. Their systems tend to be over-engineered, which is exactly what is needed when travelling to another planet.
And before anybody trots out Mars Polar Lander, remember that the problem was, or so I have read, with one of the contractors not building its part of the spacecraft according to NASA's specifications (using Imperial measurements instead of metric). In fact, recent evidence suggests that Mars Polar Lander may have landed intact, which means that it failed for some other reason.
A human scientist on-site could probably learn much more than all the landers and rovers combined. During the course of its entire mission, the Mars Pathfinder rover only travelled a grand total of something like 40 feet. The reason the mission ended (and the reason that the Spirit and Opportunity missions will end, if everything goes well): dust gathering on the solar cells until they can no longer provide enough electricity for the vehicle to function. Not a problem with internally-powered humans.
Communications lag means that rovers can't be controlled in real-time, and the people involed with the mission don't want to risk getting the rover stuck (rightfully so), so each destination, and the best way to get to that destination, are carefully planned out. Combine that with the rover's low speed, and it's easy to see why Mars Pathfinder didn't travel very far. On the other hand, a human walking around on the Martian surface can decide which rock looks the most interesting and pick it up in a matter of seconds.
Lastly, NASA's budget is much smaller than many other federal agencies, as others have already mentioned.
Visual effects != special effects. Special effects are effects done on the set. Visual effects are effects done in post production. The VFX Oscar has nothing to do with things like the quality of the sets (unless the sets are CG or models added in post).
First of all, I hope you realize that, in order for a film to even be considered for an Oscar, it has to be submitted by the studio that released it. Warner Bros. didn't submit The Matrix: Reloaded because they didn't want to split the vote between that and Revolutions, so Reloaded wasn't even in the running.
Also, the VFX bake-off is done by actual VFX experts, who know a bad effect when they see one. And there were lots of bad effects in The Matrix: Revolutions.
Even funnier is that Roberto Benigni stopped by the set (he was also shooting a movie in Rome), and was talking with Scorcese about it. Scorcese said Lucas came over and was like, "You know, we can do these sets with computers now." at which point Benigni laughed and said something to the effect of, "Well, that might work for George Lucas, but that's not good enough for Martin Scorcese."
I'd take the oppinions of an Oscar-winning director over George Lucas' any day of the week.
First off, let me just note that virtually all of the major VFX companies use Pixar's RenderMan implementation (called PhotoRealistic RenderMan, or PRman for short) for rendering their 3D animations. It is extremely flexible and, having been in use at Pixar and other studios for over a decade, extremely reliable. It can also handle extremely complex scenes in a relatively efficient manner. But it can't do raytracing or global illumination without utilizing dirty hacks where PRman uses another renderer (such as BMRT) as "ray server", letting the other renderer do the raytracing. Anyway, on with the story. There may be some slight inaccuracies, but to the best of my knowledge the following is true.
Back in the mid-90s, a guy named Larry Gritz wrote a RenderMan-compliant renderer called BMRT (Blue Moon Render Tools) that could do raytracing and global illumination. BMRT was made freely available (though closed source) over the internet. He was eventually hired by Pixar to work on their own RenderMan implementation called PhotoRealistic RenderMan (PRman for short). This, if memory serves, was around the the same time that Pixar was working on A Bug's Life.
Eventually, Larry Gritz left Pixar, and he and a few other people started Exluna. You see, Larry had managed to keep the copyright to BMRT while he worked at Pixar, and he intended to use BMRT (which, while producing film-quality images, was very slow and buggy) as the basis for a new, production-quality Renderman renderer called Entropy.
When it came out, Entropy got a lot of attention from VFX people. Not only did it cost less that PRman (something like $5000 per CPU for PRman vs $1700 per CPU for Entropy), it could do more. You could turn off Entropy's raytracing and global illumination if they were too slow for your liking or if you didn't need them, but the fact that they were available if you wanted/needed them (and you didn't have to do any ugly hacks to enable them) made a lot of people take a long, hard look at Entropy. Since Entropy was RenderMan-compliant, it was basically a drop-in replacement for PRman (as others have mentioned).
Throw into the mix the fact that Pixar was no longer the only major contender in the computer animated feature business. DreamWorks had done two successful computer animated features (although they used Pixar's PRman to do the rendering). BlueSky Studios was doing a computer animated feature called Ice Age, had their own proprietary renderer (CGI Studio), and unlike Pixar's PRman, it could also do raytracing and global illumination (it isn't RenderMan compliant from what I've heard, though, but that doesn't matter since CGI Studio isn't commercially available). BlueSky's renderer was also production-proven, having been used on various BlueSky projects since somewhere around 1996 (BlueSky used it to do the CG aliens in Alien: Resurrection in 1997, for example).
Facing serious competition in both the computer animated feature business and in the renderer licensing business for the first time, Pixar was probably getting nervous. So, they did the natural thing: bring out the lawyers. Since Exluna's founders were ex-Pixar employees, that gave Pixar everything they needed to file a lawsuit (albeit a shaky one) against Exluna.
The dispute, according to Pixar, was over trade secrets and a (bogus) software patent issue. I don't remember the exact details, but it was over some Pixar-held patent for a technology that Entropy didn't even use. The official response from Exluna, as posted on their website during the lawsuit, follows:
To our valued customers, partners, and supporters,
You are probably aware that Pixar Animation Studios has filed a lawsuit against Exluna, Inc. claiming infringement of a patent covering pseudorandom point sampling techniques for computer graphics (US patent 4,897,806).
There is no merit to the claim. As anyone who has used our Entropy product knows, our software uses a proprietary antialiasing method that does not involve poin
Let me spell it out for you: Warner Bros. didn't even submit The Matrix: Reloaded for inclusion in the VFX category. They didn't want to split votes between Reloaded and Revolutions.
Secondly, the VFX nominees are chosen by the academy's VFX branch. This branch is made up of actual VFX experts, most of them with years, if not decades, of experience.
That shot looked horrifically fake. The audience groaned when they saw it.
Also, it should be noted that Warner Bros. didn't even submit Reloaded for a VFX award. They didn't want the votes to be split between Reloaded and Revolutions.
You're right. There is, in fact, a color curves editor in GIMP 1.3.x. I didn't think to look under the Tools->Color Tools menu. Chalk that one up to stupidity.
The rest of my arguments remain valid, however. GTK 2.x sucks, it just sucks less than GTK 1.x. GIMP 1.3.x's GUI still sucks, it just sucks less than GIMP 1.2.x.
I realize that UserLinux is based off of Debian. My question is, why would corporate KDE users want to get a Debian-based distro that doesn't include KDE on the installation CDs when they can just go with regular Debian (which I'm assuming puts KDE on the installation CDs)?
People are forgetting that corporate users of KDE will have many systems that need KDE installed on them. By not having KDE on the installation CD, they're creating more work for the sysadmins, who now, instead of merely selecting an "Install KDE" option when installing the OS, have more steps to go through, which makes them more inclined to go with something besides UserLinux.
Care to back that up with screenshots? I distinctly remember seeing on the Pirates of the Caribbean DVD extras a shot of an ILM artist's workstation, and it looked like KDE to me.
At any rate, Digital Domain and others (such as Rythm & Hues) use KDE.
The argument is that including two software packages that are themselves as complex as the Linux kernel is not a good idea. I'm not a KDE/GNOME developer, but I can understand this. Why can't you?
No, see, I do understand it. I just don't agree with it. Especially since other distros can do it just fine.
By not even including both on the installation CDs they are effectively limiting how useful the distro is to the user. Yes, anybody can go and download KDE or GNOME. How many people can properly build and install them? But how many people will want to, when they can just pick a different distro that includes KDE on the installation CDs (as prebuilt binaries with the dependency problems already sorted out)?
The whole point of a Linux distribution is to include Linux and essential Linux software on a CD (or 3) in a nice, easy, prepackaged form so that users don't have to download it, build it, and install it by hand. If a distro is intentionally leaving what for some people is a core application (and not even offering it as an option) off of the installation CDs, then that distro is useless to those people.
To each and every corporate KDE user, UserLinux has become effectively worthless in one fell swoop.
Yes, just what I thought. You're not considering what is best for open/free software, you are simply thinking of yourself. Well, look at the bright side: KDE is open and free, and you are free to compile it under any Linux distro you want.
Have you ever tried writing programs for GTK? If not, please kindly shut up. GTK sucks, plain and simple.
Actually, according to one poster on the CinePaint mailing list (which I believe was actually a reposting of a comment on Slashdot):
the reason most studios that are Linux based use GIMP as their paint tool is because there is NO OTHER CHOICE. I work at one of the studios listed in the article. The artists on my team doing texture painting will actually go look for a 5 year old SGI octane with Photoshop 3.0 to use because it is faster and easier to use than GIMP. Let that settle in for a moment. These kids love fast machines, they crave them like crack cocaine. However, they will go sit in front of a 250MHz boat anchor and use a product released 8 years ago because it is a better tool. GIMP has a UI that that the Surgeon General should place warnings on for RSI risks (repetitive stress injury for the non acronym types.)
I think that pretty much settles that argument.
And, for the record, I have used Photoshop on both PCs and Macs. And yes, you're right, Mac Photoshop's interface isn't quite MDI. That doesn't make GTK and The GIMP suck any less.
I'm constantly hearing from Photoshop users how much they hate The GIMP's interface. More specifically, they hate the fact that in The GIMP it takes 5 clicks to do something that can be done in Photoshop with 1 or 2. They hate the way The GIMP does everything in separate windows. They hate the fact that they have to right-click on their image to get the right File menu to save the image because the File menu on the main GIMP window has no Save option. One of the smartest interface changes the CinePaint team made to their inherited GIMP interface was to put the right-click menu crap in a real menu bar on each image's window so that you can access it like a regular menu if you want to.
Yeah, lots of C programmers (myself included) hate GTK.
What I should've said was
And from what I understand, the whole "C programmers HAVE to write for GNOME/GTK and C++ programmers HAVE to write for KDE/QT" isn't true anymore, as there are bindings for both languages for both environments IIRC.
or better yet
And from what I understand, the whole "Only C programmers can write for GNOME/GTK and only C++ programmers can write for KDE/QT" isn't true anymore, as there are bindings for both languages for both environments IIRC.
Well, if you want to see things like Photoshop running natively on Linux, Adobe will have to use a toolkit that can do multiple document interfaces, and that rules out GTK.
The #1 reason people prefer Photoshop over The GIMP is the interface.
First of all, the argument that GNOME is the better choice for multi-platform shops due to the lack of licensing issues is missing a crucial point: the Windows and Mac OS X ports of GTK suck hard. Just ask the CinePaint developers.
Second, if GNOME is so much faster and so much more stable then why are major VFX studios like Digital Domain and ILM using KDE?
Thirdly, the API for QT is 10x better than GTK's API. GTK can't even do MDI-style interfaces, for crying out loud. All of GTK's problems can be traced back to the fact that it was designed with The GIMP in mind (which in and of itself is no miracle of GUI or API design).
Fourthly, the documentation for QT is superior to GTK's barebones "documentation."
Fifthly, the KDE user interface is much more consistent. Virtually all KDE apps have the same basic interface. The same cannot be said of GNOME and programs that just use GTK.
The thing is, you don't have to test for KDE and GNOME. If you write a GNOME program, test it with GNOME, and it will always work with KDE since if you run it from KDE it will still use the GNOME libraries. The same is true for the other way around.
This is really just a, "We don't like KDE, so we've decided that nobody who uses our distro will use it."
I personally don't like GNOME very much. I think QT is a better toolkit than GTK. GTK has way too many problems and limitations (like the complete inability to do MDI-style interfaces), and its whole API is a quasi-documented mess. And from what I understand, the whole "Well GNOME is for C programmers and KDE is for C++ programmers" isn't true anymore, as there are bindings for both languages for both environments IIRC.
Hey, don't worry about those flashing polygons Mr Muren, they're only in there for one frame! Wait, whadda you mean "fired"?
Re:Dear Slashdot... do my work for me please...
on
Building a Render Farm?
·
· Score: 3, Informative
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, 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.
If digital photography could match the lattitude of film, as well as the resolution of an 8x10 negative, then sure, I could see Ansel Adams using digital.
But it can't. Even 35mm film still has more lattitude than digital, and I've yet to see a digital camera that can match the extreme resolution of an 8x10 negative (without having to resort to stitching together several images).
Slashdot Mirror
Just remember that a human scientist walking around on the surface of Mars would most likely be able to learn more about Mars than all our previous landers and rovers combined. Instead of spending days deciding which rock to look at and the best route to get to that rock, sending the commands to do it, and then waiting for the results, a human could walk over and pick up a rock that looked interesting in a matter of seconds, and would know almost immediately if the rock warranted further inspection or was just like all the other rocks he or she has looked at so far. No problems with pesky airbags not retracting fully; a person can decide right then and there whether to walk over or around them. No worrying about the soil at Sleepy Hollow being so soft that the rover's wheels sink in and get stuck; as long as it wasn't quicksand (not possible without liquid water, blah blah blah) a person would be able to get out of it on their own.
Nevermind the technologies we'd develop during the process of designing the mission, and the useful offshoots they'd have. The Apollo missions did more than show up the Russians and prove that the Moon wasn't made of cheese.
You could be correct, but dust gathering on the solar cells is the reason as it was explained to me.
While anti-nuclear sentiment most likely plays a part, a big reason is probably because of the weight. It doesn't matter for a craft that is going to stay in one place once it's on the surface, but for a rover I imagine they want as little weight as possible, hence the solar cells.
Probably because it isn't guaranteed to work (try running the windshield wipers on your car when the windshield is dirty and you have no wiper fluid, and see how effective it is), is weight that can be better used for things like more science equipment, and is one more moving part that can malfunction.
Also, the only time it's going to be worth it to run the wipers is when the dust is significantly cutting into the solar cells' effectiveness, but running the wiper would probably scratch the hell out of the solar cells, which will also cut significantly into their effectiveness. Remember, the wiper would be running across the solar cells while dry (no wiper fluid), dragging the dust and dirt across them as it goes.
And you could give it some wiper fluid, but again, that's less weight and room for science equipment (liquid is heavy, and you'd need to keep it under pressure or have a pump) and more things that can go wrong. What if the fluid sprayer gets clogged by the dust? What if the fluid's container or plumbing springs a leak and shorts out a critical system? The chances of a leak happening somewhere increase if you decide to keep the fluid under pressure instead of using a pump. How would you test the fluid sprayer? The gravity on Mars is a good deal less than on Earth, so if the sprayer's aim was spot-on here on Earth, it would overshoot the solar cells once the lander gets to Mars. You could try to compensate, but it'd be hard to be sure you had it aimed right, especially since the atmosphere on Mars is thinner than on Earth, so the fluid would encounter less air resistance.
In all, it just isn't worth the extra effort and added headaches, or else the rovers and landers would have a wiper for the solar cells.
Yeah, because that $400 million, extensively-tested and over-engineered Spirit rover was a disaster, while the $65 million, under-tested Beagle 2 is sending back useful data.
While I'd like nothing more than to see NASA become more efficient money-wise, cutting corners isn't the right way to do it. There's a reason NASA's projects cost a lot: they check, double-check, then triple-check everything. Their systems tend to be over-engineered, which is exactly what is needed when travelling to another planet.
And before anybody trots out Mars Polar Lander, remember that the problem was, or so I have read, with one of the contractors not building its part of the spacecraft according to NASA's specifications (using Imperial measurements instead of metric). In fact, recent evidence suggests that Mars Polar Lander may have landed intact, which means that it failed for some other reason.
A human scientist on-site could probably learn much more than all the landers and rovers combined. During the course of its entire mission, the Mars Pathfinder rover only travelled a grand total of something like 40 feet. The reason the mission ended (and the reason that the Spirit and Opportunity missions will end, if everything goes well): dust gathering on the solar cells until they can no longer provide enough electricity for the vehicle to function. Not a problem with internally-powered humans.
Communications lag means that rovers can't be controlled in real-time, and the people involed with the mission don't want to risk getting the rover stuck (rightfully so), so each destination, and the best way to get to that destination, are carefully planned out. Combine that with the rover's low speed, and it's easy to see why Mars Pathfinder didn't travel very far. On the other hand, a human walking around on the Martian surface can decide which rock looks the most interesting and pick it up in a matter of seconds.
Lastly, NASA's budget is much smaller than many other federal agencies, as others have already mentioned.
Visual effects != special effects. Special effects are effects done on the set. Visual effects are effects done in post production. The VFX Oscar has nothing to do with things like the quality of the sets (unless the sets are CG or models added in post).
First of all, I hope you realize that, in order for a film to even be considered for an Oscar, it has to be submitted by the studio that released it. Warner Bros. didn't submit The Matrix: Reloaded because they didn't want to split the vote between that and Revolutions, so Reloaded wasn't even in the running.
Also, the VFX bake-off is done by actual VFX experts, who know a bad effect when they see one. And there were lots of bad effects in The Matrix: Revolutions.
Even funnier is that Roberto Benigni stopped by the set (he was also shooting a movie in Rome), and was talking with Scorcese about it. Scorcese said Lucas came over and was like, "You know, we can do these sets with computers now." at which point Benigni laughed and said something to the effect of, "Well, that might work for George Lucas, but that's not good enough for Martin Scorcese."
I'd take the oppinions of an Oscar-winning director over George Lucas' any day of the week.
Back in the mid-90s, a guy named Larry Gritz wrote a RenderMan-compliant renderer called BMRT (Blue Moon Render Tools) that could do raytracing and global illumination. BMRT was made freely available (though closed source) over the internet. He was eventually hired by Pixar to work on their own RenderMan implementation called PhotoRealistic RenderMan (PRman for short). This, if memory serves, was around the the same time that Pixar was working on A Bug's Life.
Eventually, Larry Gritz left Pixar, and he and a few other people started Exluna. You see, Larry had managed to keep the copyright to BMRT while he worked at Pixar, and he intended to use BMRT (which, while producing film-quality images, was very slow and buggy) as the basis for a new, production-quality Renderman renderer called Entropy.
When it came out, Entropy got a lot of attention from VFX people. Not only did it cost less that PRman (something like $5000 per CPU for PRman vs $1700 per CPU for Entropy), it could do more. You could turn off Entropy's raytracing and global illumination if they were too slow for your liking or if you didn't need them, but the fact that they were available if you wanted/needed them (and you didn't have to do any ugly hacks to enable them) made a lot of people take a long, hard look at Entropy. Since Entropy was RenderMan-compliant, it was basically a drop-in replacement for PRman (as others have mentioned).
Throw into the mix the fact that Pixar was no longer the only major contender in the computer animated feature business. DreamWorks had done two successful computer animated features (although they used Pixar's PRman to do the rendering). BlueSky Studios was doing a computer animated feature called Ice Age, had their own proprietary renderer (CGI Studio), and unlike Pixar's PRman, it could also do raytracing and global illumination (it isn't RenderMan compliant from what I've heard, though, but that doesn't matter since CGI Studio isn't commercially available). BlueSky's renderer was also production-proven, having been used on various BlueSky projects since somewhere around 1996 (BlueSky used it to do the CG aliens in Alien: Resurrection in 1997, for example).
Facing serious competition in both the computer animated feature business and in the renderer licensing business for the first time, Pixar was probably getting nervous. So, they did the natural thing: bring out the lawyers. Since Exluna's founders were ex-Pixar employees, that gave Pixar everything they needed to file a lawsuit (albeit a shaky one) against Exluna.
The dispute, according to Pixar, was over trade secrets and a (bogus) software patent issue. I don't remember the exact details, but it was over some Pixar-held patent for a technology that Entropy didn't even use. The official response from Exluna, as posted on their website during the lawsuit, follows:
Let me spell it out for you: Warner Bros. didn't even submit The Matrix: Reloaded for inclusion in the VFX category. They didn't want to split votes between Reloaded and Revolutions.
Secondly, the VFX nominees are chosen by the academy's VFX branch. This branch is made up of actual VFX experts, most of them with years, if not decades, of experience.
That shot looked horrifically fake. The audience groaned when they saw it.
Also, it should be noted that Warner Bros. didn't even submit Reloaded for a VFX award. They didn't want the votes to be split between Reloaded and Revolutions.
You're right. There is, in fact, a color curves editor in GIMP 1.3.x. I didn't think to look under the Tools->Color Tools menu. Chalk that one up to stupidity.
The rest of my arguments remain valid, however. GTK 2.x sucks, it just sucks less than GTK 1.x. GIMP 1.3.x's GUI still sucks, it just sucks less than GIMP 1.2.x.
1)The last time I tried GIMP 1.3 it didn't have (or I couldn't find) a curves tool. This automatically renders it a non-contender.
2)While better than GTK 1.x, GTK 2.x still sucks.
I realize that UserLinux is based off of Debian. My question is, why would corporate KDE users want to get a Debian-based distro that doesn't include KDE on the installation CDs when they can just go with regular Debian (which I'm assuming puts KDE on the installation CDs)?
People are forgetting that corporate users of KDE will have many systems that need KDE installed on them. By not having KDE on the installation CD, they're creating more work for the sysadmins, who now, instead of merely selecting an "Install KDE" option when installing the OS, have more steps to go through, which makes them more inclined to go with something besides UserLinux.
Care to back that up with screenshots? I distinctly remember seeing on the Pirates of the Caribbean DVD extras a shot of an ILM artist's workstation, and it looked like KDE to me.
At any rate, Digital Domain and others (such as Rythm & Hues) use KDE.
No, see, I do understand it. I just don't agree with it. Especially since other distros can do it just fine.
By not even including both on the installation CDs they are effectively limiting how useful the distro is to the user. Yes, anybody can go and download KDE or GNOME. How many people can properly build and install them? But how many people will want to, when they can just pick a different distro that includes KDE on the installation CDs (as prebuilt binaries with the dependency problems already sorted out)?
The whole point of a Linux distribution is to include Linux and essential Linux software on a CD (or 3) in a nice, easy, prepackaged form so that users don't have to download it, build it, and install it by hand. If a distro is intentionally leaving what for some people is a core application (and not even offering it as an option) off of the installation CDs, then that distro is useless to those people.
To each and every corporate KDE user, UserLinux has become effectively worthless in one fell swoop.
Have you ever tried writing programs for GTK? If not, please kindly shut up. GTK sucks, plain and simple.
I think that pretty much settles that argument.
And, for the record, I have used Photoshop on both PCs and Macs. And yes, you're right, Mac Photoshop's interface isn't quite MDI. That doesn't make GTK and The GIMP suck any less.
I'm constantly hearing from Photoshop users how much they hate The GIMP's interface. More specifically, they hate the fact that in The GIMP it takes 5 clicks to do something that can be done in Photoshop with 1 or 2. They hate the way The GIMP does everything in separate windows. They hate the fact that they have to right-click on their image to get the right File menu to save the image because the File menu on the main GIMP window has no Save option. One of the smartest interface changes the CinePaint team made to their inherited GIMP interface was to put the right-click menu crap in a real menu bar on each image's window so that you can access it like a regular menu if you want to.
What I should've said was
or better yet
Well, if you want to see things like Photoshop running natively on Linux, Adobe will have to use a toolkit that can do multiple document interfaces, and that rules out GTK.
The #1 reason people prefer Photoshop over The GIMP is the interface.
First of all, the argument that GNOME is the better choice for multi-platform shops due to the lack of licensing issues is missing a crucial point: the Windows and Mac OS X ports of GTK suck hard. Just ask the CinePaint developers.
Second, if GNOME is so much faster and so much more stable then why are major VFX studios like Digital Domain and ILM using KDE?
Thirdly, the API for QT is 10x better than GTK's API. GTK can't even do MDI-style interfaces, for crying out loud. All of GTK's problems can be traced back to the fact that it was designed with The GIMP in mind (which in and of itself is no miracle of GUI or API design).
Fourthly, the documentation for QT is superior to GTK's barebones "documentation."
Fifthly, the KDE user interface is much more consistent. Virtually all KDE apps have the same basic interface. The same cannot be said of GNOME and programs that just use GTK.
GNOME is not a window manager. In fact, GNOME seems to switch window managers with every release. Enlightenment, Sawfish, Metacity, etc.
I use KDE 3.0.3 every day and it never crashes. I also care mostly about the apps: KMail for e-mail, Kate for writing code, KHexEdit, etc.
The thing is, you don't have to test for KDE and GNOME. If you write a GNOME program, test it with GNOME, and it will always work with KDE since if you run it from KDE it will still use the GNOME libraries. The same is true for the other way around.
This is really just a, "We don't like KDE, so we've decided that nobody who uses our distro will use it."
I personally don't like GNOME very much. I think QT is a better toolkit than GTK. GTK has way too many problems and limitations (like the complete inability to do MDI-style interfaces), and its whole API is a quasi-documented mess. And from what I understand, the whole "Well GNOME is for C programmers and KDE is for C++ programmers" isn't true anymore, as there are bindings for both languages for both environments IIRC.
Hey, don't worry about those flashing polygons Mr Muren, they're only in there for one frame! Wait, whadda you mean "fired"?
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, 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.
If digital photography could match the lattitude of film, as well as the resolution of an 8x10 negative, then sure, I could see Ansel Adams using digital.
But it can't. Even 35mm film still has more lattitude than digital, and I've yet to see a digital camera that can match the extreme resolution of an 8x10 negative (without having to resort to stitching together several images).