Very true. I've been outfitting my company with a Linux renderfarm since our main renderers have been available for it (since early this year). We're looking at setting up Linux workstations, some of our animators have stated that they would prefer to be running Linux over MSWin*.
The other issue, one that should have SGI and IBM a little worried, is cheap x86 hardware. SGI and IBM both sell render units bun charge several times more than the cost of an equivelent unit assembled from off-the-shelf parts. I don't see how they can justify this cost differential in a field where shear horsepower is absolutely crucial, buying more render power by far outweighs anything else, including high individual system availability. This is a premise of clustered computing: get the most bang for the buck and make replacing a faulty node cheap and inexpensive.
It sure sounds nice when they write that they can render something that took 90 mins per frame at.4 seconds per frame, but is this really a fair comparison? I don't doubt that NVIDIA is bringing some wicked technologies to the table, but let's also consider:
Size of rendered frames. What resolution was NVIDIA rendering out, maybe 640x480? 1024x768? FF was probably rendered out at 1880x1024 (about 2-3 times the number of pixels as compared to 1024x768) if not more.
How did they have to massage the data before passing it to the rendering pipeline? I hear FF was rendered with Renderman... are they claiming they can render RIB files through the Quadra chipset? If not, how much time does it take to convert/cook the data? If so, then... wow
How good did it look in the end? Were all the elements rendered properly, and does it really look anywhere near as good as the movie we saw in the theatre?
Don't get me wrong, I'm excited to see this kind of technology coming, I can totally see this replacing, or at least complementing, our Linux render farm at some point in the future. But it sure would be nice if we had some usefull technical details to qualify this 90 mins verses.4 seconds render time comparison.
Actually, these are incompatibilities. I'm in exactly the same situation with TD, and have superficially investigated this annoyance. A JavaScript error occurs and appears to make Netscape think that the page never finishes loading, which prevents some 'page-loading' hook from being run (or something similar, it's been months). From there it cascades into an ugly ball of 'user not finished loading page, cannot allow action...' type of problems. At least, that's one of them. Very annoying.
-- Mishka
Re:Diversion from the main task/ counterproductive
on
Terminus Demo Released
·
· Score: 1
'... ready for primetime...' is relative. Working in the 3D/graphics biz, stuff like this is good because it promotes 3D development. The bigger the market there is, the more serious the support is for 3D graphics. The better graphics support, the more likely Alias|Wavefront will port Maya over, etc. I agree with you in spirit, but keep in mind that there's hope for Linux as more than just another office OS.
Speaking from a company that does 3D animation for tv and movies, this _is_ a big deal. Have you looked at the cost comparison of MIPS vs x86? Given the option to render on a from of MIPS/IRIX machines, x86/NT machines and x86/Linux machines, the choice seems nearly obvious that x86/Linux (or even x86/FreeBSD, Maya batch render allowing) is preferred, based on a price/performance ratio.
Very true. I've been outfitting my company with a Linux renderfarm since our main renderers have been available for it (since early this year). We're looking at setting up Linux workstations, some of our animators have stated that they would prefer to be running Linux over MSWin*.
The other issue, one that should have SGI and IBM a little worried, is cheap x86 hardware. SGI and IBM both sell render units bun charge several times more than the cost of an equivelent unit assembled from off-the-shelf parts. I don't see how they can justify this cost differential in a field where shear horsepower is absolutely crucial, buying more render power by far outweighs anything else, including high individual system availability. This is a premise of clustered computing: get the most bang for the buck and make replacing a faulty node cheap and inexpensive.
--M
- Size of rendered frames. What resolution was NVIDIA rendering out, maybe 640x480? 1024x768? FF was probably rendered out at 1880x1024 (about 2-3 times the number of pixels as compared to 1024x768) if not more.
- How did they have to massage the data before passing it to the rendering pipeline? I hear FF was rendered with Renderman
... are they claiming they can render RIB files through the Quadra chipset? If not, how much time does it take to convert/cook the data? If so, then ... wow
- How good did it look in the end? Were all the elements rendered properly, and does it really look anywhere near as good as the movie we saw in the theatre?
Don't get me wrong, I'm excited to see this kind of technology coming, I can totally see this replacing, or at least complementing, our Linux render farm at some point in the future. But it sure would be nice if we had some usefull technical details to qualify this 90 mins verses--M
Actually, these are incompatibilities. I'm in exactly the same situation with TD, and have superficially investigated this annoyance. A JavaScript error occurs and appears to make Netscape think that the page never finishes loading, which prevents some 'page-loading' hook from being run (or something similar, it's been months). From there it cascades into an ugly ball of 'user not finished loading page, cannot allow action ...' type of problems. At least, that's one of them. Very annoying.
-- Mishka
'... ready for primetime ...' is relative. Working in the 3D/graphics biz, stuff like this is good because it promotes 3D development. The bigger the market there is, the more serious the support is for 3D graphics. The better graphics support, the more likely Alias|Wavefront will port Maya over, etc. I agree with you in spirit, but keep in mind that there's hope for Linux as more than just another office OS.
-- Mishka
Speaking from a company that does 3D animation for tv and movies, this _is_ a big deal. Have you looked at the cost comparison of MIPS vs x86? Given the option to render on a from of MIPS/IRIX machines, x86/NT machines and x86/Linux machines, the choice seems nearly obvious that x86/Linux (or even x86/FreeBSD, Maya batch render allowing) is preferred, based on a price/performance ratio.
--Mishka