Actually, you can restrict future versions of software released under License X, provided that you own the copyright to all the code in the project.
For example, let's say Company A makes Program 1.0, and releases it under the GPL. Everyone likes the program, people use the GPL'ed code to make new programs, etc. Then, the OS-friendly management gets replaced by some unscrupulous types, and they decide to make Program 1.1 closed source.
Now, provided that they own all the copyrights to the Program 1.1 code, they can do this. They cannot, however, go back and sue the people still using the Program 1.0 source code that was released under the GPL. And, if somebody outside the company made improvements to Program 1.0 that were then rolled into the Program 1.1 code, then Company A would not own all the copyrights to the Program 1.1 code (unless the person who wrote the improvements signed over the copyright), and would therefor not be able to make Program 1.1 closed-source.
You make it sound like they just optimized their drivers for Doom 3 or something.
The most probable cause of the GeForce 6800 GT's beating of the top-of-the-line x800 card is the fact that the 6800 can do more stencil buffer operations per pass than the x800 can.
And since Doom 3 uses the stencil buffer for rendering shadows, the 6800 gets better performance in Doom 3 than the x800.
But to make it sound as if that is a Doom 3-specific optimization is misleading. Future games, such as those based on the Unreal 3 engine, will also benefit from it.
John Carmack is a little biased towards nVidia, but not in the way that you are suggesting.
For example, he has said in the past (I'm paraphrasing), "When I'm trying something new on nVidia hardware, and it doesn't come out right, I can be pretty sure that the problem is with me. On the other hand, on ATI hardware, I have to wonder, 'Am I doing something wrong, or is the problem with ATI's drivers?'"
So, basically, it sounds (to me, anyway) like John Carmack prefers nVidia cards purely from an engineering and programming standpoint.
Well, the XBox has a modified GeForce3, and the XBox port's developers have said that they have had to scale back many aspects of the game. These included sound (since the XBox has only 64MB RAM), texture resolution, polygon counts, and some other things.
Unfortunately, when you buy an Alienware a lot of your money goes towards the Alienware name.
Back in February I bought a new computer. I built it by myself, with parts gotten entirely from NewEgg.com
For $2500 I got: P4 @ 2.8 ghz 1GB RAM (PC3700, I think; it's been a while) GeForce FX 5950 120GB Maxtor HD 74GB Western Digital 10000RPM Raptor DVD+RW CD-RW Antec case (don't remember the model) 400W power supply 19" ViewSonic G90fb Miscellaneous stuff (keyboard, mouse, cables, etc.)
All for $2500. Do you really think you'd be able to get that much from Alienware for the same price?
You realize that only the GeForce 6800 Ultra requires 2 molex connectors and an extra PCI slot, right?
The GeForce 6800 GT takes up only one slot and has but one molex connector. And yet, somehow, it still beats ATI's fastest, greatest card that costs $100 more.
I find it kind of interesting that #12 is "Portability is for Canoes". He basically goes on about how you shouldn't worry about portability, because it adds too much overhead. He also goes on to mention that only large companies can handle developing software for more than one platform.
Kind of figures, considering the guy is a Microsoft employee.
The difference is that, with pixel shaders, you aren't necessarily tracing rays of light.
A per-pixel polygon shader is just that: a small program that gets run for every pixel of that polygon on the screen. That says absolutely nothing about what lighting method is used.
Now, that pixel shader can do raytracing, but simply being a pixel shader doesn't mean that raytracing is being done. The pixel shader could instead do shadow mapping or something.
Raytracing is just what it sounds like: you literally trace the path of the light rays in the scene. As you can imagine, this process is very computationally expensive, which is why it isn't done often. Major Hollywood VFX firms have only recently begun to put it into limited use.
A much faster method, and the method that is used in pretty much every game (with exceptions being Doom 3, HL2, Far Cry, and some other recent or soon-to-be-released games that use some variant of shadow mapping or shadow volumes), is to just calculate the relation of the polygon's normal to the light's direction, and increase or decrease the brightness of the polygon based on that. In other words, the more a polygon is angled away from the light source, the darker it is. If it faces completely away from the light, then it is completely in shadow.
To get shadows in those games, the shadows are usually just faked. Black polygons on the ground directly under the object, etc.
The method used for VFX in most movies to date is called shadow mapping. Basically, with this method you render (at least) two images for every frame: one from the light's position (the shadow map), and one from the camera's position. For the image taken from the light's position, which is grayscale, you base each pixel's brightness on how far away it is from the light, so that the brighter it is the closer it is to the light. No tracing of light rays takes place, just some distance calculations. Then, when you render the image from the camera's position, you just calculate each pixel's corresponding location in the shadow map, and use that to determine whether the pixel is in the light or in shadow, and color it accordingly. Again, no tracing of light rays is done, just distance calculations and such.
Even in games like Doom 3 and Half Life 2 ray tracing is not done. While it might be possible to do low-quality raytracing on a GPU, the quality would probably be so low that you'd get better looking results from some other method.
The poster I was replying to was bitching about road construction and repair being subsidized by taxes, and that if roadways were to compete fairly with trains then the taxes should be eliminated and replaced with toll roads instead.
He was implying that the government subsidizing things like road construction and repair was unfair to the train system.
In my oppinion his idea is a bad one. I'm sorry, but I'm not going to pay a toll so that I can drive to work, or go to the movies, or see some friends, or go on a road trip, simply because it's "unfair" to the passenger rail system.
Nowhere did I say that companies that ship goods on those roadways weren't competing against the freight train companies. Those companies are in competition, and they should be in competition. But the roadways themselves don't really compete against the rail system, at least not in the same sense that a company that ships by truck competes against a company that ships by rail, nor should they.
The World Wide Web != The Internet. The internet already existed when the WWW was invented, and the WWW sits atop the internet. HTTP runs over the top of TCP/IP.
Why should the roadways, which are public property on public land, have to "compete" with trains? I'm glad I live in the Southwestern US, where toll roads are practically unheard of.
As for trains, I don't see why everyone is so gung-ho about them. Here in Phoenix a light rail system (like the one that's getting built) is essentially worthless, since the city is so spread out. There's just no way they could have stops everywhere you need to go in Phoenix, at least not without spending a ridiculous amount of money and making surface street traffic worse than it already is. And Phoenix is not the kind of city where you want to have to walk several blocks to get where you need to be after leaving the train.
Besides, having roadways "compete" against trains and airlines just hurts the economy, since tolls and increased fuel taxes increase a company's operating costs, which increases prices. And it discourages ordinary citizens from using our vast interstate highway system. No more impromptu road trips, always having to worry about whether you've brought enough toll money, possibly waiting in long lines to pay the toll. No thanks.
Until a project decides not to put it's.pc files in the standard place. For instance, when installing Clanlib on my Gentoo system (using Portage, no less), the.pc files didn't get put in/usr/lib/pkgconfig (which is where pkg-config expects them to be on Gentoo).
Instead they got put in/usr/lib/clanlib-0.7.7, and when I tried to build a program that used pkg-config to find clanlib, the build broke. If I were a Linux newbie, I'd probably have just given up rather than try to find the.pc files that I knew were installed.
I really don't want to get into some kind of PKG_CONFIG=$PKG_CONFIG:/some/directory:/some/other/directory:/yet/another/directory mess.
Well, yes, CVS is obviously better than SCCS and raw RCS.
But some things about it really suck. Like individual versioning on files, thanks to its lack of atomic commits. Or the fact that it has a hard time dealing with file and directory renaming and changes to the project's directory layout.
I recommend Subversion to anyone looking for an open-source source code control system. It does atomic commits, so if one part of the check in fails, the whole thing is aborted, to make sure that partial check ins can't happen (let's say changes made to File A depend on changes made to File B; what would happen if File A gets checked in OK, but File B doesn't? How fast can you get the conflicts in File B fixed and checked in?). It also handles file and directory renames in a civilized manner, so that if your project's source code grows beyond your initial layout you can fix it without a lot of headaches (at least, not any headaches stemming from Subversion).
As to your remarks about how much easier CVS is, I'd like to remind you that Subversion is basically supposed to be "a better CVS" (and does it quite well, IMHO), and as such the commands are intentionally very similar to CVS. After first installing Subversion, and having never used it before, I was up and running in less than 5 minutes.
I'd like to see the results of the same test run with a 2.6 kernel.
Also, people should pick a file system that suits that task at hand: -XFS was designed for handling large files quickly, and on a file system where most of the files are at least a few megabytes in size, XFS will reign supreme.
-ReserFS, on the other hand, is excellent for file systems with lots and lots of small files.
-ext2 is still useful. For instance, there's no need for journalling in/tmp.
-ext3, at least under 2.6, is a decent desktop file system. While not the fastest, it's reliable, and its performance in the 2.6 kernels is much better than in the 2.4 kernels. It should be sufficient for most desktop file system needs.
As to file system reliability, from what I've heard, all the major file systems are pretty solid in the 2.6 kernel.
I don't remember what Doom you played, but the Doom that I played was dark and full of atmosphere and suspense. It didn't turn into an all-out actionfest until the last half of the game.
The same with Quake. In fact, looking at my Quake box, most of the praise seems to be going towards the game's atmosphere and scariness. You remember how dark the game was, right? You remember Trent Reznor's creepy soundtrack, right? You remember monsters jumping out at you from the shadows, right?
It's unfortunate, but id Software seems to be in a "damned if they do, damned if they don't" situation. If they focus on making the game scary and atmospheric (which would necessitate a slower pace and fewer enemies), people bitch that it's not very Doom-like, but if they focus on mindless action then people bitch that they should focus on things besides that.
Case-in-point: Penny Arcade. After Doom 3's first E3 showing: "The new Doom 3 engine looks great. I can't wait until somebody makes a good game with it." Then a while later (days?): "Doom 3 won't be room after room of zombies? How un-Doom-like."
Well, if you're worried about having to cut other programs, tell your Congress critters that you want them to try and get the "Revisit the moon and start a permanent base there" thing cut.
From a scientific value going back to the Moon and starting a permanent base there is nearly worthless, it doesn't help us learn how to get to Mars, and it would free up a lot of money that could be spent on the manned Mars mission or some other worthwhile NASA program.
I'm wondering what personal pet project of his Dr Chaikin would rather see the money saved from not sending humans into space go towards.
Are we really content to just sit here on Earth and send machines off to see the rest of the universe? Are we content to say, "Well, yeah, we could've gone to Mars, but it wasn't safe"?
I think the answer to anyone who says we should stop sending people into space should be, "Well, when people stop wanting to go, we'll stop sending them." I mean, I'd be the first one to volunteer to go to Mars.
When it comes to actually landing on a planet and having a look around, a human (equipped with the necessary scientific instruments) could do a much better job than a robotic probe. The Spirit rover spent, what, a week just sitting there after landing because the JPL guys had to decide the best way to get it off the landing pad without it getting stuck? A human on Mars would have no such trouble.
And, of course, having humans on Mars would settle once and for all whether or not NASA's coloration of the Mars Rover images was accurate or not;)
What about programs like Maya, which have the capacity to store the entire creation history of an object? In Maya keeping at least some of an object's construction history is important.
Especially since Maya's file format is basically just a listing of the MEL commands that were used to create the object in the first place (in Maya, every action, tool, etc., generates a MEL (Maya Embedded Language) command, and it's the MEL command that actually performs the action).
Really, this is bound to fail. They'd have to create a very large feature set in order to accomodate every need of every program, and that means the only to routes they can go are thus: 1)Have a small, core set of required features and a larger set of optional features. or 2)Have a large set of required features
Obviously, #2 won't work. It just doesn't make sense for a program that only uses polygons to have to worry about things like NURBS, subdivision surfaces, etc.
However, #1 isn't that great either. This is because there will inevitably be some programs that don't implement some of the optional features that other programs do implement, rendering this new format useless as a "universal" format.
What's more, somebody will inevitably implement some of the features in a nonstandard way. Do you really think Microsoft wants to play nice and for once doesn't have any ulterior motives?
As the old adage goes, "You can please some of the people all of the time, or all of the people some of the time, but you cannot please all of the people all of the time." The same goes for file formats.
As to multi-dimensional arrays, MEL isn't meant for heavy computation or anything like that. And I don't really see the need for extensive string manipulation functions, since MEL isn't meant to be a general purpose language.
Rather, MEL is more of a support/glue language. Do you have some menial task that you keep doing over and over? Write a MEL script that does the same thing, and make an icon for it on the shelf. Have you gone to the trouble of modelling a head for a character and all the different blend shapes necessary for facial animation? Moving the individual blend shape sliders can be a pain, especially since (when the blend shapes for facial animation are done properly) the sliders often adjust blendshapes that are related. So you can just write a MEL script that creates a little dialog box that has one slider (instead of 3) that controls the smile-related blendshapes, etc.
As to using XML for doing UI stuff, why would you want to? You need the ability to associate scripting actions with buttons, separate your code into various functions, etc., and since XML isn't actually a scripting language I don't see how that'd be possible. Never mind the fact that nearly the entire Maya UI is written in MEL, and that every action you perform in Maya actually just generates (and then executes) one or more MEL commands.
I am aware that real-time does not mean "really fast."
There are many aspects of Java that mean you can't guarantee a response within a certain timeframe. Garbage collection, for example.
My remark about it being an interpreted language just meant that there isn't necessarily a 1:1 instruction translation of the JVM's bytecode, and therefor you can't know beyond a shadow of a doubt that a certain operation will get done in a certain amount of time.
The remark about the 20mhz thing (the CPUs on the two MERs run at 20mhz) had nothing to do with Java not being suitable for real-time applications. Rather, I was just stating that Java would be really slow on such a system.
Java is only used on the ground. They'd be stupid to use it in the flight software.
That isn't a slight against Java. It's just that they need real-time software, which can't be had with an interpreted language (even if it is only interpreted from bytecode).
How fast do you think a 20mhz processor could run a Java app?
Slashdot Mirror
No, I got the point.
In fact, I specifically said that they cannot go back and sue somebody who's using the code for Program 1.0, since it is, and will always be, GLP'ed.
Actually, you can restrict future versions of software released under License X, provided that you own the copyright to all the code in the project.
For example, let's say Company A makes Program 1.0, and releases it under the GPL. Everyone likes the program, people use the GPL'ed code to make new programs, etc. Then, the OS-friendly management gets replaced by some unscrupulous types, and they decide to make Program 1.1 closed source.
Now, provided that they own all the copyrights to the Program 1.1 code, they can do this. They cannot, however, go back and sue the people still using the Program 1.0 source code that was released under the GPL. And, if somebody outside the company made improvements to Program 1.0 that were then rolled into the Program 1.1 code, then Company A would not own all the copyrights to the Program 1.1 code (unless the person who wrote the improvements signed over the copyright), and would therefor not be able to make Program 1.1 closed-source.
You make it sound like they just optimized their drivers for Doom 3 or something.
The most probable cause of the GeForce 6800 GT's beating of the top-of-the-line x800 card is the fact that the 6800 can do more stencil buffer operations per pass than the x800 can.
And since Doom 3 uses the stencil buffer for rendering shadows, the 6800 gets better performance in Doom 3 than the x800.
But to make it sound as if that is a Doom 3-specific optimization is misleading. Future games, such as those based on the Unreal 3 engine, will also benefit from it.
According to the article, neither nVidia nor ATI had access to the demo prior to the benchmark.
John Carmack is a little biased towards nVidia, but not in the way that you are suggesting.
For example, he has said in the past (I'm paraphrasing), "When I'm trying something new on nVidia hardware, and it doesn't come out right, I can be pretty sure that the problem is with me. On the other hand, on ATI hardware, I have to wonder, 'Am I doing something wrong, or is the problem with ATI's drivers?'"
So, basically, it sounds (to me, anyway) like John Carmack prefers nVidia cards purely from an engineering and programming standpoint.
Well, the XBox has a modified GeForce3, and the XBox port's developers have said that they have had to scale back many aspects of the game. These included sound (since the XBox has only 64MB RAM), texture resolution, polygon counts, and some other things.
Unfortunately, when you buy an Alienware a lot of your money goes towards the Alienware name.
Back in February I bought a new computer. I built it by myself, with parts gotten entirely from NewEgg.com
For $2500 I got:
P4 @ 2.8 ghz
1GB RAM (PC3700, I think; it's been a while)
GeForce FX 5950
120GB Maxtor HD
74GB Western Digital 10000RPM Raptor
DVD+RW
CD-RW
Antec case (don't remember the model)
400W power supply
19" ViewSonic G90fb
Miscellaneous stuff (keyboard, mouse, cables, etc.)
All for $2500. Do you really think you'd be able to get that much from Alienware for the same price?
You realize that only the GeForce 6800 Ultra requires 2 molex connectors and an extra PCI slot, right?
The GeForce 6800 GT takes up only one slot and has but one molex connector. And yet, somehow, it still beats ATI's fastest, greatest card that costs $100 more.
I find it kind of interesting that #12 is "Portability is for Canoes". He basically goes on about how you shouldn't worry about portability, because it adds too much overhead. He also goes on to mention that only large companies can handle developing software for more than one platform.
Kind of figures, considering the guy is a Microsoft employee.
BSD was Free as in speech, but it wasn't free as in beer. To get the source code from Berkely cost several hundred dollars IIRC.
The difference is that, with pixel shaders, you aren't necessarily tracing rays of light.
A per-pixel polygon shader is just that: a small program that gets run for every pixel of that polygon on the screen. That says absolutely nothing about what lighting method is used.
Now, that pixel shader can do raytracing, but simply being a pixel shader doesn't mean that raytracing is being done. The pixel shader could instead do shadow mapping or something.
Raytracing is just what it sounds like: you literally trace the path of the light rays in the scene. As you can imagine, this process is very computationally expensive, which is why it isn't done often. Major Hollywood VFX firms have only recently begun to put it into limited use.
A much faster method, and the method that is used in pretty much every game (with exceptions being Doom 3, HL2, Far Cry, and some other recent or soon-to-be-released games that use some variant of shadow mapping or shadow volumes), is to just calculate the relation of the polygon's normal to the light's direction, and increase or decrease the brightness of the polygon based on that. In other words, the more a polygon is angled away from the light source, the darker it is. If it faces completely away from the light, then it is completely in shadow.
To get shadows in those games, the shadows are usually just faked. Black polygons on the ground directly under the object, etc.
The method used for VFX in most movies to date is called shadow mapping. Basically, with this method you render (at least) two images for every frame: one from the light's position (the shadow map), and one from the camera's position. For the image taken from the light's position, which is grayscale, you base each pixel's brightness on how far away it is from the light, so that the brighter it is the closer it is to the light. No tracing of light rays takes place, just some distance calculations. Then, when you render the image from the camera's position, you just calculate each pixel's corresponding location in the shadow map, and use that to determine whether the pixel is in the light or in shadow, and color it accordingly. Again, no tracing of light rays is done, just distance calculations and such.
Even in games like Doom 3 and Half Life 2 ray tracing is not done. While it might be possible to do low-quality raytracing on a GPU, the quality would probably be so low that you'd get better looking results from some other method.
I hope this answers your question.
What the fuck are you on about?
The poster I was replying to was bitching about road construction and repair being subsidized by taxes, and that if roadways were to compete fairly with trains then the taxes should be eliminated and replaced with toll roads instead.
He was implying that the government subsidizing things like road construction and repair was unfair to the train system.
In my oppinion his idea is a bad one. I'm sorry, but I'm not going to pay a toll so that I can drive to work, or go to the movies, or see some friends, or go on a road trip, simply because it's "unfair" to the passenger rail system.
Nowhere did I say that companies that ship goods on those roadways weren't competing against the freight train companies. Those companies are in competition, and they should be in competition. But the roadways themselves don't really compete against the rail system, at least not in the same sense that a company that ships by truck competes against a company that ships by rail, nor should they.
The World Wide Web != The Internet. The internet already existed when the WWW was invented, and the WWW sits atop the internet. HTTP runs over the top of TCP/IP.
Why should the roadways, which are public property on public land, have to "compete" with trains? I'm glad I live in the Southwestern US, where toll roads are practically unheard of.
As for trains, I don't see why everyone is so gung-ho about them. Here in Phoenix a light rail system (like the one that's getting built) is essentially worthless, since the city is so spread out. There's just no way they could have stops everywhere you need to go in Phoenix, at least not without spending a ridiculous amount of money and making surface street traffic worse than it already is. And Phoenix is not the kind of city where you want to have to walk several blocks to get where you need to be after leaving the train.
Besides, having roadways "compete" against trains and airlines just hurts the economy, since tolls and increased fuel taxes increase a company's operating costs, which increases prices. And it discourages ordinary citizens from using our vast interstate highway system. No more impromptu road trips, always having to worry about whether you've brought enough toll money, possibly waiting in long lines to pay the toll. No thanks.
Until a project decides not to put it's .pc files in the standard place. For instance, when installing Clanlib on my Gentoo system (using Portage, no less), the .pc files didn't get put in /usr/lib/pkgconfig (which is where pkg-config expects them to be on Gentoo).
/usr/lib/clanlib-0.7.7, and when I tried to build a program that used pkg-config to find clanlib, the build broke. If I were a Linux newbie, I'd probably have just given up rather than try to find the .pc files that I knew were installed.
r /directory:/yet/another/directory mess.
Instead they got put in
I really don't want to get into some kind of PKG_CONFIG=$PKG_CONFIG:/some/directory:/some/othe
Well, yes, CVS is obviously better than SCCS and raw RCS.
But some things about it really suck. Like individual versioning on files, thanks to its lack of atomic commits. Or the fact that it has a hard time dealing with file and directory renaming and changes to the project's directory layout.
I recommend Subversion to anyone looking for an open-source source code control system. It does atomic commits, so if one part of the check in fails, the whole thing is aborted, to make sure that partial check ins can't happen (let's say changes made to File A depend on changes made to File B; what would happen if File A gets checked in OK, but File B doesn't? How fast can you get the conflicts in File B fixed and checked in?). It also handles file and directory renames in a civilized manner, so that if your project's source code grows beyond your initial layout you can fix it without a lot of headaches (at least, not any headaches stemming from Subversion).
As to your remarks about how much easier CVS is, I'd like to remind you that Subversion is basically supposed to be "a better CVS" (and does it quite well, IMHO), and as such the commands are intentionally very similar to CVS. After first installing Subversion, and having never used it before, I was up and running in less than 5 minutes.
I'd like to see the results of the same test run with a 2.6 kernel.
/tmp.
Also, people should pick a file system that suits that task at hand:
-XFS was designed for handling large files quickly, and on a file system where most of the files are at least a few megabytes in size, XFS will reign supreme.
-ReserFS, on the other hand, is excellent for file systems with lots and lots of small files.
-ext2 is still useful. For instance, there's no need for journalling in
-ext3, at least under 2.6, is a decent desktop file system. While not the fastest, it's reliable, and its performance in the 2.6 kernels is much better than in the 2.4 kernels. It should be sufficient for most desktop file system needs.
As to file system reliability, from what I've heard, all the major file systems are pretty solid in the 2.6 kernel.
I don't remember what Doom you played, but the Doom that I played was dark and full of atmosphere and suspense. It didn't turn into an all-out actionfest until the last half of the game.
The same with Quake. In fact, looking at my Quake box, most of the praise seems to be going towards the game's atmosphere and scariness. You remember how dark the game was, right? You remember Trent Reznor's creepy soundtrack, right? You remember monsters jumping out at you from the shadows, right?
It's unfortunate, but id Software seems to be in a "damned if they do, damned if they don't" situation. If they focus on making the game scary and atmospheric (which would necessitate a slower pace and fewer enemies), people bitch that it's not very Doom-like, but if they focus on mindless action then people bitch that they should focus on things besides that.
Case-in-point: Penny Arcade. After Doom 3's first E3 showing: "The new Doom 3 engine looks great. I can't wait until somebody makes a good game with it." Then a while later (days?): "Doom 3 won't be room after room of zombies? How un-Doom-like."
Well, if you're worried about having to cut other programs, tell your Congress critters that you want them to try and get the "Revisit the moon and start a permanent base there" thing cut.
From a scientific value going back to the Moon and starting a permanent base there is nearly worthless, it doesn't help us learn how to get to Mars, and it would free up a lot of money that could be spent on the manned Mars mission or some other worthwhile NASA program.
I'm wondering what personal pet project of his Dr Chaikin would rather see the money saved from not sending humans into space go towards.
;)
Are we really content to just sit here on Earth and send machines off to see the rest of the universe? Are we content to say, "Well, yeah, we could've gone to Mars, but it wasn't safe"?
I think the answer to anyone who says we should stop sending people into space should be, "Well, when people stop wanting to go, we'll stop sending them." I mean, I'd be the first one to volunteer to go to Mars.
When it comes to actually landing on a planet and having a look around, a human (equipped with the necessary scientific instruments) could do a much better job than a robotic probe. The Spirit rover spent, what, a week just sitting there after landing because the JPL guys had to decide the best way to get it off the landing pad without it getting stuck? A human on Mars would have no such trouble.
And, of course, having humans on Mars would settle once and for all whether or not NASA's coloration of the Mars Rover images was accurate or not
What about programs like Maya, which have the capacity to store the entire creation history of an object? In Maya keeping at least some of an object's construction history is important.
Especially since Maya's file format is basically just a listing of the MEL commands that were used to create the object in the first place (in Maya, every action, tool, etc., generates a MEL (Maya Embedded Language) command, and it's the MEL command that actually performs the action).
Really, this is bound to fail. They'd have to create a very large feature set in order to accomodate every need of every program, and that means the only to routes they can go are thus:
1)Have a small, core set of required features and a larger set of optional features.
or
2)Have a large set of required features
Obviously, #2 won't work. It just doesn't make sense for a program that only uses polygons to have to worry about things like NURBS, subdivision surfaces, etc.
However, #1 isn't that great either. This is because there will inevitably be some programs that don't implement some of the optional features that other programs do implement, rendering this new format useless as a "universal" format.
What's more, somebody will inevitably implement some of the features in a nonstandard way. Do you really think Microsoft wants to play nice and for once doesn't have any ulterior motives?
As the old adage goes, "You can please some of the people all of the time, or all of the people some of the time, but you cannot please all of the people all of the time." The same goes for file formats.
As to multi-dimensional arrays, MEL isn't meant for heavy computation or anything like that. And I don't really see the need for extensive string manipulation functions, since MEL isn't meant to be a general purpose language.
Rather, MEL is more of a support/glue language. Do you have some menial task that you keep doing over and over? Write a MEL script that does the same thing, and make an icon for it on the shelf. Have you gone to the trouble of modelling a head for a character and all the different blend shapes necessary for facial animation? Moving the individual blend shape sliders can be a pain, especially since (when the blend shapes for facial animation are done properly) the sliders often adjust blendshapes that are related. So you can just write a MEL script that creates a little dialog box that has one slider (instead of 3) that controls the smile-related blendshapes, etc.
As to using XML for doing UI stuff, why would you want to? You need the ability to associate scripting actions with buttons, separate your code into various functions, etc., and since XML isn't actually a scripting language I don't see how that'd be possible. Never mind the fact that nearly the entire Maya UI is written in MEL, and that every action you perform in Maya actually just generates (and then executes) one or more MEL commands.
...to all the Slashbots rambling about how we should do all movies as CG with nothing but CG sets and (eventually) nothing but CG actors.
Of course, the fact that they're wrong won't stop them from posting.
I am aware that real-time does not mean "really fast."
There are many aspects of Java that mean you can't guarantee a response within a certain timeframe. Garbage collection, for example.
My remark about it being an interpreted language just meant that there isn't necessarily a 1:1 instruction translation of the JVM's bytecode, and therefor you can't know beyond a shadow of a doubt that a certain operation will get done in a certain amount of time.
The remark about the 20mhz thing (the CPUs on the two MERs run at 20mhz) had nothing to do with Java not being suitable for real-time applications. Rather, I was just stating that Java would be really slow on such a system.
Java is only used on the ground. They'd be stupid to use it in the flight software.
That isn't a slight against Java. It's just that they need real-time software, which can't be had with an interpreted language (even if it is only interpreted from bytecode).
How fast do you think a 20mhz processor could run a Java app?