At which point it will pick up the fifth passenger and return to form the head.
Question: I know we pay a lot of attention to the nuclear capabilities of other countries, but has anyone stopped to examine their Blazing Sword capabilities as well? This is no time to let down our guard!
If you want insightful, informative, or interesting posts, don't read the article within 8 hours of it having been posted. Funny happens now, intellectual discourse happens later. That's simply how it works. If you've ever heard the joke/. tagline, "Slashdot: Yesterday's news, Today," it makes even more sense. Just read today's articles tomorrow and you'll get precisely what you're looking for.:)
Ever read any press releases from the likes of the RIAA, MPAA, etc.? Any time piracy is found to be lower, it's allegedly because DRM methods are working. This is a discussion, not a Wikipedia article, so no, I'm not going to waste my time running around Google looking for citations. As I give the people in the discussion the benefit of the doubt when it comes to Google-competence, I leave finding those statements as an exercise to the reader.
Your comment, however, provides little--if anything--of substance to the discussion.
Please note: I made absolutely NO claim that the contrapositive of my original statement is true. That is, I claimed that decreased piracy DOES NOT induce decreased DRM. I did NOT, however, claim that increased piracy DOES induce decreased DRM.
The simple fact of the matter is that NOTHING induces decreased DRM. DRM is both the inevitable future of media, and the inevitable doom.
Hopefully, if the piracy rate for the game is low, perhaps EA will get comfortable enough to ship with even less DRM in the future.
That's not how it works. If the piracy rate is low, they will herald their measures as a success, and it will only serve to increase the amount of DRM in the future.
Don't most of these companies usually have you sign an agreement of some sort (I don't know if it constitutes a "contract," per se) which states something to the effect of, "(Company) will not share your data with other entities, barring partners of (Company)?" So, wouldn't providing your data to a non-partner, whether intentional or otherwise, constitute a breach of contract? (or agreement, or whatever.) I doubt any of these companies are going to claim the thief was acting in good faith. If they were to claim such a thing, they wouldn't have to disclose the theft, I imagine, and thusly we'd never hear of it...
Just a thought. Of course, I would never expect such an argument to stand up in court, especially against a big corporation. Still, can anyone who doesn't have to use the IANAL disclaimer comment on this notion?:)
For one, this was clearly intended to be an idle article, but it ended up in the honest-to-goodness book reviews section.
Secondly, the subject matter of the book doesn't even pertain to what Slashdot (at least ostensibly) is about. Remember that little tagline? News for nerds? How does this book even remotely fit into that category? Yes, they should review good and bad books. But those books should all be relevant.
Thirdly, book reviews should go through the normal editing process. Regardless of the skill of Slashdot editors (let's not have that discussion now) they do catch a fair number of errors and mistakes. However, these Idle reviews do not go through that process, it would appear. Just because it was written by an editor does not mean it doesn't need to be reviewed by an editor.
So, in short form:
Idle articles in regular-article space
Review concerns irrelevant content
Little or no regard for the normal editing process
This is a really good point, and I'd completely forgotten about pixel shaders. That's pretty funny, actually. I was saying, "we need this!" and lo and behold, we already have it. So, there you go. Be aware, though, you've only supported my previous statement/response to the GGP, in that realistic textures in ray-tracing need be no more costly than realistic texturing using the current model. You did what I failed to, though: you pointed out precisely why this is already the case.:P
The way I see it, if resources were devoted to processing procedural textures instead of storing texture images, then that, at the very least, puts the two on an even playing field.
What follows is train of thought, totally unorganized:
Yes, RAM is cheap and thus you can store large amounts of textures in it for a relatively low-cost. But, in general, REALLY FAST RAM (like cache, or better) is NOT cheap, and so you DON'T store textures there. You store it in the cheap, "slow" RAM. On the other hand, if you generate the texture on the fly, procedurally, in the processor (GPU in this case), then that's FAST. I have absolutely no doubt that a GPU on a graphics card is more than capable of generating a texel as fast or faster than it can be used by the rest of the pipeline. Yes, this depends on the procedure used, of course. But assuming we'll continue to blend multiple textures and do all kinds of different texture operations, I'm equating a single, flat, procedural texture to a single, flat, texture image. Blending of multiple textures (procedural or otherwise) happens later.
That being the case, there's no reason that, if graphics cards allowed procedural textures to be generated in the pipeline, that they couldn't easily outpace pre-rendered textures.
Even with the current texturing models, the renderer is still asking a shitload of questions per-pixel about what that color is supposed to be. The trick to making it work right now is just that there is a lot (and I mean an obscene amount) of support in the pipeline for making those questions get answered fast. With a similar amount of support for procedural textures, a lot of opportunities arise.
I just can't stop thinking about other rendering situations that are vaguely similar to procedural textures. Take vector vs. raster graphics, for instance. Photoshop (or Illustrator) is able to render high-quality vector graphics just as well as high-quality raster graphics. In some case, actually, vector graphics are significantly faster, even though the surface has to be calculated just to find out "where" it is. On the other hand, raster graphics are simply buffers in memory. In this case, however, Adobe's done a lot of work to make the two comparable.
I'm totally rambling at this point, and I apologize for that. Long story short, pre-rendered textures are just as complicated as procedural textures, it's just that right now, renderers only put their horsepower towards pre-rendered textures.
Imagine what your CPU could do, rendering procedural textures to memory (instead of to your screen.) Insanely complex textures, hundreds of them, blended in insanely complex ways. You could do some pretty amazing crap like that. Even the relatively "slow" GPU could do that. And that's all you really need. Once it's rendered a texel to memory, it can be used in the pipeline like any other texture source. That gets us so far beyond simple marble patterns, it's not even funny.:)
Everything else I said above left aside, I think what I'm really driving at was this one statement:
...if anything even close to the support given to the current texture models is given to procedural texture models, they will almost instantly outpace the current options and limitations.
Umm, no. I admit it's been a while, so my memory may be off, but I distinctly recall that procedural textures in ray-tracing are really, really easy, and add almost no (necessary) overhead to speak of. If you can find a way to do those things you mentioned with a procedural texture (those cases you provided are the textbook examples of how to do procedural textures, mind you) then you can almost certainly do them easily and cheaply. Any graphics course will have you rendering textured oranges inside the first week of the ray-tracing portion. Rainbowed CD undersides and the cool microscopic rings on the underside of a brass pot the day after that.
I don't remember the implementation details, as it's been many years since I tried, but it's easy, and doesn't add any real overhead to speak of. Yes, when running procedural textures, you CAN make them heavy (it's a procedure: it'll do whatever the hell you want) but by no means is that a requirement.
Which do you think is worse:
Loading a 10MB texture image that only works at certain resolutions, and eats up 10MB of space, or
Loading up a 1k code segment that generates the same (or similar) texture at any resolution, on the fly, and only generates the texture for the exact pixels you're looking at?
Not to mention that if anything even close to the support given to the current texture models is given to procedural texture models, they will almost instantly outpace the current options and limitations.
Did you ever notice that the early-generation ray-tracers supported procedural textures long before they supported the "regular" texturing model? There's a reason for that.
-G
P.S. Yes, I'm fully prepared for nit-picking you-used-the-wrong-word-here responses, so fire away.:P
By attempting to disagree, you totally agreed with the GP. That's precisely what he said: by selling the hardware for MORE, they can charge LESS for the software. That is, the hardware subsidizes the software.
Slashdot Mirror
Kind of like calling someone a pilot if they would someday like to fly a plane.
Come now, this is Slashdot. It's actually more like calling someone a car mechanic, when they would some day like to work on cars.
-G
And also for subsequently pointing out that you pointed out that we aren't speaking Russian. I bet this comment, however, gets modded as flamebait. :P
-G
I hear that pink has an opening *rimshot*
-G
Insightful, really? I mean, really? That was not what I had in mind...
-G
Read a little further down. Turns out, that's what SZ7 is for.
-G
...and part of it will return the men home.
At which point it will pick up the fifth passenger and return to form the head.
Question: I know we pay a lot of attention to the nuclear capabilities of other countries, but has anyone stopped to examine their Blazing Sword capabilities as well? This is no time to let down our guard!
-G
I'm sorry, I couldn't help it. I tagged this with "voltron"
-G
If you want insightful, informative, or interesting posts, don't read the article within 8 hours of it having been posted. Funny happens now, intellectual discourse happens later. That's simply how it works. If you've ever heard the joke /. tagline, "Slashdot: Yesterday's news, Today," it makes even more sense. Just read today's articles tomorrow and you'll get precisely what you're looking for. :)
-G
Ever read any press releases from the likes of the RIAA, MPAA, etc.? Any time piracy is found to be lower, it's allegedly because DRM methods are working. This is a discussion, not a Wikipedia article, so no, I'm not going to waste my time running around Google looking for citations. As I give the people in the discussion the benefit of the doubt when it comes to Google-competence, I leave finding those statements as an exercise to the reader.
Your comment, however, provides little--if anything--of substance to the discussion.
-G
Please note: I made absolutely NO claim that the contrapositive of my original statement is true. That is, I claimed that decreased piracy DOES NOT induce decreased DRM. I did NOT, however, claim that increased piracy DOES induce decreased DRM.
The simple fact of the matter is that NOTHING induces decreased DRM. DRM is both the inevitable future of media, and the inevitable doom.
Yeah, it's a bummer.
-G
Hopefully, if the piracy rate for the game is low, perhaps EA will get comfortable enough to ship with even less DRM in the future.
That's not how it works. If the piracy rate is low, they will herald their measures as a success, and it will only serve to increase the amount of DRM in the future.
-G
Don't most of these companies usually have you sign an agreement of some sort (I don't know if it constitutes a "contract," per se) which states something to the effect of, "(Company) will not share your data with other entities, barring partners of (Company)?" So, wouldn't providing your data to a non-partner, whether intentional or otherwise, constitute a breach of contract? (or agreement, or whatever.) I doubt any of these companies are going to claim the thief was acting in good faith. If they were to claim such a thing, they wouldn't have to disclose the theft, I imagine, and thusly we'd never hear of it...
Just a thought. Of course, I would never expect such an argument to stand up in court, especially against a big corporation. Still, can anyone who doesn't have to use the IANAL disclaimer comment on this notion? :)
-G
Well, except that at least this time, it wasn't white-on-teal, so I guess that's technically an improvement.
-G
Please note: this "review" was posted under book reviews, not under Idle. Which makes it worse, I'd say.
-G
For one, this was clearly intended to be an idle article, but it ended up in the honest-to-goodness book reviews section.
Secondly, the subject matter of the book doesn't even pertain to what Slashdot (at least ostensibly) is about. Remember that little tagline? News for nerds? How does this book even remotely fit into that category? Yes, they should review good and bad books. But those books should all be relevant.
Thirdly, book reviews should go through the normal editing process. Regardless of the skill of Slashdot editors (let's not have that discussion now) they do catch a fair number of errors and mistakes. However, these Idle reviews do not go through that process, it would appear. Just because it was written by an editor does not mean it doesn't need to be reviewed by an editor.
So, in short form:
-G
Please. No more. These reviews are, truly, the bottom of the barrel.
The editing is worse.
-G
I said it in the last Idle article, and I'll say it in this one:
New tag: pleasestop
Never give up, never surrender!
-G
I'm not sure what the etiquette is for this, but I'd like to propose a new tag for these idle articles that hit the front page:
pleasestop
I, for one, will be tagging all future idle articles in this manner.
-G
View->Page Style->No Style
I'm pretty sure they've already got that one licked.
-G
This is a really good point, and I'd completely forgotten about pixel shaders. That's pretty funny, actually. I was saying, "we need this!" and lo and behold, we already have it. So, there you go. Be aware, though, you've only supported my previous statement/response to the GGP, in that realistic textures in ray-tracing need be no more costly than realistic texturing using the current model. You did what I failed to, though: you pointed out precisely why this is already the case. :P
-G
The way I see it, if resources were devoted to processing procedural textures instead of storing texture images, then that, at the very least, puts the two on an even playing field.
What follows is train of thought, totally unorganized:
Yes, RAM is cheap and thus you can store large amounts of textures in it for a relatively low-cost. But, in general, REALLY FAST RAM (like cache, or better) is NOT cheap, and so you DON'T store textures there. You store it in the cheap, "slow" RAM. On the other hand, if you generate the texture on the fly, procedurally, in the processor (GPU in this case), then that's FAST. I have absolutely no doubt that a GPU on a graphics card is more than capable of generating a texel as fast or faster than it can be used by the rest of the pipeline. Yes, this depends on the procedure used, of course. But assuming we'll continue to blend multiple textures and do all kinds of different texture operations, I'm equating a single, flat, procedural texture to a single, flat, texture image. Blending of multiple textures (procedural or otherwise) happens later.
That being the case, there's no reason that, if graphics cards allowed procedural textures to be generated in the pipeline, that they couldn't easily outpace pre-rendered textures.
Even with the current texturing models, the renderer is still asking a shitload of questions per-pixel about what that color is supposed to be. The trick to making it work right now is just that there is a lot (and I mean an obscene amount) of support in the pipeline for making those questions get answered fast. With a similar amount of support for procedural textures, a lot of opportunities arise.
I just can't stop thinking about other rendering situations that are vaguely similar to procedural textures. Take vector vs. raster graphics, for instance. Photoshop (or Illustrator) is able to render high-quality vector graphics just as well as high-quality raster graphics. In some case, actually, vector graphics are significantly faster, even though the surface has to be calculated just to find out "where" it is. On the other hand, raster graphics are simply buffers in memory. In this case, however, Adobe's done a lot of work to make the two comparable.
I'm totally rambling at this point, and I apologize for that. Long story short, pre-rendered textures are just as complicated as procedural textures, it's just that right now, renderers only put their horsepower towards pre-rendered textures.
Imagine what your CPU could do, rendering procedural textures to memory (instead of to your screen.) Insanely complex textures, hundreds of them, blended in insanely complex ways. You could do some pretty amazing crap like that. Even the relatively "slow" GPU could do that. And that's all you really need. Once it's rendered a texel to memory, it can be used in the pipeline like any other texture source. That gets us so far beyond simple marble patterns, it's not even funny. :)
-G
Everything else I said above left aside, I think what I'm really driving at was this one statement:
...if anything even close to the support given to the current texture models is given to procedural texture models, they will almost instantly outpace the current options and limitations.
-G
Umm, no. I admit it's been a while, so my memory may be off, but I distinctly recall that procedural textures in ray-tracing are really, really easy, and add almost no (necessary) overhead to speak of. If you can find a way to do those things you mentioned with a procedural texture (those cases you provided are the textbook examples of how to do procedural textures, mind you) then you can almost certainly do them easily and cheaply. Any graphics course will have you rendering textured oranges inside the first week of the ray-tracing portion. Rainbowed CD undersides and the cool microscopic rings on the underside of a brass pot the day after that.
I don't remember the implementation details, as it's been many years since I tried, but it's easy, and doesn't add any real overhead to speak of. Yes, when running procedural textures, you CAN make them heavy (it's a procedure: it'll do whatever the hell you want) but by no means is that a requirement.
Which do you think is worse:
Not to mention that if anything even close to the support given to the current texture models is given to procedural texture models, they will almost instantly outpace the current options and limitations.
Did you ever notice that the early-generation ray-tracers supported procedural textures long before they supported the "regular" texturing model? There's a reason for that.
-G
P.S. Yes, I'm fully prepared for nit-picking you-used-the-wrong-word-here responses, so fire away. :P
I thought it was referencing your sig, which was cute:
...playing a rather dangerous game*
...
*Space Invaders!!!
-G
By attempting to disagree, you totally agreed with the GP. That's precisely what he said: by selling the hardware for MORE, they can charge LESS for the software. That is, the hardware subsidizes the software.
http://dictionary.reference.com/browse/subsidize (see #1)
and
http://dictionary.reference.com/browse/subsidy (see #3)
-G