Um, it's the economists who keep yelling at us to not run such an enormous deficit. It's the "people" who keep voting for their precious government programs that keep running up the debt.
Of course, you do realize that understanding economics has little to do with knowing which companies will be successful? That takes a business man's mind, not an economist's.
Compared to modeling for a movie? Yes it is. Games have much less demanding geometry, rather simple shaders, and have most effects done in the engine rather than in the modeler. 3D Studio is an excellent program, but it's optimized for this sort of work (eg: good polygon reduction tools), rather than for more quality-intensive work.
Re:Why no comparison with D3D?
on
OpenGL 2.0 Released
·
· Score: 2, Insightful
Uber-buffers hasn't been thought-through all the way yet. They're trying to make sure that they can design something that lasts, and something that fits the new 3D-accelerated paradigm that seems imminent. I think the point is that they'd rather do it right by implementing uber-buffers properly, than just put render-to-texture in there for the sake of keeping up. This is especially true considering that you can already to render-to-texture using WGL_ARB_pbuffer and GL_SGIX_pbuffer, which are pretty well-supported.
I don't know why I should even bother replying to you --- your argument is patently ridiculous at face value. It's completely illogical --- you provide no evidence to support your view that economists' theories are "half baked." All you say is that their jobs are not on the line, which has no logical bearing on the validity of their theories!
But I'll indulge you anyway. What kind of economic super genius are you to call their theories half-baked? Even Samuelson points out that globalization has helped us so far, just as economic theory has predicted for 100 years. He's proposing a new wrinkle in the existing theory. The existing theory is well-established, well-supported, and very far from "half baked."
Hmm, I knew this would come up. When I say "US education system" I'm talking about the one most Americans go too --- our public K-12 system. Only 21% of Americans have taken any college courses, and only 15% have a college degree. The other 80-85% attend our attrocious public K-12 schools.
Yes, our university system is one of the best in the world, and we have a couple of top-notch high-schools, but it's not the Harvard and Yale folks who are out of a job...
If you read the whole article, you'll see this isn't true. He won his Nobel Prize for his work showing how internationalization can help make a rich country. He notes that until now, globalization has helped us, rather than hurt us. He just tries to make the qualification that globalization doesn't *necessarily* always lead to benefits, as most economists believe.
His statement is quite a bit mroe subtle than you can put in "simplified terms." Basically, his point is that while the traditional theories of comparative advantage hold, it is possible that certain types of trade can cause you to loose your comparative advantage.
Makes sense, but I'll reserve judgement until the majority of economists have had a chance to weigh in on it.
Like most things, the truth is probably somewhere in the middle. That is, of course, fallacious reasoning. A common fallacy, but a fallacy nonetheless.
Has it occurred to you that we're losing our edge, not because outsourcing, but because we haven't been working very hard to keep it? Our education system is in shambles, our young people are complete morons, and we as a culture pretty much revile the educated and glorify the average.
This has been a long time coming, and outsourcing is a symptom, not a cause.
Yes, but id software is a major and high-profile supplier of engines. Each OpenGL-based engine they release leads to a whole host of OpenGL-supporting games.
3DS MAX is also a modeler primarly aimed at gaming and other lightweight work.
Re:Why no comparison with D3D?
on
OpenGL 2.0 Released
·
· Score: 2, Informative
OpenGL isn't OOP because it's a procedural API, low-level API. DirectX isn't really OO either --- it just happens to use objects. If you want an OO interface to OpenGL, you should use a proper scene graph library.
I don't think that the ARB has really dropped the ball on render-to-texture. As it is implemented in current systems, it's really not a general solution. If you look at the OpenGL uber-buffers proposal, you'll find that render-to-texture is just a feature of what could be a much more powerful and general memory model for OpenGL. I think the real holdup is that they'd rather do this right, by generalizing the memory model, than to add a special-case feature like render-to-texture.
That's not even close to being a good comparison. Cg is a vendor-proprietory language not a cross-vendor language. You don't see Cg for ATI cards, no do you? DirectX is a platform-specific API, not a cross-platform API. On top of that, it's optimized for gaming, not professional applications. In any case, GLSL came out last year, so at worst, you can say that OpenGL was a year behind Direct3D in getting a high-level shading language.
Personally, I've used both D3D and OpenGL, and find D3D to be a horribly designed API, with massive changes in each revision. I'd much rather get OpenGL a year later, but designed right, than the D3D hack of the day.
Re:Um, is this news item accurate?
on
OpenGL 2.0 Released
·
· Score: 4, Informative
Um, what do you think OpenGL 2.0 is? It's a specification.
Well, obviously, if your implementation doesn't have a good 3D engine, you won't be able to use the new apps that require one. X.org will continue to support non-3D systems, of course, and if the apps draw through Cairo, the X server will use software-emulated RENDER instead of OpenGL. If software-emulated RENDER isn't fast enough, and you don't have OpenGL acceleration, then you probably shouldn't be trying to run such a graphically-rich application on your machine.
Video drivers cannot accelerate GDI+ because they are never given an oppurtunity to. You're wrong about that. Drivers *can* accelerate GDI+. See this article.
I don't beleve you. You don't have to believe me. It's a simple fact that most software only utilizes the most basic parts of the GDI. Show me where on your desktop you see Bezier curves? XP themes, for example, just use pixmaps that are blitted to the screen --- curves aren't actually drawn using the hardware.
Eh? As you said before, video output is human consumable data, not designed to be reconsumed by the computer. How can an application depend on it? Let me put this in concrete terms: GDI, I can draw a line that, according to the semantics of the GDI, passes through 10,20, then draw a white pixel at 10,20 to erase that part of the line, and expect it to work. I shouldn't be able to do this, but that doesn't change the fact that existing GDI applications are coded with this assumption. If you treat video as human consumable, rather than computer-consumable, output (as you should), your API has to specify from the beginning (as OpenGL does), that you cannot make these sorts of assumptions.
How can Avalon break those semantics yet retain compatibility but GDI cannot? Because existing GDI apps won't draw through Avalon. It's okay to break the semantics in a new API, because new apps are aware of the new semantics.
Here is an example of GDI being resolution-independent: printer drivers are just another type of display driver. The same is true of drawing APIs for X too, and in both cases apps writing to the printer know to expect a resolution independent interface. Apps written for screen display don't know this. Let me give you another concrete example:
Qt's QPainter has similar semantics to the GDI. QPainter can draw to the screen, or to the display, and can have a coordinate transform. Yet, it is common in applications to draw a slightly rounded square by drawing rectangle, than clearing the four corner pixels. There is tons of code like this both in the X world and the Windows world. That code will break in a resolution-independent UI. Apps use the same API for the printer and display, but have come to expect tighter semantics when rendering to the display.
Retained mode means that Avalon retains the necessary instructions to draw a surface, no? Yes, but it's much more than that. It retains an object-hierarchy of everything that needs to be drawn. There is much more semantic information in an Avalon surface than can be described by a sequence of cached GDI calls. A sequence of GDI calls is just deferred immediate mode rendering. You can't go into the cache and say "animate this red square by moving it 2 pixels in the x-axis every second). You *can* implement a scene graph on top of an immediate-mode API of course, but Avalon is designed to make the scene-graph the primary API.
Slashdot Mirror
Um, it's the economists who keep yelling at us to not run such an enormous deficit. It's the "people" who keep voting for their precious government programs that keep running up the debt.
You do attack him for wanting to wait. I quote: That is, assuming they don't have agendas of their own.
You imply they have ulterior motives for their actions.
Of course, you do realize that understanding economics has little to do with knowing which companies will be successful? That takes a business man's mind, not an economist's.
Yes, I'm going to trust alt.computer.consultants before I trust MIT-educated economists. Thanks for putting my priorities in line!
Let me restate that. The "Oxford" that people refer to whenever they use it in the same sentence with "Harvard" and "MIT" isn't in the US.
Compared to modeling for a movie? Yes it is. Games have much less demanding geometry, rather simple shaders, and have most effects done in the engine rather than in the modeler. 3D Studio is an excellent program, but it's optimized for this sort of work (eg: good polygon reduction tools), rather than for more quality-intensive work.
Uber-buffers hasn't been thought-through all the way yet. They're trying to make sure that they can design something that lasts, and something that fits the new 3D-accelerated paradigm that seems imminent. I think the point is that they'd rather do it right by implementing uber-buffers properly, than just put render-to-texture in there for the sake of keeping up. This is especially true considering that you can already to render-to-texture using WGL_ARB_pbuffer and GL_SGIX_pbuffer, which are pretty well-supported.
You're being fallacious.
I don't know why I should even bother replying to you --- your argument is patently ridiculous at face value. It's completely illogical --- you provide no evidence to support your view that economists' theories are "half baked." All you say is that their jobs are not on the line, which has no logical bearing on the validity of their theories!
But I'll indulge you anyway. What kind of economic super genius are you to call their theories half-baked? Even Samuelson points out that globalization has helped us so far, just as economic theory has predicted for 100 years. He's proposing a new wrinkle in the existing theory. The existing theory is well-established, well-supported, and very far from "half baked."
Hmm, I knew this would come up. When I say "US education system" I'm talking about the one most Americans go too --- our public K-12 system. Only 21% of Americans have taken any college courses, and only 15% have a college degree. The other 80-85% attend our attrocious public K-12 schools.
Yes, our university system is one of the best in the world, and we have a couple of top-notch high-schools, but it's not the Harvard and Yale folks who are out of a job...
PS> Oxford isn't in the US.
If you read the whole article, you'll see this isn't true. He won his Nobel Prize for his work showing how internationalization can help make a rich country. He notes that until now, globalization has helped us, rather than hurt us. He just tries to make the qualification that globalization doesn't *necessarily* always lead to benefits, as most economists believe.
His statement is quite a bit mroe subtle than you can put in "simplified terms." Basically, his point is that while the traditional theories of comparative advantage hold, it is possible that certain types of trade can cause you to loose your comparative advantage.
Makes sense, but I'll reserve judgement until the majority of economists have had a chance to weigh in on it.
Like most things, the truth is probably somewhere in the middle.
That is, of course, fallacious reasoning. A common fallacy, but a fallacy nonetheless.
Has it occurred to you that we're losing our edge, not because outsourcing, but because we haven't been working very hard to keep it? Our education system is in shambles, our young people are complete morons, and we as a culture pretty much revile the educated and glorify the average.
This has been a long time coming, and outsourcing is a symptom, not a cause.
Yes, but id software is a major and high-profile supplier of engines. Each OpenGL-based engine they release leads to a whole host of OpenGL-supporting games.
3DS MAX is also a modeler primarly aimed at gaming and other lightweight work.
OpenGL isn't OOP because it's a procedural API, low-level API. DirectX isn't really OO either --- it just happens to use objects. If you want an OO interface to OpenGL, you should use a proper scene graph library.
I don't think that the ARB has really dropped the ball on render-to-texture. As it is implemented in current systems, it's really not a general solution. If you look at the OpenGL uber-buffers proposal, you'll find that render-to-texture is just a feature of what could be a much more powerful and general memory model for OpenGL. I think the real holdup is that they'd rather do this right, by generalizing the memory model, than to add a special-case feature like render-to-texture.
Why do you think ARB is increasingly political? The ARB has been very good about keeping OpenGL up-to-date over the last few years.
Um, what exactly can geometry-instancing accomplish that VBOs cannot?
That's not even close to being a good comparison. Cg is a vendor-proprietory language not a cross-vendor language. You don't see Cg for ATI cards, no do you? DirectX is a platform-specific API, not a cross-platform API. On top of that, it's optimized for gaming, not professional applications. In any case, GLSL came out last year, so at worst, you can say that OpenGL was a year behind Direct3D in getting a high-level shading language.
Personally, I've used both D3D and OpenGL, and find D3D to be a horribly designed API, with massive changes in each revision. I'd much rather get OpenGL a year later, but designed right, than the D3D hack of the day.
Um, what do you think OpenGL 2.0 is? It's a specification.
Well, obviously, if your implementation doesn't have a good 3D engine, you won't be able to use the new apps that require one. X.org will continue to support non-3D systems, of course, and if the apps draw through Cairo, the X server will use software-emulated RENDER instead of OpenGL. If software-emulated RENDER isn't fast enough, and you don't have OpenGL acceleration, then you probably shouldn't be trying to run such a graphically-rich application on your machine.
Now rural villagers can take our jobs!
Video drivers cannot accelerate GDI+ because they are never given an oppurtunity to.
You're wrong about that. Drivers *can* accelerate GDI+. See this article.
I don't beleve you.
You don't have to believe me. It's a simple fact that most software only utilizes the most basic parts of the GDI. Show me where on your desktop you see Bezier curves? XP themes, for example, just use pixmaps that are blitted to the screen --- curves aren't actually drawn using the hardware.
Eh? As you said before, video output is human consumable data, not designed to be reconsumed by the computer. How can an application depend on it?
Let me put this in concrete terms: GDI, I can draw a line that, according to the semantics of the GDI, passes through 10,20, then draw a white pixel at 10,20 to erase that part of the line, and expect it to work. I shouldn't be able to do this, but that doesn't change the fact that existing GDI applications are coded with this assumption. If you treat video as human consumable, rather than computer-consumable, output (as you should), your API has to specify from the beginning (as OpenGL does), that you cannot make these sorts of assumptions.
How can Avalon break those semantics yet retain compatibility but GDI cannot?
Because existing GDI apps won't draw through Avalon. It's okay to break the semantics in a new API, because new apps are aware of the new semantics.
Here is an example of GDI being resolution-independent: printer drivers are just another type of display driver.
The same is true of drawing APIs for X too, and in both cases apps writing to the printer know to expect a resolution independent interface. Apps written for screen display don't know this. Let me give you another concrete example:
Qt's QPainter has similar semantics to the GDI. QPainter can draw to the screen, or to the display, and can have a coordinate transform. Yet, it is common in applications to draw a slightly rounded square by drawing rectangle, than clearing the four corner pixels. There is tons of code like this both in the X world and the Windows world. That code will break in a resolution-independent UI. Apps use the same API for the printer and display, but have come to expect tighter semantics when rendering to the display.
Retained mode means that Avalon retains the necessary instructions to draw a surface, no?
Yes, but it's much more than that. It retains an object-hierarchy of everything that needs to be drawn. There is much more semantic information in an Avalon surface than can be described by a sequence of cached GDI calls. A sequence of GDI calls is just deferred immediate mode rendering. You can't go into the cache and say "animate this red square by moving it 2 pixels in the x-axis every second). You *can* implement a scene graph on top of an immediate-mode API of course, but Avalon is designed to make the scene-graph the primary API.
The overall goal of NT Object Filing System is the same as WinFS. It's not the same code, just the same overall product.