i_r_sensitive is extremely optimistic if he feels that multi-core processors are going to mean the end of per-processor licensing. I would think that most software licensors are looking toward multi-core chips as the gravy train finally pulling into town.
When you think about it, any licensing deal is a contract between a software provider and a software user. If the price doesn't make sense, then the contract won't happen.
Depending on the cost of the processor chips, the computer chassis they plug into, and the license cost -- per processor licensing could save people money when they move to multi-core machines -- assuming that the two-core machine really is twice as fast at the application as two single-core machines. If the chips don't cost much more, you save the hardware, energy, and cooling costs of the second chassis. This could be a big win.
This is one of those cases where the market will decide. In [my] visual effects business, company policies are all over the map. Pixar allows you to run RenderMan on dual-proc machines with a single license. It believe (could be wrong, we have only 2 proc machines)) that Shake will run on however many processors you have in one box using just one license. Other software requires a separate license for each processor.
But really, when I say "software requires", that's wrong and stupid. It's the contract you have with the software provider that requires it, and contracts are often quite malleable.
That's an astronomical day, as opposed to a solar day. The sun is in a different place with respect to the more distance stars every day, that's where the extra four minutes goes.
Another way of saying it is that every 24 hours (more or less) the sun is at the same place in the sky, while every 23:56, the stars are in the same place in the sky.
In the JPEG standard, there are two possible compression modes for the DCT coefficients, Huffman and Arithmetic encoding. The arithmetic coding is about 10% smaller, far faster to compute, but is unfortunately proscribed by the IBM patent.
If IBM would release this patent, we could change some #defines in the JPEG code and get 10% smaller pictures with no change in quality.
You are exactly right. The movie business needs to change dramatically to make a product that people are willing to part with their hard-earned dollars to see.
I believe that the home theater market is going to explode in the next few years as HDTV becomes more widespread. The prices for exquisitely good TV's has been plummeting, and will continue to plummet, to the point where they will become quite common. Large screen LCD and soon OLED and SED TVs are going to be fabulous and affordable. Good audio is not terribly expensive, and I believe it will also become ubiquitous.
So, movie theaters have to raise the bar. I will continue to push the digital film industry toward higher quality -- I think it's absolutely necessary to stay competetive. Current digital projectors (there are somewhat less than 100 digital theaters in the US right now) project at a measely 1280x1024. The next generation is going to be only 1920 pixels wide, which is the same resolution as HDTV. This isn't good enough!
So, I differ from the parent in that I think the home market will move faster than he expects, but I completely agree that the movie theater experience needs to be improved, and quickly, to stay competetive. If it fails to do that, then perhaps it deserves its fate.
Hans Lehmann says Please note that it's the Mexican music *Industry* that's being hurt. The music continues to be played & recorded, and people are still listening to it.
When the Mexican music "industry" you speak so poorly of disappears, who exactly will be recording this music? The music referred to in the LA Times article is native Mexican music, not imported USian music.
If people want their music to be produced in garages, then that's what they'll get. A lot of great music can be made that way, especially with modern digital recording techniques. It's kind of a bummer, though, if that's the only kind of music that can be produced.
It is useful to see this ultimate result of the piracy phenomenon getting played out so close to home. Maybe people will notice. I somehow doubt it, though.
The LA Times has an interesting story today (registration required, sorry) about the Mexican music industry. It is in the process of being destroyed by piracy.
I think that the movie industry is about five years behind the music industry in terms of the impact of downloading, mostly because the file size is so much higher. It will happen, though.
Note well that that Harry Potter film that they are talking about cost about $120 million to make, as opposed to a record which might cost about $1 million. That money has to be recovered or the movie will not be made. Movies will, of course, continue to be made when piracy becomes rampant, but they will be dramatically different. They will be far cheaper, and will be filled with product placement.
Hopefully, I'll be retired by that point.
thad
If you really have 1TB/month of fMRI data, I'd look very carefully into algorithms for compressing it. I would think that a customized compression scheme for a particular type of data might yeild quite impressive results, reducing the backup problem by an order of magnitude or more. From your description of the value of the data and the cost of recovery, some time invested in a compression scheme would be well spent.
My guess for the watermarking is that there won't be just a few artifacts -- that every bit of every image will be affected in a subtle way.
That said, it is probably true that the watermarking could be defeated with access to several of the players. It would take a serious effort, at least as serious as what Felton and his group at Princeton put into cracking the audio watermarking scheme a few years ago. As you recall, he had the advantage that the watermarking scheme was disclosed very completely in a patent filing. I can't imagine anybody but some kind of organized crime group putting in that kind of effort.
The most likely avenue for exploitation of screeners is that somebody's house will be broken into, and their collection of screeners and their player stolen. I'm willing to bet that this will happen. I mean, if the entire shipment of Academy Awards statues can be stolen...
Actually, no. The early (and probably devastating) Hulk pre-release wasn't a screener -- it was a early rough-cut of the movie with temp effects that was given to a advertising agency. The agency was supposed to be making ads for the movie. You're right, though, that once the fool ripped it, it was everywhere immediately. Because the temp rough-cut of the movie was so unique, the studio was able to track it down almost immediately.
A screener wouldn't have been as bad, because those don't become available until just as, or maybe a very few days before, the movie is released. This copy of Hulk, though, came out almost two months before the final movie. IMHO, having a poor copy of the movie with temp effects so widely viewed two months early really did impact the market for The Hulk.
I read the articles. The KCBS (2) article is interesting. They say that the state tolerates an error of 6 cubic inches in 5 gallons, and that the first pump he tested was off by 50% more than that. Wow! 50% more that legal! But how much is that?
Well, 5 gallons is 1155 cubic inches, so 6 cubic inches is one-half of one percent. This pump that was off was off one-quarter percent more than that. 1/4% is 5 cents on a 20 dollar fillup.
I wouldn't be at all surprised if gas stations try to hit that.5% low, but really that's pretty close to the mark. This is nothing compared to, say, the decrease in energy resulting from the mandated blending of ethanol with gasoline.
In my experience, when the needle in my MR2 gets to E, it always takes within.1 gallon of 11.3 gallons, except for one time when it was considerably more -- and I called the state Weights and Measures people to report that station. The number is on a sticker on the gas pump, might as well attempt to make the system work. Anyway, since it always takes the same amount of gas, I have to think that most stations are either accurate or all cheating by the same amount.
I love AvWeek. I read every article every week. If it gets to be Wednesday or Thursday and it hasn't shown up yet -- I start to get quite annoyed. Like this week:) Once you get past the rah-rah war stuff (and there's a lot of that) you do see an interesting cross-section of state-of-the-art computer, aerodynamic, and mechanical engineering.
My father-in-law was a test pilot for Grumman, and his daughter (my wife) asked him what would happen if he had to choose between his wife and his AvWeek. He said "Fortunately, I've never had to make that choice."
At some point, you are going to have car manufacturers trying to make a car that will do well on the artificial EPA fuel economy test -- we may well have seen that with the Prius. Toyota actually complains (I'm not sure if they're sincere, mind you) that they are not allowed to specify any numbers other than the EPA numbers -- they'd really like to tell people what they really would expect, but federal law prohibits that kind of thing.
That said, I'm selling my MR2 Spyder Thursday and buying a new Prius. Mostly I need more space for my family -- the two-seater just isn't cutting it.
The MR2 specification is 26 City, 32 Highway. I usually get about 28 mpg doing fairly aggressive mountain and city driving.
I'm guessing that the roll control was caused by assymetric thrust on motor ignition. This was the first flight using a dramatically larger engine bell.
As rockets climb, the optimal size of the engine bell increases dramatically. The more the exhaust gases can be expanded supersonically, the more thrust they generate. But, you can't expand the exhaust too much a low altitudes, because the pressure of the atmosphere the gases are expanding into is too great, you get instability.
One of the most important things about launching SpaceShipOne from altitude is that you can avoid 90% of the atmosphere, and can use a far more optimized engine bell. All previous flights, though, used a smaller bell that could be tested on the ground. This limited performance.
It wouldn't surprise me that as the engine was ramping up to full power, there was instability in the nozzle due to overexpansion. Note well that all ground based rockets are held on the ground for a few seconds to evaluate the performance of the engines and to allow them to stabilize -- this is one of the downsides to air-launch.
Assymetric yaw could easily couple into roll for SpaceShipOne, with its rather pronounced dihedral effect.
SpaceShipOne is fairly unique in that the horizontal tail surfaces are outside the span of the wings. It uses differential movement of these tail surfaces to control roll. At subsonic speeds the pilot controls the elevons at the back of these surfaces, through a fairly normal linkage, but as you get to supersonic speeds the aerodynamic forces become impossible for human strength to overcome. So, at high speeds the front half of the tail control surfaces are moved electrically to generate pitch and roll forces. Apparently one of these electric trim systems failed.
The Bell X-1 used a similar electric trim for pitch, to overcome instabilities going through Mach 1.
Because the elevons on SpaceShipOne control both pitch and roll, Melville was left with no control on two out of three axes at the end of his climb. I cannot imagine how this must have felt, but he recovered with astonishing speed -- and was playing around with floating M&M's a few seconds later. It's unclear to me just what kind of "backup system" he used to control the ship after the trim motor failure, perhaps it was the cold-gas thrusters.
SpaceShipOne depends on still being within the vestiges of the atmosphere for control while the rocket is firing, although the parent poster is correct, control will get sloppy toward the end of the burn as they get above 150,000 ft. The ship has the advantage that it is going very fast indeed at that point, so while there is not a lot of air up there, the forces is generates is more than you would expect.
I was surprised watching the launch that the exhaust plume did not change much during the flight from 50,000 ft to burnout -- I would have expected to see far more expansion as it left the atmosphere -- as you see during a MinuteMan launch, for example. This again points to the ship still being atmosphere of some significant (while small!) density at burnout.
That Mike Melville is one hell of a pilot, his skill and Burt Rutan's innovative feather recovery saved the day. Every previous manned exoatmospheric craft depended on flying an extremely precise attitude before and during re-entry. Failure to maintain this attitude led to the loss of an X-15 and the NF-104 as dramatically recounted in The Right Stuff. SpaceShipOne has no effective attitude control during re-entry, but feathering the wing put the ship into an extremely stable high-drag configuration. Once the ship was subsonic and the wing was folded back into its normal position, the manual control of the elevons was used to fly the ship to a perfect landing.
If you look at SpaceShipOne as it flew yesterday, there was significant work done in the tail booms after the previous flight and prior to this one -- the most obvious change is the installation of a few more camera portholes (presumably with cameras behind them). That's the first place I'd look for the cause of the trim failure.
The launch yesterday was great fun to attend, and I really do think that it will mark a profound change in our access to space.
I think that these pilots are old fighter jocks, every maneuver they did was right out of the sun. Unfortunately, the people on the ground weren't the enemy, but were the fans:)
It was an awe-inspiring show. It seems the crowds were about the same as those at the Voyager landing in '86 -- my wife joked that they were probably the same people, a little grayer and a little longer in the tooth:)
I loved the fact that the Scaled Composite site says that "especially kids" are welcome, they want to introduce the next generation to private space flight. I'm taking my 14 year old daughter and two of her friends.
We're currently planning on camping at the Tehachapi glider park Sunday night, then driving to Mojave at 4:00 Monday morning. We'll see if that works -- there is so much publicity here and at other sites that it may be insanely crowded.
I've been a fan of Rutan since the '79 Popular Science cover of the VariEze, and I've got a copy of the plans for his LongEZ (too big a job for me to complete, though...) I have been looking forward to this event for a long time, I can't wait!
Concentrated H2O2 has been used a long, long time as a monopropellant, and in fact that's what some of Carmack's early rockets were powered by. But, unfortunately, it had some serious problems. They are:
The couldn't find anybody who would sell them the required 90% H202, because they were building rockets. They could buy the stuff, but only if they promised not to build rockets with it.
90% H202 is pretty darn expensive.
The Specific Impulse of H2O2 monopropellant engines is not very high, building an X-Prize vehicle based on H2O2 would be extremely difficult because there just isn't too much ooomph in pure H202.
No flames shoot out the back (this was a problem for Carmack, anyway)
Carmack now uses a combination of 50%-strength H2O2 and some amount of alcohol. As the H2O2 breaks down into steam and oxygen in the first layer of catalyst, the alcohol can burn with the oxygen. This give substantially more specific impulse with much cheaper, readily available fuel.
BEWARE BEWARE BEWARE Mixing alcohol with hydrogen peroxide is not for the faint of heart. Doing it wrong can yeild disasterous results. As Carmack said of his early experiments, the resulting spectacular explosions "gives one pause." Yeah.
Carmack was encouraged to try again with the mixed monopropellant by somebody who was reading his blog who referred him to German WW2 torpedo propellants. A problem that the Germans had with H2O2 propellants were that the resulting oxygen made bubbles that were easy for the good guys to track. By burning alcohol as well, they would use up the oxygen and be left with water vapor and CO2, both of which dissolve quite readily in seawater. The trick was using just the right concentration of H2O2 and the right proportion of the right kind of alcohol. Many tests were performed to find the optimal mixture. Even so, engineering a rocket engine that would successfully, reliably, and repeatably light off and burn cleanly took many months of quite difficult, not to say disheartening, work.
Congratulations, John -- this flight was a spectacular achievement. May the full-scale vehicle tests go as well.
I believe it was Mark Twain that said "History doesn't repeat itself, but it rhymes."
Picking on Fred Brooks' TMMM by noting it's anacrhonisms is about the most juvenile thing I can imagine. I can only surmise that the alleged reviewer was forced to read the book by somebody he did not like, and while he read the words he certainly didn't extrapolate the lessons to his present day situations.
When I re-read The Mythical Man Month I can see, in every paragraph, perfect analogies to my work today, and the work I see of other people in other fields. I can't wait to have the reviewer look at The Soul of the New Machine and laugh about how people used to build CPUs out of discrete parts, and how therefore none of the lessons of that book have any applicability today.
Who hasn't seen -- or lived -- an example of Brooks's "The Second System Effect?" The movie that I just finished working on, The Chronicles of Riddick was precisely an example of that paradigm with respect to Pitch Black. Every page of the chapter on The Second System Effect has one-to-one correspondences to the work on this movie.
There are few things that I'm dogmatic about -- but Everybody needs to read this book!
Well, I should have mentioned that are largest line item, by far, is the animators that drive all of this software. At least on a project of the scale of Riddick, it was best to use software with which our animators would be most productive. For rendering, that means RenderMan. There are many people who have strong experience in writing shaders and doing lighting in RenderMan -- and RenderMan is practically bullet-proof after decades now of work.
We did try a couple of other rendering alternatives. We hoped to be able to use the new Cg shading language to do hardware rendering for some of the shots. We hired an absolute wizard named Hal Bertram to help us with that, but in the end decided that the hardware (at the time) was still not good enough to do final rendering. Interestingly, with the new NV40 chips incorporating Vertex Shader 3.0 and Pixel Shader 3.0 capabilities, almost all of those limitations have been overcome, and we'll be examining hardware rendering anew for our future projects. It seem inevitable to me that in the near future, we will be using hardware rendering for most of our shots -- the quality of what can be rendered with hardware is improving at a breathtaking pace.
We also looked at some other non-free and free (although not open-source) software renderers, some even claiming to be compatible with RenderMan. While they are truly amazing efforts by small teams, we very quickly ran into devastating problems with each of them. I really hate to mention who they are, because they are trying so hard -- but they're not there yet.
One renderer that I'm extremely excited about is Splutterfish's Brazil. It renders some spectacular images mind-bogglingly fast. In particular, it does what has come to be known as "ambient occlusion" so fast that I just can't believe it. Unfortunately, it only runs on the Operating System That Will Not Be Named.
So, in the end, we spent the money for RenderMan to make best use of the really expensive resource, our animators. Having a familiar environment, and one where everything worked every time with no "gotcha's" was worth it. [OK, we did run into some RenderMan surprises...but nothing too serious].
I think that this is a very valid point -- that as your system gets bigger the decisions have to change. Certainly the bigger you are, the more of a win it becomes to write software, and configure hardware, to your particular needs rather than relying on an off-the-shelf solution.
A big problem with this is that systems that end up really big (hundreds of employees and 500 renderers is really big as far as I'm concerned) don't start out big -- so the decisions and configurations you start with and are optimal when you start become completely wrong when the project grows. I'm quite impressed that you were able to move over to a custom in-house tool when you needed to -- especially as you were surely sweltering in the heat of production as you found Rush to be inadequate.
Are you able to tell us which productions were these machines involved in rendering?
These particular machines were just used for The Chronicles of Riddick. Computer technology advances so fast, has lowered in price so quickly, and movie post-production schedules are so long (six to nine months, typically) that we typically don't use any particular machines for more than a couple of films.
Also, in the interest of understanding how much it costs to set up a significant render farm, how much does this sort of thing cost? Is it all in the PCs, or would the backplane infrastructure cost surprise us a lot?
In fact the dominant cost, at least for us, is not the render boxes themselves. The network is a significant expense, as is the data server system. An even larger expense, though, are the licenses for the rendering software. Top-of-the-line rendering systems like RenderMan (for 3D) and Shake (for 2D) cost thousands of dollars per node. And then there are significant infrastructure costs in just electrical wiring and cooling.
At least in the 10-to-50 server range, I would say that the costs are pretty linear. As you get bigger than that, you can start to see some economies of scale.
At some point, it becomes profitable to start developing in-house software tools instead of buying licenses. Digital Domain's Nuke system was originally developed as a renderer for Flame, for example, so that the expensive Flame machines could be used for the interactive work and the batch rendering could happen on commodity hardware. For Riddick, we developed our own smoke-rendering system rather than use RenderMan, to free up render licenses for other parts of the movie.
I'm afraid that an explict cost-per-node breakdown would get into details that we keep confidential, but this should give you an overview of our situation.
1.) The words 'dual' and 'Opteron' both surprised us. We were kind of under the impression that maybe single proc machines would be better for a render farm. We were really curious why dual was chosen over single. Did the extra cost end up being worth it?
The computers are relatively cheap -- it's render licenses (especially for RenderMan) that are expensive. With the newest version of RenderMan, Pixar has deigned to let us use the two processors of a dual-processor machine with a single license. This lowers the cost of rendering by about 60%, if the machine rendered twice as fast with dual processors. In fact, for RenderMan, the Opterons were indeed almost twice as fast, where the Xeons were only about 50% faster.
Our other big rendering application was Shake, and it also allowed the use of two processors with one license.
2.) You mentioned that Opteron was more efficient than Xeons. I just had to ask: Was the particular software you were using particularly tuned to Opteron (i.e. 64-bit?) or was the 32-bit side of it just pleasant to work with? Any more insight you can share with me about the use of Opteron would be most helpful.
Yes and no. The Opterons are the first AMD machines to implement the SSE2 instructions, which are heavily used by RenderMan. Also, the HyperChannel communication between processors on the Opteron is light-years beyond the communication between Athlons and Xeons. On the other hand, there is absolutely no advantage in the 64-bitness of the Opterons -- we were running a 32-bit Linux (RedHat 9), and we weren't using more than 4 GB memory on any of the boxes.
3.) Did you guys end up buying a bunch of machines from a place like IBM or something, or was it more like "we bought the components and assembled ourselves..?" If it's the former, how'd you like the service?
We hired a beige-box manufacturer. We specced it out to various places, and PC Mall built them for the best price. If I had to do it over again, I'm not sure that I wouldn't go with IBM -- while they cost a lot more, I expect that they'd build more solid systems.
4.) Any regrets or things you'd do differently next time around?
We bought minitower machines instead of the more trendy, space- and power-efficient 1U or blade machines. We did that so that we could potentially use the new Gelato renderer from NVidia -- that software uses the current NVidia high-performance graphics cards as an external array processor, giving significantly better render performance.
As we didn't end up using Gelato, that was perhaps a mistake. We ended up power and HVAC constrained in the end -- as happens with almost every renderfarm I've heard of.
5.) Why are you getting rid of the machines used for Riddick? Or did I read that wrong?
No, you read it right. Hammerhead is a small company, typically working on just one show at a time. We don't see a use for the machines for another nine months or so, as we begin development of the next project -- and it just isn't right to leave all that compute horespower idle.
I could be wrong, but I thought that Pixar was going to stick with Intel-type machines for the renderfarm, although they are apparently moving to OS X boxes for their animator workstations.
I'm porting all of our animation code from Linux to OS X as well -- more or less as an exercise in code portability -- and it's going pretty well. OS X 10.3 is dramatically more standards- (or at least Linux-) compliant than the earlier OS X versions were. Almost every program I have compiles with virtually no changes. The OpenGL and Glut implementations seem to work perfectly. The only surprise is how far behind the times the Mac graphics cards arel, but few of our programs really need to render 5 million polygons a second.
Slashdot Mirror
i_r_sensitive is extremely optimistic if he feels that multi-core processors are going to mean the end of per-processor licensing. I would think that most software licensors are looking toward multi-core chips as the gravy train finally pulling into town.
When you think about it, any licensing deal is a contract between a software provider and a software user. If the price doesn't make sense, then the contract won't happen.
Depending on the cost of the processor chips, the computer chassis they plug into, and the license cost -- per processor licensing could save people money when they move to multi-core machines -- assuming that the two-core machine really is twice as fast at the application as two single-core machines. If the chips don't cost much more, you save the hardware, energy, and cooling costs of the second chassis. This could be a big win.
This is one of those cases where the market will decide. In [my] visual effects business, company policies are all over the map. Pixar allows you to run RenderMan on dual-proc machines with a single license. It believe (could be wrong, we have only 2 proc machines)) that Shake will run on however many processors you have in one box using just one license. Other software requires a separate license for each processor.
But really, when I say "software requires", that's wrong and stupid. It's the contract you have with the software provider that requires it, and contracts are often quite malleable.
Thad Beier
That's an astronomical day, as opposed to a solar day. The sun is in a different place with respect to the more distance stars every day, that's where the extra four minutes goes.
Another way of saying it is that every 24 hours (more or less) the sun is at the same place in the sky, while every 23:56, the stars are in the same place in the sky.
In the JPEG standard, there are two possible compression modes for the DCT coefficients, Huffman and Arithmetic encoding. The arithmetic coding is about 10% smaller, far faster to compute, but is unfortunately proscribed by the IBM patent.
If IBM would release this patent, we could change some #defines in the JPEG code and get 10% smaller pictures with no change in quality.
Thad Beier
You are exactly right. The movie business needs to change dramatically to make a product that people are willing to part with their hard-earned dollars to see.
I believe that the home theater market is going to explode in the next few years as HDTV becomes more widespread. The prices for exquisitely good TV's has been plummeting, and will continue to plummet, to the point where they will become quite common. Large screen LCD and soon OLED and SED TVs are going to be fabulous and affordable. Good audio is not terribly expensive, and I believe it will also become ubiquitous.
So, movie theaters have to raise the bar. I will continue to push the digital film industry toward higher quality -- I think it's absolutely necessary to stay competetive. Current digital projectors (there are somewhat less than 100 digital theaters in the US right now) project at a measely 1280x1024. The next generation is going to be only 1920 pixels wide, which is the same resolution as HDTV. This isn't good enough!
So, I differ from the parent in that I think the home market will move faster than he expects, but I completely agree that the movie theater experience needs to be improved, and quickly, to stay competetive. If it fails to do that, then perhaps it deserves its fate.
Thad Beier
When the Mexican music "industry" you speak so poorly of disappears, who exactly will be recording this music? The music referred to in the LA Times article is native Mexican music, not imported USian music.
If people want their music to be produced in garages, then that's what they'll get. A lot of great music can be made that way, especially with modern digital recording techniques. It's kind of a bummer, though, if that's the only kind of music that can be produced.
It is useful to see this ultimate result of the piracy phenomenon getting played out so close to home. Maybe people will notice. I somehow doubt it, though.
Thad
The LA Times has an interesting story today (registration required, sorry) about the Mexican music industry. It is in the process of being destroyed by piracy. I think that the movie industry is about five years behind the music industry in terms of the impact of downloading, mostly because the file size is so much higher. It will happen, though. Note well that that Harry Potter film that they are talking about cost about $120 million to make, as opposed to a record which might cost about $1 million. That money has to be recovered or the movie will not be made. Movies will, of course, continue to be made when piracy becomes rampant, but they will be dramatically different. They will be far cheaper, and will be filled with product placement. Hopefully, I'll be retired by that point. thad
If you really have 1TB/month of fMRI data, I'd look very carefully into algorithms for compressing it. I would think that a customized compression scheme for a particular type of data might yeild quite impressive results, reducing the backup problem by an order of magnitude or more. From your description of the value of the data and the cost of recovery, some time invested in a compression scheme would be well spent.
Thad
My guess for the watermarking is that there won't be just a few artifacts -- that every bit of every image will be affected in a subtle way.
That said, it is probably true that the watermarking could be defeated with access to several of the players. It would take a serious effort, at least as serious as what Felton and his group at Princeton put into cracking the audio watermarking scheme a few years ago. As you recall, he had the advantage that the watermarking scheme was disclosed very completely in a patent filing. I can't imagine anybody but some kind of organized crime group putting in that kind of effort.
The most likely avenue for exploitation of screeners is that somebody's house will be broken into, and their collection of screeners and their player stolen. I'm willing to bet that this will happen. I mean, if the entire shipment of Academy Awards statues can be stolen...
Thad
Actually, no. The early (and probably devastating) Hulk pre-release wasn't a screener -- it was a early rough-cut of the movie with temp effects that was given to a advertising agency. The agency was supposed to be making ads for the movie. You're right, though, that once the fool ripped it, it was everywhere immediately. Because the temp rough-cut of the movie was so unique, the studio was able to track it down almost immediately.
A screener wouldn't have been as bad, because those don't become available until just as, or maybe a very few days before, the movie is released. This copy of Hulk, though, came out almost two months before the final movie. IMHO, having a poor copy of the movie with temp effects so widely viewed two months early really did impact the market for The Hulk.
thad
Disclaimer: I am an Academy member
I've been testing these drivers under Fedora Core 2 for a while, and they appear to work flawlessly.
Thad
I read the articles. The KCBS (2) article is interesting. They say that the state tolerates an error of 6 cubic inches in 5 gallons, and that the first pump he tested was off by 50% more than that. Wow! 50% more that legal! But how much is that?
.5% low, but really that's pretty close to the mark. This is nothing compared to, say, the decrease in energy resulting from the mandated blending of ethanol with gasoline.
.1 gallon of 11.3 gallons, except for one time when it was considerably more -- and I called the state Weights and Measures people to report that station. The number is on a sticker on the gas pump, might as well attempt to make the system work. Anyway, since it always takes the same amount of gas, I have to think that most stations are either accurate or all cheating by the same amount.
Well, 5 gallons is 1155 cubic inches, so 6 cubic inches is one-half of one percent. This pump that was off was off one-quarter percent more than that. 1/4% is 5 cents on a 20 dollar fillup.
I wouldn't be at all surprised if gas stations try to hit that
In my experience, when the needle in my MR2 gets to E, it always takes within
Thad Beier
I love AvWeek. I read every article every week. If it gets to be Wednesday or Thursday and it hasn't shown up yet -- I start to get quite annoyed. Like this week :) Once you get past the rah-rah war stuff (and there's a lot of that) you do see an interesting cross-section of state-of-the-art computer, aerodynamic, and mechanical engineering.
My father-in-law was a test pilot for Grumman, and his daughter (my wife) asked him what would happen if he had to choose between his wife and his AvWeek. He said "Fortunately, I've never had to make that choice."
thad
At some point, you are going to have car manufacturers trying to make a car that will do well on the artificial EPA fuel economy test -- we may well have seen that with the Prius. Toyota actually complains (I'm not sure if they're sincere, mind you) that they are not allowed to specify any numbers other than the EPA numbers -- they'd really like to tell people what they really would expect, but federal law prohibits that kind of thing.
That said, I'm selling my MR2 Spyder Thursday and buying a new Prius. Mostly I need more space for my family -- the two-seater just isn't cutting it.
The MR2 specification is 26 City, 32 Highway. I usually get about 28 mpg doing fairly aggressive mountain and city driving.
I'm guessing that the roll control was caused by assymetric thrust on motor ignition. This was the first flight using a dramatically larger engine bell.
As rockets climb, the optimal size of the engine bell increases dramatically. The more the exhaust gases can be expanded supersonically, the more thrust they generate. But, you can't expand the exhaust too much a low altitudes, because the pressure of the atmosphere the gases are expanding into is too great, you get instability.
One of the most important things about launching SpaceShipOne from altitude is that you can avoid 90% of the atmosphere, and can use a far more optimized engine bell. All previous flights, though, used a smaller bell that could be tested on the ground. This limited performance.
It wouldn't surprise me that as the engine was ramping up to full power, there was instability in the nozzle due to overexpansion. Note well that all ground based rockets are held on the ground for a few seconds to evaluate the performance of the engines and to allow them to stabilize -- this is one of the downsides to air-launch.
Assymetric yaw could easily couple into roll for SpaceShipOne, with its rather pronounced dihedral effect.
Thad Beier
What's even more amazing is that the cost per flight is amazingly low, they're saying about $80,000.
This is about what it costs to fly a 747 across the country.
thad
SpaceShipOne is fairly unique in that the horizontal tail surfaces are outside the span of the wings. It uses differential movement of these tail surfaces to control roll. At subsonic speeds the pilot controls the elevons at the back of these surfaces, through a fairly normal linkage, but as you get to supersonic speeds the aerodynamic forces become impossible for human strength to overcome. So, at high speeds the front half of the tail control surfaces are moved electrically to generate pitch and roll forces. Apparently one of these electric trim systems failed.
The Bell X-1 used a similar electric trim for pitch, to overcome instabilities going through Mach 1.
Because the elevons on SpaceShipOne control both pitch and roll, Melville was left with no control on two out of three axes at the end of his climb. I cannot imagine how this must have felt, but he recovered with astonishing speed -- and was playing around with floating M&M's a few seconds later. It's unclear to me just what kind of "backup system" he used to control the ship after the trim motor failure, perhaps it was the cold-gas thrusters.
SpaceShipOne depends on still being within the vestiges of the atmosphere for control while the rocket is firing, although the parent poster is correct, control will get sloppy toward the end of the burn as they get above 150,000 ft. The ship has the advantage that it is going very fast indeed at that point, so while there is not a lot of air up there, the forces is generates is more than you would expect.
I was surprised watching the launch that the exhaust plume did not change much during the flight from 50,000 ft to burnout -- I would have expected to see far more expansion as it left the atmosphere -- as you see during a MinuteMan launch, for example. This again points to the ship still being atmosphere of some significant (while small!) density at burnout.
That Mike Melville is one hell of a pilot, his skill and Burt Rutan's innovative feather recovery saved the day. Every previous manned exoatmospheric craft depended on flying an extremely precise attitude before and during re-entry. Failure to maintain this attitude led to the loss of an X-15 and the NF-104 as dramatically recounted in The Right Stuff. SpaceShipOne has no effective attitude control during re-entry, but feathering the wing put the ship into an extremely stable high-drag configuration. Once the ship was subsonic and the wing was folded back into its normal position, the manual control of the elevons was used to fly the ship to a perfect landing.
If you look at SpaceShipOne as it flew yesterday, there was significant work done in the tail booms after the previous flight and prior to this one -- the most obvious change is the installation of a few more camera portholes (presumably with cameras behind them). That's the first place I'd look for the cause of the trim failure.
The launch yesterday was great fun to attend, and I really do think that it will mark a profound change in our access to space.
Thad Beier
I think that these pilots are old fighter jocks, every maneuver they did was right out of the sun. Unfortunately, the people on the ground weren't the enemy, but were the fans :)
:)
It was an awe-inspiring show. It seems the crowds were about the same as those at the Voyager landing in '86 -- my wife joked that they were probably the same people, a little grayer and a little longer in the tooth
thad
I loved the fact that the Scaled Composite site says that "especially kids" are welcome, they want to introduce the next generation to private space flight. I'm taking my 14 year old daughter and two of her friends.
We're currently planning on camping at the Tehachapi glider park Sunday night, then driving to Mojave at 4:00 Monday morning. We'll see if that works -- there is so much publicity here and at other sites that it may be insanely crowded.
I've been a fan of Rutan since the '79 Popular Science cover of the VariEze, and I've got a copy of the plans for his LongEZ (too big a job for me to complete, though...) I have been looking forward to this event for a long time, I can't wait!
Thad
The couldn't find anybody who would sell them the required 90% H202, because they were building rockets. They could buy the stuff, but only if they promised not to build rockets with it.
90% H202 is pretty darn expensive.
The Specific Impulse of H2O2 monopropellant engines is not very high, building an X-Prize vehicle based on H2O2 would be extremely difficult because there just isn't too much ooomph in pure H202.
No flames shoot out the back (this was a problem for Carmack, anyway)
Carmack now uses a combination of 50%-strength H2O2 and some amount of alcohol. As the H2O2 breaks down into steam and oxygen in the first layer of catalyst, the alcohol can burn with the oxygen. This give substantially more specific impulse with much cheaper, readily available fuel.
BEWARE BEWARE BEWARE
Mixing alcohol with hydrogen peroxide is not for the faint of heart. Doing it wrong can yeild disasterous results. As Carmack said of his early experiments, the resulting spectacular explosions "gives one pause." Yeah.
Carmack was encouraged to try again with the mixed monopropellant by somebody who was reading his blog who referred him to German WW2 torpedo propellants. A problem that the Germans had with H2O2 propellants were that the resulting oxygen made bubbles that were easy for the good guys to track. By burning alcohol as well, they would use up the oxygen and be left with water vapor and CO2, both of which dissolve quite readily in seawater. The trick was using just the right concentration of H2O2 and the right proportion of the right kind of alcohol. Many tests were performed to find the optimal mixture. Even so, engineering a rocket engine that would successfully, reliably, and repeatably light off and burn cleanly took many months of quite difficult, not to say disheartening, work.
Congratulations, John -- this flight was a spectacular achievement. May the full-scale vehicle tests go as well.
Thad Beier
I believe it was Mark Twain that said "History doesn't repeat itself, but it rhymes."
Picking on Fred Brooks' TMMM by noting it's anacrhonisms is about the most juvenile thing I can imagine. I can only surmise that the alleged reviewer was forced to read the book by somebody he did not like, and while he read the words he certainly didn't extrapolate the lessons to his present day situations.
When I re-read The Mythical Man Month I can see, in every paragraph, perfect analogies to my work today, and the work I see of other people in other fields. I can't wait to have the reviewer look at The Soul of the New Machine and laugh about how people used to build CPUs out of discrete parts, and how therefore none of the lessons of that book have any applicability today.
Who hasn't seen -- or lived -- an example of Brooks's "The Second System Effect?" The movie that I just finished working on, The Chronicles of Riddick was precisely an example of that paradigm with respect to Pitch Black. Every page of the chapter on The Second System Effect has one-to-one correspondences to the work on this movie.
There are few things that I'm dogmatic about -- but Everybody needs to read this book!
Thad Beier
Well, I should have mentioned that are largest line item, by far, is the animators that drive all of this software. At least on a project of the scale of Riddick, it was best to use software with which our animators would be most productive. For rendering, that means RenderMan. There are many people who have strong experience in writing shaders and doing lighting in RenderMan -- and RenderMan is practically bullet-proof after decades now of work.
We did try a couple of other rendering alternatives. We hoped to be able to use the new Cg shading language to do hardware rendering for some of the shots. We hired an absolute wizard named Hal Bertram to help us with that, but in the end decided that the hardware (at the time) was still not good enough to do final rendering. Interestingly, with the new NV40 chips incorporating Vertex Shader 3.0 and Pixel Shader 3.0 capabilities, almost all of those limitations have been overcome, and we'll be examining hardware rendering anew for our future projects. It seem inevitable to me that in the near future, we will be using hardware rendering for most of our shots -- the quality of what can be rendered with hardware is improving at a breathtaking pace.
We also looked at some other non-free and free (although not open-source) software renderers, some even claiming to be compatible with RenderMan. While they are truly amazing efforts by small teams, we very quickly ran into devastating problems with each of them. I really hate to mention who they are, because they are trying so hard -- but they're not there yet.
One renderer that I'm extremely excited about is Splutterfish's Brazil. It renders some spectacular images mind-bogglingly fast. In particular, it does what has come to be known as "ambient occlusion" so fast that I just can't believe it. Unfortunately, it only runs on the Operating System That Will Not Be Named.
So, in the end, we spent the money for RenderMan to make best use of the really expensive resource, our animators. Having a familiar environment, and one where everything worked every time with no "gotcha's" was worth it. [OK, we did run into some RenderMan surprises...but nothing too serious].
Thad Beier
Hammerhead Productions
thad@hammerhead.com
I think that this is a very valid point -- that as your system gets bigger the decisions have to change. Certainly the bigger you are, the more of a win it becomes to write software, and configure hardware, to your particular needs rather than relying on an off-the-shelf solution.
A big problem with this is that systems that end up really big (hundreds of employees and 500 renderers is really big as far as I'm concerned) don't start out big -- so the decisions and configurations you start with and are optimal when you start become completely wrong when the project grows. I'm quite impressed that you were able to move over to a custom in-house tool when you needed to -- especially as you were surely sweltering in the heat of production as you found Rush to be inadequate.
Thad Beier
Hammerhead Productions
Are you able to tell us which productions were these machines involved in rendering?
These particular machines were just used for The Chronicles of Riddick. Computer technology advances so fast, has lowered in price so quickly, and movie post-production schedules are so long (six to nine months, typically) that we typically don't use any particular machines for more than a couple of films.
Also, in the interest of understanding how much it costs to set up a significant render farm, how much does this sort of thing cost? Is it all in the PCs, or would the backplane infrastructure cost surprise us a lot?
In fact the dominant cost, at least for us, is not the render boxes themselves. The network is a significant expense, as is the data server system. An even larger expense, though, are the licenses for the rendering software. Top-of-the-line rendering systems like RenderMan (for 3D) and Shake (for 2D) cost thousands of dollars per node. And then there are significant infrastructure costs in just electrical wiring and cooling.
At least in the 10-to-50 server range, I would say that the costs are pretty linear. As you get bigger than that, you can start to see some economies of scale.
At some point, it becomes profitable to start developing in-house software tools instead of buying licenses. Digital Domain's Nuke system was originally developed as a renderer for Flame, for example, so that the expensive Flame machines could be used for the interactive work and the batch rendering could happen on commodity hardware. For Riddick, we developed our own smoke-rendering system rather than use RenderMan, to free up render licenses for other parts of the movie.
I'm afraid that an explict cost-per-node breakdown would get into details that we keep confidential, but this should give you an overview of our situation.
Thad Beier
Hammerhead Productions
p.s we don't do Videos, we make Films.
Good questions
1.) The words 'dual' and 'Opteron' both surprised us. We were kind of under the impression that maybe single proc machines would be better for a render farm. We were really curious why dual was chosen over single. Did the extra cost end up being worth it?
The computers are relatively cheap -- it's render licenses (especially for RenderMan) that are expensive. With the newest version of RenderMan, Pixar has deigned to let us use the two processors of a dual-processor machine with a single license. This lowers the cost of rendering by about 60%, if the machine rendered twice as fast with dual processors. In fact, for RenderMan, the Opterons were indeed almost twice as fast, where the Xeons were only about 50% faster.
Our other big rendering application was Shake, and it also allowed the use of two processors with one license.
2.) You mentioned that Opteron was more efficient than Xeons. I just had to ask: Was the particular software you were using particularly tuned to Opteron (i.e. 64-bit?) or was the 32-bit side of it just pleasant to work with? Any more insight you can share with me about the use of Opteron would be most helpful.
Yes and no. The Opterons are the first AMD machines to implement the SSE2 instructions, which are heavily used by RenderMan. Also, the HyperChannel communication between processors on the Opteron is light-years beyond the communication between Athlons and Xeons. On the other hand, there is absolutely no advantage in the 64-bitness of the Opterons -- we were running a 32-bit Linux (RedHat 9), and we weren't using more than 4 GB memory on any of the boxes.
3.) Did you guys end up buying a bunch of machines from a place like IBM or something, or was it more like "we bought the components and assembled ourselves..?" If it's the former, how'd you like the service?
We hired a beige-box manufacturer. We specced it out to various places, and PC Mall built them for the best price. If I had to do it over again, I'm not sure that I wouldn't go with IBM -- while they cost a lot more, I expect that they'd build more solid systems.
4.) Any regrets or things you'd do differently next time around?
We bought minitower machines instead of the more trendy, space- and power-efficient 1U or blade machines. We did that so that we could potentially use the new Gelato renderer from NVidia -- that software uses the current NVidia high-performance graphics cards as an external array processor, giving significantly better render performance.
As we didn't end up using Gelato, that was perhaps a mistake. We ended up power and HVAC constrained in the end -- as happens with almost every renderfarm I've heard of.
5.) Why are you getting rid of the machines used for Riddick? Or did I read that wrong?
No, you read it right. Hammerhead is a small company, typically working on just one show at a time. We don't see a use for the machines for another nine months or so, as we begin development of the next project -- and it just isn't right to leave all that compute horespower idle.
Thad Beier
Hammerhead Productions
I could be wrong, but I thought that Pixar was going to stick with Intel-type machines for the renderfarm, although they are apparently moving to OS X boxes for their animator workstations.
I'm porting all of our animation code from Linux to OS X as well -- more or less as an exercise in code portability -- and it's going pretty well. OS X 10.3 is dramatically more standards- (or at least Linux-) compliant than the earlier OS X versions were. Almost every program I have compiles with virtually no changes. The OpenGL and Glut implementations seem to work perfectly. The only surprise is how far behind the times the Mac graphics cards arel, but few of our programs really need to render 5 million polygons a second.
Thad Beier