I think it would be great to run that first series again, just for the comedy value.
Did you mean the science or Maxine Gray's fashion sense?
Re:yeah, sure... right...
on
AI Movie Promo
·
· Score: 2
...and you think that one of these ten billion brain cells interconnected with dozens or even hundreds of others responding to many different electrical and chemical stimuli in complex ways equals one byte?
In storage capacity, yes. In processing power, no. Hence my comment about FPGA arrays.
Think about it: the human brain contains ten billion brain cells. It's not too expensive today to buy a machine with 8Gb or more of RAM in it. So we already have the storage capacity. A modern computer, if suitably programmed, could simulate a brain, only much slower. (Prohibitively slower, in fact.)
What you really need is something which is more massively parallel. Think FPGAs. Think ten billion nodes. That would give you the processing power of the human brain. Ten years before such arrays are in use at the high-end, twenty years before it's on everyone's desk.
motion is easy... just fire the cameras in series instead of all at once. same tech, same concept.
Actually, it's much harder. It'd be easy (or at least "straightforward") if the cameras fired at exactly the right time, but in practice, because the shutter is mechanical, there is an element of randomness. All this needs to be corrected... manually. When it's a still (or when you're faking a little motion like in Lost in Space) you don't notice the jitter as much, but when it's smooth slow motion, you really notice it.
Also, most of the reviewers are just plain old readers, like yours truly. Plus I'm in a country that didn't get it delivered until a few months ago. Oh, and the review sat in the/. queue for over a month. (I'm pretty sure that timothy spaces them out so we get about one book review a week instead of "as they come".)
So the moral of the story is: don't expect/. book reviews to be "timely".
These days, you have to watch the 'making of' on television, an ad masquerading as a documentary before the film's released.
Actually, I like those. Any film with a "making of" documentary tends to be of such poor quality that all the good bits are in the documentary, so you don't have to see the film.
My employers supplied some of the rendering software used by one of the effects houses on Matrix, and we'll be doing the same for Matrix 2 and 3. (I'm supplying a shader compiler which will most likely be used too.)
In the highly unlikely event that I find out anything you'd be interested in (I may find out what local illumination model on the buildings in Zion, but who cares, right?) and I'm actually allowed to say it, I'll attempt to fill you in. No promises, though. The NDAs are pretty tight in this business.
Remember that a light year describes a distance (the distance light travels in a year) and not a time span.
That accurately describes the standard Western European time metaphor. The model that we use is that we're standing on a time line, walking forward as time elapses. That's why we say "it was a long way ahead" referring to a span of time, or we are "forward looking" if we think about the future and "backward looking" if we think about the past, and it's why we "face the future".
If you think about it, the time metaphor that we use doesn't make sense. You can't see into the future, but you can see into the past. That's why some cultures (from memory, and I could be wrong about this, Chinese and some Australian Aboriginal cultures do this) have as their metaphor that you're walking along a time line backwards. Presumably in their buzzword-laden corporate cultures, if they have them, someone who looks to the future is "backward-looking".:-)
If the problem with Unix is that it's 30 years old... Mach (and other kernels like it, such as pre-version-4 NT) is over 10 years old. As microkernels go, it's considered to be quite bloated nowadays.
If you want to see a kernel that's truly modern in design, look at Chorus, QNX or BeOS.
The point is not to win the tech war
on
CPRM Voted Down
·
· Score: 5
You're right that we can't win a technological arms race with big business. CPRM will probably get implemented.
What we can do is win the PR war. It's interesting that you bring up Ralph Nader. He won the PR war against businesses years ago. He turned enough people against companies producing consumer products which play fast-and-loose with people's safety that in the end, the government and business had to stand up and take notice.
That's where we need to concentrate our efforts, IMO. We can't win the technology in the short term, but if we do it right, we can win the hearts and minds.
I find that I write the best code while "in the zone."
I do too, I must admit, but the code that I do write "in the zone" tends to be the most in need of a code review when I'm done.
And really, that's all pair programming is. It's a very tight code review loop. We all know code reviews are good, so let's do it all the time, even while coding. Pair programming is code review taken to extreme. Everything in "extreme programming" is actually stuff we already know is good taken to extremes, hence the name.
I think part of the problem is that we're coming from different domains here. My company writes software for people putting images onto film. (Visual effects, mostly.) Therefore we need to handle the huge dynamic range of film. People playing Quake don't need that.
And going to a higher resolution DOES solve the aliasing problem. Take a 2048x1536 picture, shrink it to 256x192. Display both full-screen. See the jaggies in the smaller one? Those diagonal lines were just as rough at high resolution, but the pixels were smaller and less obvious. Once the size of a pixel drops below our visible threshold we won't see that anymore.
If the scene that the 2048x1536 image was meant to represent has even higher frequencies in it and that image was not properly filtered, you will see aliasing problems. Especially if this is an animation frame, or if there are fine objects such as hair or fur (although shrinking it properly, using a sinc or Catmull-Rom reconstruction filter will help this a lot). This is particularly noticable in the early films which used CGI (I'm thinking in particular of The Last Starfighter). They rendered larger and then shrunk the frame down for printing onto the film plates. For the most part it looks okay, but you can often see "sparkling" around the edges or on complex textures, because regular sampling never removes aliasing, it just moves it up a few octaves. Modern renderers don't do that. They use stochastic sampling instead, which also doesn't get rid of aliasing, but it does convert it to random noise, which is less visually objectionable than aliasing.
[Aside: I noticed the "sparklies" in the opening battle scene of Lost in Space when I saw it in the theatre, and you really notice it in cheap TV effects, like the first series of Babylon 5 or pretty much all of SeaQuest DSV.]
Worse than aliasing, though, that is the fact that it simply wastes computing resources. If your shading is properly filtered (for OpenGL that would include properly filtered mipmapped textures; for offline rendering that would include analytic integration), you don't need the higher sampling rates everywhere, only where it matters. The computrons that you expend on rendering at a higher resolution could be spent on more complex models, which would pay off better for realism. By comparison, Pixar reports that faithfully modelling a typical room in a house requires about 2Gb of compressed model data. For a game, you wouldn't need quite that much, of course.
One thing that's misunderstood about Moore's Law when it comes to computer graphics is that peoples' expectations increase as computing power increases. Nowadays, we can do Doom at 85 frames per second, but people don't want Doom, they want Quake 3. Which means that to keep up with both you need to work smarter rather than harder.
But, how does wanting 16bpcc (color channel) require a monitor capable of 256 times more light output? The problem is that if you display 256 equal width bars of a color across the screen they appear as distinct bars. That's with 8bpcc. So wouldn't it be nice if you could draw 65536 (or rather, as many as you had lines of resolution) different shades of a single color across the screen to avoid the banding?
First off, I said that 16bpcc would only be useful if you had a monitor capable of more light output. I stand by that. (Note: 256 is too much, of course.:-) What you really want is 0-4095 be equivalent to the current 0-255, and the rest as headroom.)
As for 256 equal width bars appearing as distinct bars: of course they will. The human eye always looks for discontinuities, causing the Mach banding effect. What you have here is an aliasing problem. Just like going to a higher resolution doesn't solve spatial aliasing problems (I can see the jaggies on the sides of polygons when I play Quake at 1600x1200, which is better than HDTV), going to a higher colour resolution doesn't solve colour quantisation aliasing problems either. You really need something like stochastic sampling to hide the aliasing behind noise. In this case, you need dithering.
I've heard Hollywood typically uses 48bpp for the special effects graphics, and there's some 16bpc (bit per channel) features in GIMP and Photoshop, but I don't know much more about how we're advancing for hardware support there. I just want better colors!
Unless you're working with film, you don't need it. Eight bits per channel is adequate, and will remain so until we have monitors that can deliver 256 times the amount of light that current ones can.
I've posted twocomments on this topic previously. Go have a read.
Having said that, one place where we really need more precision is in the intermediate buffers of OpenGL (e.g. the accumulation buffer). But what you want there is floating point pixels.
Considering the number of wars that have happened during slashdot's history, and the number still happening now, I think we can conclude that for the next few wars at least, slashdot would be no help at all, and would be largely unaffected by it.
Or were you referring to a war affecting the slashdot editors? Geez, if someone invaded Jon Katz' territory we'd never hear the end of it...
War in the United States ain't gonna happen any time in the forseeable future. Nobody's going to invade the country with the world's most bloated millitary budget, and the likelihood of revolution of any kind, second amendment or no second amendment, is as close to zero as it's possible to be. (If the well-trained militia were really going to overthrow the government for being tyrranical, it'd have happened by now.)
One of the problems I find is that by the time the USA gets around to April 1st, it's almost over elsewhere in the world. The jokes tend to wear thin after a couple of days of them.
Slashdot Mirror
Did you mean the science or Maxine Gray's fashion sense?
In storage capacity, yes. In processing power, no. Hence my comment about FPGA arrays.
That sounds about right. We're on track, too.
Think about it: the human brain contains ten billion brain cells. It's not too expensive today to buy a machine with 8Gb or more of RAM in it. So we already have the storage capacity. A modern computer, if suitably programmed, could simulate a brain, only much slower. (Prohibitively slower, in fact.)
What you really need is something which is more massively parallel. Think FPGAs. Think ten billion nodes. That would give you the processing power of the human brain. Ten years before such arrays are in use at the high-end, twenty years before it's on everyone's desk.
It's not too fantastic, when you think about it.
Even before that, The Truman Show had a web site which was supposedly the activist group campaigning to free Truman. It's gone now.
Actually, it's much harder. It'd be easy (or at least "straightforward") if the cameras fired at exactly the right time, but in practice, because the shutter is mechanical, there is an element of randomness. All this needs to be corrected... manually. When it's a still (or when you're faking a little motion like in Lost in Space) you don't notice the jitter as much, but when it's smooth slow motion, you really notice it.
"Pseudonym" isn't my real name, either.
Of course. But I figured I should declare my potential conflict of interest anyway.
Yes they did. I submitted the link along with the review.
However, ThinkGeek now has a link back to the review. Work that one out, conspiracy theorists...
For the record, I have no financial interest in the book, and my employers got paid a flat fee for the rendering software they provided for the film.
And think to yourself: If Pseudonym did not like the film, would he have bought the book?
Also, most of the reviewers are just plain old readers, like yours truly. Plus I'm in a country that didn't get it delivered until a few months ago. Oh, and the review sat in the /. queue for over a month. (I'm pretty sure that timothy spaces them out so we get about one book review a week instead of "as they come".)
So the moral of the story is: don't expect /. book reviews to be "timely".
As Mick Molloy once pointed out, it was just like the mechanical Sam Neill in Jurassic Park. You could almost think it was lifelike...
Actually, I like those. Any film with a "making of" documentary tends to be of such poor quality that all the good bits are in the documentary, so you don't have to see the film.
Not yet. :-)
My employers supplied some of the rendering software used by one of the effects houses on Matrix, and we'll be doing the same for Matrix 2 and 3. (I'm supplying a shader compiler which will most likely be used too.)
In the highly unlikely event that I find out anything you'd be interested in (I may find out what local illumination model on the buildings in Zion, but who cares, right?) and I'm actually allowed to say it, I'll attempt to fill you in. No promises, though. The NDAs are pretty tight in this business.
That accurately describes the standard Western European time metaphor. The model that we use is that we're standing on a time line, walking forward as time elapses. That's why we say "it was a long way ahead" referring to a span of time, or we are "forward looking" if we think about the future and "backward looking" if we think about the past, and it's why we "face the future".
If you think about it, the time metaphor that we use doesn't make sense. You can't see into the future, but you can see into the past. That's why some cultures (from memory, and I could be wrong about this, Chinese and some Australian Aboriginal cultures do this) have as their metaphor that you're walking along a time line backwards. Presumably in their buzzword-laden corporate cultures, if they have them, someone who looks to the future is "backward-looking". :-)
If the problem with Unix is that it's 30 years old... Mach (and other kernels like it, such as pre-version-4 NT) is over 10 years old. As microkernels go, it's considered to be quite bloated nowadays.
If you want to see a kernel that's truly modern in design, look at Chorus, QNX or BeOS.
You're right that we can't win a technological arms race with big business. CPRM will probably get implemented.
What we can do is win the PR war. It's interesting that you bring up Ralph Nader. He won the PR war against businesses years ago. He turned enough people against companies producing consumer products which play fast-and-loose with people's safety that in the end, the government and business had to stand up and take notice.
That's where we need to concentrate our efforts, IMO. We can't win the technology in the short term, but if we do it right, we can win the hearts and minds.
I do too, I must admit, but the code that I do write "in the zone" tends to be the most in need of a code review when I'm done.
And really, that's all pair programming is. It's a very tight code review loop. We all know code reviews are good, so let's do it all the time, even while coding. Pair programming is code review taken to extreme. Everything in "extreme programming" is actually stuff we already know is good taken to extremes, hence the name.
I think part of the problem is that we're coming from different domains here. My company writes software for people putting images onto film. (Visual effects, mostly.) Therefore we need to handle the huge dynamic range of film. People playing Quake don't need that.
If the scene that the 2048x1536 image was meant to represent has even higher frequencies in it and that image was not properly filtered, you will see aliasing problems. Especially if this is an animation frame, or if there are fine objects such as hair or fur (although shrinking it properly, using a sinc or Catmull-Rom reconstruction filter will help this a lot). This is particularly noticable in the early films which used CGI (I'm thinking in particular of The Last Starfighter). They rendered larger and then shrunk the frame down for printing onto the film plates. For the most part it looks okay, but you can often see "sparkling" around the edges or on complex textures, because regular sampling never removes aliasing, it just moves it up a few octaves. Modern renderers don't do that. They use stochastic sampling instead, which also doesn't get rid of aliasing, but it does convert it to random noise, which is less visually objectionable than aliasing.
[Aside: I noticed the "sparklies" in the opening battle scene of Lost in Space when I saw it in the theatre, and you really notice it in cheap TV effects, like the first series of Babylon 5 or pretty much all of SeaQuest DSV.]
Worse than aliasing, though, that is the fact that it simply wastes computing resources. If your shading is properly filtered (for OpenGL that would include properly filtered mipmapped textures; for offline rendering that would include analytic integration), you don't need the higher sampling rates everywhere, only where it matters. The computrons that you expend on rendering at a higher resolution could be spent on more complex models, which would pay off better for realism. By comparison, Pixar reports that faithfully modelling a typical room in a house requires about 2Gb of compressed model data. For a game, you wouldn't need quite that much, of course.
One thing that's misunderstood about Moore's Law when it comes to computer graphics is that peoples' expectations increase as computing power increases. Nowadays, we can do Doom at 85 frames per second, but people don't want Doom, they want Quake 3. Which means that to keep up with both you need to work smarter rather than harder.
First off, I said that 16bpcc would only be useful if you had a monitor capable of more light output. I stand by that. (Note: 256 is too much, of course. :-) What you really want is 0-4095 be equivalent to the current 0-255, and the rest as headroom.)
As for 256 equal width bars appearing as distinct bars: of course they will. The human eye always looks for discontinuities, causing the Mach banding effect. What you have here is an aliasing problem. Just like going to a higher resolution doesn't solve spatial aliasing problems (I can see the jaggies on the sides of polygons when I play Quake at 1600x1200, which is better than HDTV), going to a higher colour resolution doesn't solve colour quantisation aliasing problems either. You really need something like stochastic sampling to hide the aliasing behind noise. In this case, you need dithering.
I'm gonna go cybersquat on vabsd.com right now.
Two languages, both alike in dignity, in fair Cambridge where we set our scene...
Unless you're working with film, you don't need it. Eight bits per channel is adequate, and will remain so until we have monitors that can deliver 256 times the amount of light that current ones can.
I've posted two comments on this topic previously. Go have a read.
Having said that, one place where we really need more precision is in the intermediate buffers of OpenGL (e.g. the accumulation buffer). But what you want there is floating point pixels.
Considering the number of wars that have happened during slashdot's history, and the number still happening now, I think we can conclude that for the next few wars at least, slashdot would be no help at all, and would be largely unaffected by it.
Or were you referring to a war affecting the slashdot editors? Geez, if someone invaded Jon Katz' territory we'd never hear the end of it...
War in the United States ain't gonna happen any time in the forseeable future. Nobody's going to invade the country with the world's most bloated millitary budget, and the likelihood of revolution of any kind, second amendment or no second amendment, is as close to zero as it's possible to be. (If the well-trained militia were really going to overthrow the government for being tyrranical, it'd have happened by now.)
One of the problems I find is that by the time the USA gets around to April 1st, it's almost over elsewhere in the world. The jokes tend to wear thin after a couple of days of them.