King Crimson did the same with their label,
Discipline Global Mobile.
(They're not just King Crimson any more, either. I
believe that John Paul Jones of Led Zeppelin has
signed up with them, too.)
A look at their
business
aims is quite instructive as it sums
up what they think is wrong with the rest of the
industry.
Assuming you're running in a
different protection ring than your interrupt
handlers, and assuming you don't want to use
explicit push and pop instructions, I can't think
of any reason why %esp need be the barrier between
live data and garbage.
I might be wrong. I probably am, in fact. (I
haven't finished my first caffeine of the day,
which is my standard excuse for these sorts of
situations.) Still, I'm
curious as to what these demands are.
Software is often extended beyond its original
spec, this is true. In this era we have some
quite large systems. However, this is also the
era of small throwaway code. I've worked
on all sizes of application, large, medium
and small. In my experience,
large applications are extended but for small
applications, it's often cheaper to throw
them away and rewrite them (cutting and pasting
from the old system as required).
Here's an example: I used to work for a group
which did drug trials. The software to collate
the results of a study often wouldn't last beyond
the life of the study, except in "cut and paste"
form, because the requirements were so different.
These sorts of projects involved a lot of data
which needed to be accessed and reported on
quickly, but even so, they never needed the full
power of an Oracle or DB2. The data was only
used on one site, and if we ever were to lose a
disk it would still be cheaper to restore from
backup and re-enter the lost day's worth than to
buy an Oracle licence. If they did find they
ever needed a high-end DBMS, it won't cost very
much at all to migrate.
BTW, the number one reason why databases like
Oracle are used on small applications is and
probably will always be that there is already an
Oracle licence and a bunch of DBAs in house, and
it's less expensive in terms of resources to get
them do it than to get something new. I don't
have an argument with this, since despite the
usual hammer/nail metaphor, the most
appropriate tool is often the one that you
already know and have.
The -fomit-frame-pointer merely converts frame-pointer-relative
addressing into stack-pointer-relative
addressing, thus saving a register. What I'm talking about is the kind of
optimisation which stores live data above the
stack pointer.
Consider, for example, the following code:
long foo(float p_y) { return (long)p_y; }
At -O8 -march=pentiumpro I get:
pushl %ebp
movl %esp,%ebp
subl $24,%esp ... stuff which uses %ebp...
movl %ebp,%esp
popl %ebp
ret
Adding -fomit-frame-pointer I get:
subl $28,%esp ...stuff which uses %esp...
addl $28,%esp
ret
It successfully eliminated %ebp, but did not
eliminate the sub %esp/add %esp pair even though
there are no calls in the intervening code. The
reason for this is that if a signal is
delivered to the current thread, it will happen
by making a C call frame at the current %esp, so
if there's live data above the top of the stack,
it will be clobbered.
This may not seem too bad a price to pay, but
many nonprocedural languages (mostly functional
and logic languages) do not use a
conventional "call stack" in the same way that C
does, and so could use the built-in stack (or the
built-in stack pointer) for other purposes. No
such luck under Unix, because signal delivery is
by C callback, so you need a valid C stack.
I hate to break this to you, but C is just as
tightly woven into Unix, as anyone who has tried
to implement a compiler for a higher-level language
will tell you.
For example: Suppose your language wants to
manage a stack differently than C does. Suppose,
for example, you want to perform some optimisation
where the stack pointer does not point to the true
end of the stack (say, in a leaf call). Under
Unix, too bad. You need to maintain a true C
stack pointer otherwise signals won't be delivered
properly.
Unix is just as much a C virtual machine as the
Symbolics devices were Lisp virtual machines.
Oracle has been used for a lot of projects where it doesn't really need to be used, usually because the company already had a licence, but sometimes because the project was way over-spec'd.
Don't get me wrong, MySQL doesn't even come close to challenging the benefits of Oracle or DB2 in replication, scalability and so on. However, in applications where you don't need them, MySQL is perfect, especially because it requires no monetary investment. (It requires other kinds of investment, of course, but everything does.)
The other thing which the RIAA won't mention
is that DVD sales have gone up by a lot in
the last two years. I believe the Australian
figure is something like a 70% increase in the
last 18 months alone. One factor in the steadying
of CD sales is almost certainly due to the fact
that there are more forms of entertainment but
only so much budget to go around.
I couldn't agree more. If, after sitting down
for 15-30 mins in a bookstore's cafe with the
book, I buy it only to take it home only to find
it's not worth owning, I really only
have myself to blame. Either it was expensive, in
which case I didn't investigate
it thoroughly enough before buying, or it was
cheap, in which case I haven't lost much.
One proviso, though. Who in their right
mind buys hardcovers?:-)
Well why don't you just demand to render
reality while you're at it?
Nobody in the entertainment industry wants to
render reality. That's because there is nothing
at all real about movies.
No scene has 1000 lights, by the way, unless
you're generating lights automatically from a
HDR light probe image. We're talking on the scale
of a hundred or so here, compared with the ten or
so which modern video cards can handle.
I doubt even Monsters Inc. had
4poly/pixel.
alking on the scale
of a hundred or so here, compared with the ten or
so which modern video cards can handle.
BTW, a hundred or so lights is not uncommon
on a big traditional movie set, either.
I doubt even Monsters Inc. had
4poly/pixel.
Actually, Monsters Inc ran at some
Actually, Monsters Inc ran at somewhat over one
polygon per pixel. PRMan dices curved
primitives down to one polygon per pixel as part
of the rendering process. The figure is
configurable on a per-object basis, and it's
automatically less for highly blurred objects
(e.g. objects which are out of focus or moving),
but this is made up for by culling around
silhouette edges rendering more layers.
Of course, more geometry than this actually
goes into the pipeline. About 2Gb gzipped is
a typical size, according to Tom Duff; more if
there's a lot of LOD (e.g. the room full of
doors).
It is true that the way most animation is done today is by motion capture, but it is also possible to simulate characters entirely digitally.
Not even close. Most animation today is done
the same way it has for most of the 20th century:
Analyse the motion of things in the "real world",
then try to copy it as well as you can.
Motion capture is used, just like traditional
cel animators (and visual effects artists) have
always used rotoscoping since Disney pioneered the
technique. It's not "most", though.
Kubrick is dead. He died before post-production
was completed on that film. I think that Eyes Wide
Shut isn't a good example here for two reasons
relating to this.
The first problem is that Kubrick was not around
to defend himself. The studio saying "Kubrick would
have wanted it this way" is nowhere near as
powerful as Kubrick himself making the same claim,
especially in the face of commercial pressures of
an expensive film featuring two of the hottest
actors in the business at the time.
Second is that I don't think Eyes Wide Shut
was edited quite the way he would have wanted it
regardless. I know that when I first saw it
(international version, without the "Austin Powers"
version of the orgy scene), I had
worked out the big secret half an hour before
it was revealed, and was almost literally looking
at my watch in the intervening time. That's
never happened to me with my first viewing of
a Kubrick film before. I suspect that if some of
the trademark "nothing time" had been edited down
a bit more, my brain would have been sufficiently
occupied that the ending would have affected me
better. I further
suspect that Kubrick knew this, and filmed too
much because he didn't know which bit of "nothing
time" was best to cut down until he saw it in
situ. (All screenwriters and directors know
this, by the way. Average-length shooting scripts
are almost always 20 pages too long, which gives
the editor some room.)
Having said that, I agree with the rest of your
post.:-)
I'm not sure which Cathedral and the Bazaar
you read, but the one by ESR likened commercial software
development to the cathedral and open software
development to the bazaar. The terms "cathedral"
and "bazaar" refer only to the
process by which software is developed.
The issue which CatB addresses is the belief that software that wasn't
carefully designed and controlled would have lower
quality than software which was. ESR's response was
that for the most measures of "quality" (robustness,
bug-freeness and so on) bazaar-developed code could
actually be better. The price you may
pay is that the scope of the software, may change from
what you originally intended it to be (e.g. fetchmail).
On the other hand, it may well be better than you
intended.
The claim from Pixar included copyright, trade secret and patent violations.
The patent which Pixar claims that ExLuna violated is basically
a couple of traditional Monte Carlo integration variance reduction
strategies applied to pixel filtering, which many in the industry believe
to be a completely bogus patent. (Much like the rest
of Pixar's patent portfolio, in fact, possibly
excluding patents relating the CHAP processor. I digress.)
Larry deliberately removed this from BMRT (which did
once support stochastic sampling) and Entropy was
deliberately built on a different scheme. ExLuna
did apply for patents on their technology precisely
because they thought something like this might happen.
High-end modelling and rendering is an area where the
"big boys" have a lot of patents, something which
the "little boys" (like Hammerhead and also my former
employers, Dot C) are constantly angry about.
As an aside, Aqsis,
the pre-eminent open source RenderMan-based renderer
(and probably the only free one left now that BMRT is dead in the water),
uses N-rooks Monte Carlo sampling which, while not
officially mentioned in the Pixar patent, and not
used by Pixar as far as I know, could be
considered "derivative work" if it ever came to
court (depending on how nasty the patent holder's
lawyers were). We don't need to be worried yet
because Aqsis doesn't really compete in the same
arena.
The trade secret and copyright violation charges
are harder to deal with. The three main founders of
ExLuna are ex-Pixar employees and all worked on PRMan
in various capacities. Without seeing the source,
and knowing exactly what the "trade secret" stuff
is, there's no real way for an external observer to
tell whether the claims have any merit or not.
Add to all of this that all of the features
which were Entropy's strong points (combined
ray tracing and scanline rendering, global
illumination) are going into the next version
of Pixar's renderer, due out later this year.
I should add that competing with Entropy
probably isn't the reason why the features are
going in. More likely is that Pixar is trying
to compete with Blue Sky Studios, whose in-house
renderer (used on Ice Age) already has
them. In the end, PRMan is designed for Pixar's
needs first and the wider market second.
What I conclude from all this is that the
answer one of the original questions, "How do I
get into CGI?" must include the following maxim:
Never work for Pixar unless you plan to
change fields as soon as you leave there.
Yes, GC usually does not slow down your code. (That is, what you gain in the ability to use better algorithms is usually greater than the cost of running a garbage collector.)
However:
It does not solve all of your memory problems. C++ still lets you write out of the end of memory blocks. (Not that you should be using C-style arrays in C++ if you can at all avoid it.)
It does not interact well with several well-used C++ idioms, such as the resource acquisition is object creation idiom.
The latter, IMO, is the more serious of the two. If an object holds a resource, then until it is destroyed, the resource is held. Even the best general-purpose garbage collectors you can find today do not guarantee a maximum time between an object becoming unreferenced and being cleaned up. This goes double for conservative GC, where the resource might not be freed until everything which looks like a pointer to the resource-holding object disappears.
So in summary: I'm a big fan of GC, but it doesn't solve all my problems, and that's especially true in C++.
Why would any alien intelligence capable of interstellar travel would choose to communicate using circles in corn but apparently not be able to figure out binary, or radio.
With all due respect to John Carmack, I have to wonder what basis he has to make these remarks.
To be fair, "rendering" encompasses a lot of jobs across the industry. For example, there's a whole subfield of the CGI industry colloquially known as "flying logos", which may be a good candidate for hardware rendering in the medium term. However, certainly anything which has to be combined with a live plate will not have its final render done in special-purpose graphics hardware any time soon.
First, even before the end of next year, PC graphics cards will not have the level of filtering required for even a simple CGI element.
Secondly, rendering isn't as big a cost of the production pipeline as most people think, compared with modelling, animation, physical simulation, lighting and compositing. This is especially true when you consider that renders don't require human interaction, so can happen at night.
Thirdly, consider Blinn's Law. For the uninitiated, it's the converse of Moore's Law. Hardware may double in power every N months, but audience expectation rises just as fast. You will have to upgrade, and it's cheaper and easier to upgrade software than hardware, both for the developers and users of the products.
The thing that annoyed me the most, though, is this comment:
There will always be some market for the finest possible rendering, using ray tracing, global illumination, etc in a software renderer.
The fact is that the overwhelming majority of CGI effects elements today use neither ray tracing nor global illumination. Even in those rare circumstances when they do, it's often used in combination with traditional scanline renderers. One setup, for example, is to let the scanline renderer call out to a ray tracer to handle secondary rays. Another is to render the same geometry using a scanline renderer and using a ray tracer then composite the results.
Shaders as they will soon be commonly used in games are designed for making stuff look better than the Lambertian model. Shaders as they are used in visual effects and animation are designed for flexibility.
The biggest limitation on what you in the visual effects and animation businesses is smart and talented people. People cost more than hardware and more than software. Anything which can more effectively use "people time" is much better than anything which can more effectively use CPU cycles.
Therefore, in a perfect world (which doesn't always happen when you have tight deadlines and tight budgets), shaders are written in such a way that artists use their time the best. So, for example, you don't require that texture person to paint "colour" on that dinosaur, you let them paint "mud" or "wound". It's the same difference between logical markup and physical markup.
In the games world, I suspect that this level flexibility isn't quite so important as effective utilisation of the graphics hardware.
This, in conjunction with Blinn's Law, is one reason why games shaders and visual effects/animation shaders won't converge for a long time yet, though they will overlap.
1984 is many things: a satire, a comment on human nature, a questioning of the nature of government, a cautionary tale... but not a prediction.
Orwell's vision of Ingsoc will probably never happen, but the themes behind it will exist in every society.
One of the things which particularly impressed me was the role of war in the total state. Ingsoc started with nuclear war and relied on a constant state of war against a faceless enemy in order to survive, because it gave everyone a common enemy and hence a common purpose, even though the roles of "friend" and "enemy" could flip at a moment's notice, not that the population cared.
Compare with the modern US "war on [insert abstract concept here]" mentality and the relevance should be obvious.
One has a feeling that regexp engines are just becoming programming languages in and of themselves [...]
Not true. Yet.
Perl 5 regexes can solve NP-hard problems, but they're not quite Turing complete. However, they require only four additional stack operators to do that.
Personally, I'm waiting for the first Perl regex to become sentient.
Slashdot Mirror
King Crimson did the same with their label, Discipline Global Mobile. (They're not just King Crimson any more, either. I believe that John Paul Jones of Led Zeppelin has signed up with them, too.)
A look at their business aims is quite instructive as it sums up what they think is wrong with the rest of the industry.
How do you figure that?
Assuming you're running in a different protection ring than your interrupt handlers, and assuming you don't want to use explicit push and pop instructions, I can't think of any reason why %esp need be the barrier between live data and garbage.
I might be wrong. I probably am, in fact. (I haven't finished my first caffeine of the day, which is my standard excuse for these sorts of situations.) Still, I'm curious as to what these demands are.
Software is often extended beyond its original spec, this is true. In this era we have some quite large systems. However, this is also the era of small throwaway code. I've worked on all sizes of application, large, medium and small. In my experience, large applications are extended but for small applications, it's often cheaper to throw them away and rewrite them (cutting and pasting from the old system as required).
Here's an example: I used to work for a group which did drug trials. The software to collate the results of a study often wouldn't last beyond the life of the study, except in "cut and paste" form, because the requirements were so different. These sorts of projects involved a lot of data which needed to be accessed and reported on quickly, but even so, they never needed the full power of an Oracle or DB2. The data was only used on one site, and if we ever were to lose a disk it would still be cheaper to restore from backup and re-enter the lost day's worth than to buy an Oracle licence. If they did find they ever needed a high-end DBMS, it won't cost very much at all to migrate.
BTW, the number one reason why databases like Oracle are used on small applications is and probably will always be that there is already an Oracle licence and a bunch of DBAs in house, and it's less expensive in terms of resources to get them do it than to get something new. I don't have an argument with this, since despite the usual hammer/nail metaphor, the most appropriate tool is often the one that you already know and have.
The -fomit-frame-pointer merely converts frame-pointer-relative addressing into stack-pointer-relative addressing, thus saving a register. What I'm talking about is the kind of optimisation which stores live data above the stack pointer.
Consider, for example, the following code:
At -O8 -march=pentiumpro I get:
Adding -fomit-frame-pointer I get:
It successfully eliminated %ebp, but did not eliminate the sub %esp/add %esp pair even though there are no calls in the intervening code. The reason for this is that if a signal is delivered to the current thread, it will happen by making a C call frame at the current %esp, so if there's live data above the top of the stack, it will be clobbered.
This may not seem too bad a price to pay, but many nonprocedural languages (mostly functional and logic languages) do not use a conventional "call stack" in the same way that C does, and so could use the built-in stack (or the built-in stack pointer) for other purposes. No such luck under Unix, because signal delivery is by C callback, so you need a valid C stack.
I hate to break this to you, but C is just as tightly woven into Unix, as anyone who has tried to implement a compiler for a higher-level language will tell you.
For example: Suppose your language wants to manage a stack differently than C does. Suppose, for example, you want to perform some optimisation where the stack pointer does not point to the true end of the stack (say, in a leaf call). Under Unix, too bad. You need to maintain a true C stack pointer otherwise signals won't be delivered properly.
Unix is just as much a C virtual machine as the Symbolics devices were Lisp virtual machines.
...most people don't need Oracle.
Oracle has been used for a lot of projects where it doesn't really need to be used, usually because the company already had a licence, but sometimes because the project was way over-spec'd.
Don't get me wrong, MySQL doesn't even come close to challenging the benefits of Oracle or DB2 in replication, scalability and so on. However, in applications where you don't need them, MySQL is perfect, especially because it requires no monetary investment. (It requires other kinds of investment, of course, but everything does.)
The other thing which the RIAA won't mention is that DVD sales have gone up by a lot in the last two years. I believe the Australian figure is something like a 70% increase in the last 18 months alone. One factor in the steadying of CD sales is almost certainly due to the fact that there are more forms of entertainment but only so much budget to go around.
I couldn't agree more. If, after sitting down for 15-30 mins in a bookstore's cafe with the book, I buy it only to take it home only to find it's not worth owning, I really only have myself to blame. Either it was expensive, in which case I didn't investigate it thoroughly enough before buying, or it was cheap, in which case I haven't lost much.
One proviso, though. Who in their right mind buys hardcovers? :-)
Ah, but does it work with next year's "Pixar render farm in a box" video cards which we keep hearing all that hype about?
God no. Not in a high-end renderer. That's what proper filtering is for.
Nobody in the entertainment industry wants to render reality. That's because there is nothing at all real about movies.
No scene has 1000 lights, by the way, unless you're generating lights automatically from a HDR light probe image. We're talking on the scale of a hundred or so here, compared with the ten or so which modern video cards can handle.
alking on the scale of a hundred or so here, compared with the ten or so which modern video cards can handle.BTW, a hundred or so lights is not uncommon on a big traditional movie set, either.
Actually, Monsters Inc ran at some
Actually, Monsters Inc ran at somewhat over one polygon per pixel. PRMan dices curved primitives down to one polygon per pixel as part of the rendering process. The figure is configurable on a per-object basis, and it's automatically less for highly blurred objects (e.g. objects which are out of focus or moving), but this is made up for by culling around silhouette edges rendering more layers.
Of course, more geometry than this actually goes into the pipeline. About 2Gb gzipped is a typical size, according to Tom Duff; more if there's a lot of LOD (e.g. the room full of doors).
Not even close. Most animation today is done the same way it has for most of the 20th century: Analyse the motion of things in the "real world", then try to copy it as well as you can.
Motion capture is used, just like traditional cel animators (and visual effects artists) have always used rotoscoping since Disney pioneered the technique. It's not "most", though.
Absolutely spot on.
I'm not entirely sure what people think that CGI animators, TDs and so on do all day. Just push a button and out comes a film?
I guess there really is a physical cap on Moore's Law.
The speed of light is only so fast... and it's only going to get worse.
Just a quick comment on Eyes Wide Shut.
Kubrick is dead. He died before post-production was completed on that film. I think that Eyes Wide Shut isn't a good example here for two reasons relating to this.
The first problem is that Kubrick was not around to defend himself. The studio saying "Kubrick would have wanted it this way" is nowhere near as powerful as Kubrick himself making the same claim, especially in the face of commercial pressures of an expensive film featuring two of the hottest actors in the business at the time.
Second is that I don't think Eyes Wide Shut was edited quite the way he would have wanted it regardless. I know that when I first saw it (international version, without the "Austin Powers" version of the orgy scene), I had worked out the big secret half an hour before it was revealed, and was almost literally looking at my watch in the intervening time. That's never happened to me with my first viewing of a Kubrick film before. I suspect that if some of the trademark "nothing time" had been edited down a bit more, my brain would have been sufficiently occupied that the ending would have affected me better. I further suspect that Kubrick knew this, and filmed too much because he didn't know which bit of "nothing time" was best to cut down until he saw it in situ. (All screenwriters and directors know this, by the way. Average-length shooting scripts are almost always 20 pages too long, which gives the editor some room.)
Having said that, I agree with the rest of your post. :-)
I'm not sure which Cathedral and the Bazaar you read, but the one by ESR likened commercial software development to the cathedral and open software development to the bazaar. The terms "cathedral" and "bazaar" refer only to the process by which software is developed.
The issue which CatB addresses is the belief that software that wasn't carefully designed and controlled would have lower quality than software which was. ESR's response was that for the most measures of "quality" (robustness, bug-freeness and so on) bazaar-developed code could actually be better. The price you may pay is that the scope of the software, may change from what you originally intended it to be (e.g. fetchmail). On the other hand, it may well be better than you intended.
The claim from Pixar included copyright, trade secret and patent violations.
The patent which Pixar claims that ExLuna violated is basically a couple of traditional Monte Carlo integration variance reduction strategies applied to pixel filtering, which many in the industry believe to be a completely bogus patent. (Much like the rest of Pixar's patent portfolio, in fact, possibly excluding patents relating the CHAP processor. I digress.) Larry deliberately removed this from BMRT (which did once support stochastic sampling) and Entropy was deliberately built on a different scheme. ExLuna did apply for patents on their technology precisely because they thought something like this might happen. High-end modelling and rendering is an area where the "big boys" have a lot of patents, something which the "little boys" (like Hammerhead and also my former employers, Dot C) are constantly angry about.
As an aside, Aqsis, the pre-eminent open source RenderMan-based renderer (and probably the only free one left now that BMRT is dead in the water), uses N-rooks Monte Carlo sampling which, while not officially mentioned in the Pixar patent, and not used by Pixar as far as I know, could be considered "derivative work" if it ever came to court (depending on how nasty the patent holder's lawyers were). We don't need to be worried yet because Aqsis doesn't really compete in the same arena.
The trade secret and copyright violation charges are harder to deal with. The three main founders of ExLuna are ex-Pixar employees and all worked on PRMan in various capacities. Without seeing the source, and knowing exactly what the "trade secret" stuff is, there's no real way for an external observer to tell whether the claims have any merit or not.
Add to all of this that all of the features which were Entropy's strong points (combined ray tracing and scanline rendering, global illumination) are going into the next version of Pixar's renderer, due out later this year. I should add that competing with Entropy probably isn't the reason why the features are going in. More likely is that Pixar is trying to compete with Blue Sky Studios, whose in-house renderer (used on Ice Age) already has them. In the end, PRMan is designed for Pixar's needs first and the wider market second.
What I conclude from all this is that the answer one of the original questions, "How do I get into CGI?" must include the following maxim:
OK, first, what we seem to agree on...
However:
The latter, IMO, is the more serious of the two. If an object holds a resource, then until it is destroyed, the resource is held. Even the best general-purpose garbage collectors you can find today do not guarantee a maximum time between an object becoming unreferenced and being cleaned up. This goes double for conservative GC, where the resource might not be freed until everything which looks like a pointer to the resource-holding object disappears.
So in summary: I'm a big fan of GC, but it doesn't solve all my problems, and that's especially true in C++.
Dreamworks was making Anime five years ago. Doesn't anyone remember Invasion America?
Why would any alien intelligence capable of interstellar travel would choose to communicate using circles in corn but apparently not be able to figure out binary, or radio.
With all due respect to John Carmack, I have to wonder what basis he has to make these remarks.
To be fair, "rendering" encompasses a lot of jobs across the industry. For example, there's a whole subfield of the CGI industry colloquially known as "flying logos", which may be a good candidate for hardware rendering in the medium term. However, certainly anything which has to be combined with a live plate will not have its final render done in special-purpose graphics hardware any time soon.
First, even before the end of next year, PC graphics cards will not have the level of filtering required for even a simple CGI element.
Secondly, rendering isn't as big a cost of the production pipeline as most people think, compared with modelling, animation, physical simulation, lighting and compositing. This is especially true when you consider that renders don't require human interaction, so can happen at night.
Thirdly, consider Blinn's Law. For the uninitiated, it's the converse of Moore's Law. Hardware may double in power every N months, but audience expectation rises just as fast. You will have to upgrade, and it's cheaper and easier to upgrade software than hardware, both for the developers and users of the products.
The thing that annoyed me the most, though, is this comment:
The fact is that the overwhelming majority of CGI effects elements today use neither ray tracing nor global illumination. Even in those rare circumstances when they do, it's often used in combination with traditional scanline renderers. One setup, for example, is to let the scanline renderer call out to a ray tracer to handle secondary rays. Another is to render the same geometry using a scanline renderer and using a ray tracer then composite the results.
The Perfect Storm was some time ago, in visual effects terms. You might want to check out the digital water in Orange County and see if you like that.
Shaders as they will soon be commonly used in games are designed for making stuff look better than the Lambertian model. Shaders as they are used in visual effects and animation are designed for flexibility.
The biggest limitation on what you in the visual effects and animation businesses is smart and talented people. People cost more than hardware and more than software. Anything which can more effectively use "people time" is much better than anything which can more effectively use CPU cycles.
Therefore, in a perfect world (which doesn't always happen when you have tight deadlines and tight budgets), shaders are written in such a way that artists use their time the best. So, for example, you don't require that texture person to paint "colour" on that dinosaur, you let them paint "mud" or "wound". It's the same difference between logical markup and physical markup.
In the games world, I suspect that this level flexibility isn't quite so important as effective utilisation of the graphics hardware.
This, in conjunction with Blinn's Law, is one reason why games shaders and visual effects/animation shaders won't converge for a long time yet, though they will overlap.
1984 is many things: a satire, a comment on human nature, a questioning of the nature of government, a cautionary tale... but not a prediction.
Orwell's vision of Ingsoc will probably never happen, but the themes behind it will exist in every society.
One of the things which particularly impressed me was the role of war in the total state. Ingsoc started with nuclear war and relied on a constant state of war against a faceless enemy in order to survive, because it gave everyone a common enemy and hence a common purpose, even though the roles of "friend" and "enemy" could flip at a moment's notice, not that the population cared.
Compare with the modern US "war on [insert abstract concept here]" mentality and the relevance should be obvious.
Not true. Yet.
Perl 5 regexes can solve NP-hard problems, but they're not quite Turing complete. However, they require only four additional stack operators to do that.
Personally, I'm waiting for the first Perl regex to become sentient.