Okay, that's just spooky. I get done watching the season finale of Eureka in which one of the characters uses a holographic phone from Cisco to communicate with the mysterious bad guys. And what do I find on Slashdot?
One example is TelePresence, a technology similar to video conferencing that Cisco introduced last month that aims to deliver a three-dimensional feeling that the participants are all in the same room.
Am I going to start hearing the twilight zone music or something?:P
You are perfectly correct. This is currently one of the challenges facing 3D chip design. That said, there are several properties claimed by the article that would make nanotubes more suitable. First and foremost is that the nanotubes supposedly provide less resistance. Heat != Power per se, but rather the amount of resistance to the power applied. Less resistance == less heat. In addition, the amount of heat generated by resistance is also a function of distance. So the shorter distances provided by 3D nanotubing would provide less heat and overall power usage.
I'm also tempted to suggest that the empty space between tubings could be flooded with some sort of coolant to eliminate the temperature gradient; but I have my doubts about the feasibility of that. At such a small level, you'd have a lot of difficulty trying to fit atoms into that space. In addition, you'd probably do more to damage the circuitry than heat removal. Still, that doesn't place micro-heatpumps woven into the circuits entirely out of the question. Just mostly.;)
In any case, we're already using WAY too much power to keep up these ridiculous clock speeds. Forcing chip-makers to scale the power usage back a bit wouldn't be all that bad of a thing. Especially if they're getting replacement speed increases from the smaller interconnects and lower resistance of the nanotubes.
This sounds like it could be of particular use in 3D microprocessor technology. With the number of cores per die ramping up at incredible rates, we're starting to bump into latency issues again. I know that several memory manufacturers (who experinece similar die-space problems) have already switched to layered components to help relieve the issue and keep their dies smaller. But if we can weave nanotubes, we could do a lot more than just stack transistors three or four levels deep. Assuming that a inexpensive manufacturing process were developed, the chip could actually be fashioned in the shape of a cube. The result would make the chip orders of magnitude more dense than the CPUs of today!
Besides, it would look like a Borg cube under a microscope. How cool is that?!?:P
I'd like to see you fit a CPU through those tubes when some other schmuck is streaming his video CPU. Why, I sent my 'mov 0x000010D0' CPU 300 milliseconds ago, and my CPU just ended 2 milliseconds ago! You have to understand that those tubes can be clogged!:P
Correct me if my memory's off... weren't most or all of the US carriers at sea during the attack?
Yep. They were all off on maneuvers, about a day out of port. IIRC, the Japanese knew this, but they were mostly concerned with the battleships. The idea that a carrier could be a major force to be reckoned with was only realized because the U.S. was forced to fight the beginning of the war with only carriers. The results were so spectacular, that the carrier force became the backbone of the WWII fleets. Of course, the CVE idea might have been a bit ambitious.;)
For the first 6 months Japan had naval superiority but did not command the skies as they needed to.
My memory is a bit hazy on this point, but I believe that the problem was their ability to project force over long distances. Their planes didn't have the same range as ours, and they continued to have their code systems broken. There was a major effort to put airstrips out on the occupied islands (that was how Yamamoto got killed), but they simply weren't able to effectively implement that plan.
Also, our carriers left their carriers up in flames after Midway. That significantly reduced their airpower. The Japanese weren't concerned about it at the time, because their Wargames had told them that Battleships were superior. (Actually, one of the Japanese admirals changed the results because he didn't believe that one of his battleships could have been sunken by aircraft.)
Yamamoto was probably being pessemistic (even tho accurate) in his 6 month estimate, because it could have easily gone longer than that if luck had been with them.
Possibly. But Japan was screwed no matter which way you cut it. They'd invested most of their naval resources into the Yamoto class battleships in an attempt to outclass anything that the U.S. could safely fit through the Panama Canal. (Nearly all our warships were built, and are still built, in Newport News/Norfolk.) They were then forced to watch as their Top of the Line Battleships were almost completely ineffective against the U.S. carriers. Once the Essex came online (barely six months later!) it was all over. She had a shakedown while the Enterprise held down the fort, then went on to be the harbinger of an incredible number of Essex class carriers.
The best the Japanese could have hoped for was a protracted land battle on the pacific islands and our west coast. They simply didn't have the resources to actually win a war against the U.S., nor was that their intention. They had hoped to render the U.S. impotent, then make peace after the Axis objectives were completed. Had they never attacked Pearl Harbor, they probably would have done far more damage to the U.S. war effort.
At worst, it is like the Japanese general ( admiral? ) who is alleged to have said after Pearl Harbor: "I fear we have awakened a sleeping giant."
Admiral Isoroku Yamamoto. He spent a significant amount of time in the US before the Japanese attacked. He felt that the pre-emptive strike was a mistake, and that it would only buy them about 6 months reprieve before the American war machine was fully geared up and ready. Thus his "I fear I have awakened a sleeping giant" comment.
He was right. Six months later, the U.S. turned the tide at the Battle of Miday. The Japanese Navy was nowhere near as resilient as the U.S. Navy, and their losses hurt them deeply. Combined with the incredible number of carriers the U.S. began to manufacture, the six month turning point was a deadly one for Japan.
I actually posted that right before Taco announced the problems. It's now showing up because the kind Slashdot staff have gone through and reparented the lost posts. But thank you for your assistance. It is appreciated, even if it ended up being unecessary.:)
Ah hah! Now I understand why the Infinity FAQ has an answer to this very question.
Procedural is not the same as random. Procedural is a set of parameters that can be mathematically unfolded into a large amount of information. Random is a set of numbers that are unpredictable by nature. The confusion probably comes in because many Procedural methods use pseudo-random number generators. However, a pseudo-random generator is not random. For a given seed, you will always get the same sequence of numbers.
The seed is usually one of the parameters used to decide the look of the texture, so there ends up being nothing random about procedural texturing.:)
Q: Is it important that an artist understand Perlin code? A: NO. As *I* said, a tool could be created for them to create the textures.
Q: Does it make sense for a Photoshop plugin to be used. A: NO! As I said, a procedural texture tool would have nothing to do with bitmaps.
Q: So that means it should be a Photoshop plugin, right? A: NO! What, am I talking to a wall?
Q: But Photoshop can do text! You could use it as a Word Processor! A: What the FSCK are you people talking about?
Q: See! You should take these infinite calculations and plug them into Photoshop. Then we be all warm and fuzzy. Ahhh. A: GAAAAAAAAHHH!!!!!!!
Q: But you mentioned having Perlin Code to point out that you know what you're talking about. Therefore, you must be suggesting that Artists should become programmers. A: You're a utter looney, you know that?
Q: Ah hah! Proof of a Photoshop plugin. I need to pat myself on the head for my intelligence. A: Listen, I'm gonna go make waffles. You weirdos can think whatever you want.
---------------------- This has been another production of: All the smart people have apparently left Slashdot. Tune in next time when CowboyNeal gets modded up for swallowing and then regurgitating a whole egg.
The article is full of them. My personal favorite is the photo of the XBox 360 where the PS3 should be. (First set of images, even!) I almost have to wonder if 1UP has been hacked...
No, not specifically. But the principles are similar.
The difference here is that from different distances, you should be getting different images
We're saying the same thing, I think. I'm pointing out that zooming in on a block of wood using traditional texturing will result in a pixelated mess. Zooming in on a procedurally textured block of wood will give you the detail of the wood. Ideally, you'd start to see that the solid lines of the wood are actually a marbling. As you get closer, you should be able to make out the ringed texture from cutting. Even closer and all you see is the roughness of the surface.
The formula could give as much (or as little) detail as you want. It's up to the texture creator. In theory it's possible to provide an infinite amount of detail. In practice, you're limited by both computational time and the practicality of computing such microscopic detail. It's a bit like calculating Pi. Getting each digit gets computationally harder and harder. But the ability does exist to make a texture good enough that an observer in a virtual world would never be able to detect its artificial nature.:)
Like an amazing fool, you keep failing to listen. And here it is, the proof of the pudding:
And if you're going to show images on the screen (AKA bitmaps)
Procedural textures are not bitmaps. The fact that you think they're the same shows just how little you understand about the subject at hand.
In fact, most procedural texturing tools map the display to different objects like spheres, boxes, and cones. The purpose of doing this is to show how the texture will look in actual usage. The only "bitmap" is the one dumped into the framebuffer during rendering. When the artist zooms in, a new preview is generated. When he zooms out, a new preview is generated. When he textures a new object, a new preview is generated. There is NO bitmap.
And, incidentally, I'm pretty sure you can do text handling in Photoshop. Just like you can do drawing in Word.
Hey everyone, Control Group thinks that the text handling in Photoshop is good enough for Word Processing! (rolls eyes)
I mean, seriously. I'm drawing blood from my tongue not to throw an insult at your lack of understanding. I honestly realize that not everyone understands the inner workings of computers, mathematics, and computer software. But you're taking stupidity to new heights here. Maybe you should take a step back and pay attention to what everyone is saying? They're not just talking out of their asses here. Some of the people on this forum have done actual, honest to Godwork on procedural texturing. I still have my own Perlin code sitting around on my hard drive. (Originally intended for a super-small FPS that was going to compete in a competition.) We know a few things about the subject that you obviously don't.
Procedural texturing is just another form of compression.
Did I say it wasn't?;)
My point is that procedural texturing has the ability to be a lot more than just lossy compression. It can be used to generate textures down to any level of detail necessary. Done in real-time, it would mean a revolution for video game graphics.
All I said was that Joe Average wouldn't understand that.
sounds like it could easily be a Photoshop plugin.
(raises eyebrow) Do you download wordprocessor plugins for Photoshop as well? Because that's about how much procedural textures and Photoshop's framework have in common. Sure, you could "write a plugin". But that plugin would have to manage everything from the parsing of the file format, to the full interface, to the handling of the files. It would make just about as much sense as a Microsoft Office "plugin" for Photoshop. i.e. None at all.
We're not talking about script-fu type of stuff here. (Which is, BTW, a type of procedural texturing.) We're talking about creating the textures without generating a bitmap at any point in the process. The two are not even close to the same. That is, unless Photoshop recently obtained an infinite zoom feature, handling of images of infinite size, and no longer has any pixel manipulation tools?
Now give back those mod points. You're perpetuating stupidity.
You do know that traditional textures are often created in, you guessed it, Photoshop?
You're still missing the point. Procedural textures are procedural. There is no bitmap to edit, only a set of parameters to pass to the function of your choice. Converting the result of the procedure to a bitmap would be superfluous, as it would defeat the size gains provided by doing procedural texturing!
What you usually find in procedural texturing is a tool with various sliders and controls to modify the parameters (e.g. roughness, marbling, scaling, color, etc.) of the texture. When the artist obtains the look he's going for, he saves those parameters out. There is no need for a bitmap until runtime.
The really great thing about procedural texturing is that texture libraries become even more useful. Want a marble floor? Grab a library texture. Applied to the final product, it will look like a fresh texture rather than a rehash of an existing bitmap. The texture can be as large or as small as you need, so there's no obviously tiling like the type that makes traditional textures stand out so much. When the full potential of procedural texturing is realized in gaming, it will all but remove the need for a dedicated texture artist.
Does anyone know just how much computing power the constant (re-)generation of textures takes?
I think the key thing to understand is that real-time texture generation happens on a textel level. So the computational power needed is a function of how many textels you need to push. Poor man's procedural texturing is already available with pixel shaders. If you can imagine a pixel shader where the only input is the screen coordinates translated into a point on the surface of the polygon, then you pretty much understand how real-time procedural texturing can work.
As a result, the cost of generation will vary depending on the procedure used to generate the texture. Perlin Noise is a fairly fast algorithm that can be used to generate marbled textures. You might consider studying it to come up with a good feel for how many computations per pixel would be required.
Of course, if the desire is to simply shrink the size of downloads, then the cost of computations doesn't matter. One could quickly and easily generate all the textures needed when the software is installed, then forget all about procedural texture generation.
You can batch texture generation to cores 2/3/4 while you are playing on core 1, assuming you are running on a game which, by nature, only utilizes the first core. That is a lot of rendering power.
Technically speaking, you'd batch in texture generation in with the polygon rendering. Each textel rendered would be a set of U,V coordinates to run through the texture generator. The generator would chew on the floating point coordinates a bit, then spit the result out as a color value. That's part of the reason why procedural generation is so popular in Raytracing. You can simply and easily punch in non-integer coordinates for each pixel to always get the correct value. There's no need to interpolate an image, and the result looks just as good no matter what your angle or distance is.
Depends on the quality, precision, and whether or not you get a high-end GPU involved. CPUs are poorly suited to procedural texturing, but they're still able to do basic Perlin Noise Generation in real-time. If you get the DSP computing and multiprocessor capabilities of a GPU involved, the rendering time will drop like a rock. With the new 8000 series of NVidia cards, you could potentially generate dozens of textures in parallel.
Of course, the first-gen stuff will probably generate the textures when they're installed. In which case the user will notice that the 50 meg file they downloaded just decompressed into 10s of gigs of data. He'll probably just comment on how "cool" the compression rates are.
One thing the article doesn't quite touch on is the fact that procedural texturing can produce superior quality. We currently use tricks like trilinear mipmapping and ansitropic filtering to produce the best quality out of a resampling of a static image. However, this doesn't remove the fact that the textures are still of a fixed size, and will break up or look wrong depending on how close you come to the texture.
Procedural textures don't suffer from this. If greater detail is needed, it can simply be calculated from the texturing formula. As a result, a woodgrain will continue to look like a woodgrain (to the limits of the resolution), no matter how close or far away you get. Raytraced scenery has used this advantage to good effect in the last few decades. If procedural texturing finally makes the jump to gaming, the results could be incredible.
Of course, there is a downside. Real-time procedural texturing is costly. So if the hardware isn't up to it, the advantages of the texturing will go unrealized. It wouldn't surprise me at all if the first generation merely generates static textures on load, then uses them as if they were bitmaps included with the game. Still, once the box is opened, the potential will be too tempting to ignore.
On the Mozilla side the plan is to integrate to code with SpiderMonkey which is Mozilla's current JavaScript implementation that is written in C.
I presume the article means to say that the Tamarin engine will be coupled with SpiderMonkey's APIs? Because I don't see how you could "combine" two separate Javascript engines and expect a usable result. That would be like "combining" Windows and Mac OS X to make a better operating system. It doesn't quite work that way.
Great if you want fast answers, but the RAM used in GPUs isn't as robust accuracy-wise as normal RAM.
You're confusing your technologies. The RAM used on video cards these days is effectively the same RAM you use with your CPU. The memory cannot lose data or very bad things will happen to the rendering pipeline.
What you're thinking of is the intentional inaccuracy of the floating point calculations done by the GPU. In order to obtain the highest absolute graphical performance, most 3D drivers optimized for gaming attempt to drop the precision of the calculations to a degree that's unacceptable for engineering uses, but perfectly acceptable for gaming. NVidia and ATI make a lot of money by selling "professional" cards like the Quadro and the FireGL to engineering companies that need the greater precision. A lot of the difference is in the drivers (especially for the low-end models), but the cards do often have hardware technologies better suited to CAD-type work.
Let me see if I have this down right: With the progress of multi-core CPU's, especially looking at the AMD / ATI deal, PC's are moving towards a single 'super chip' that will do everything while phasing out the use of a truly separate graphics system. Meanwhile, supercomputers are moving towards using GPU's as the main workhorse. Doesn't that strike anybody else as a little odd?
Odd? Not really. The "PC super chip" design is practically the same thing as the "GPU Supercomputer" design. The big difference is that the PC Super Chip design adds in general processing capabilities while the GPU Supercomputer design merely shrinks existing supercomputer designs onto high performance Graphics chips.
GPUs actually share a lot in common with traditional supercomputer designs. So it's not surprising at all that the massive amounts of R&D done by the GPU market would have real-world applications for the supercomputer market. Similarly, the PC market has already played out the clock-speed trick. It still needs general purpose processing, but getting a 3.5 GHz chip just doesn't improve things much. Instead, the PC market is starting to look at using that processing power more effectively by dividing it up between truely parallel tasks. Especially those tasks that require massive number crunching.
Slashdot Mirror
Am I going to start hearing the twilight zone music or something?
GeForce 8: 128 Stream Processors
Sparc T1: 8 Cores w/4 threads (Maximum thoroughput: 32 simultaneous processes)
16 Core POWER5
Cell Processor: 1 Primary + 8 Sub-Processors
Intel Promises 80 cores
We're at a LOT more than "four".
You are perfectly correct. This is currently one of the challenges facing 3D chip design. That said, there are several properties claimed by the article that would make nanotubes more suitable. First and foremost is that the nanotubes supposedly provide less resistance. Heat != Power per se, but rather the amount of resistance to the power applied. Less resistance == less heat. In addition, the amount of heat generated by resistance is also a function of distance. So the shorter distances provided by 3D nanotubing would provide less heat and overall power usage.
;)
I'm also tempted to suggest that the empty space between tubings could be flooded with some sort of coolant to eliminate the temperature gradient; but I have my doubts about the feasibility of that. At such a small level, you'd have a lot of difficulty trying to fit atoms into that space. In addition, you'd probably do more to damage the circuitry than heat removal. Still, that doesn't place micro-heatpumps woven into the circuits entirely out of the question. Just mostly.
In any case, we're already using WAY too much power to keep up these ridiculous clock speeds. Forcing chip-makers to scale the power usage back a bit wouldn't be all that bad of a thing. Especially if they're getting replacement speed increases from the smaller interconnects and lower resistance of the nanotubes.
This sounds like it could be of particular use in 3D microprocessor technology. With the number of cores per die ramping up at incredible rates, we're starting to bump into latency issues again. I know that several memory manufacturers (who experinece similar die-space problems) have already switched to layered components to help relieve the issue and keep their dies smaller. But if we can weave nanotubes, we could do a lot more than just stack transistors three or four levels deep. Assuming that a inexpensive manufacturing process were developed, the chip could actually be fashioned in the shape of a cube. The result would make the chip orders of magnitude more dense than the CPUs of today!
:P
Besides, it would look like a Borg cube under a microscope. How cool is that?!?
I'd like to see you fit a CPU through those tubes when some other schmuck is streaming his video CPU. Why, I sent my 'mov 0x000010D0' CPU 300 milliseconds ago, and my CPU just ended 2 milliseconds ago! You have to understand that those tubes can be clogged! :P
Yep. They were all off on maneuvers, about a day out of port. IIRC, the Japanese knew this, but they were mostly concerned with the battleships. The idea that a carrier could be a major force to be reckoned with was only realized because the U.S. was forced to fight the beginning of the war with only carriers. The results were so spectacular, that the carrier force became the backbone of the WWII fleets. Of course, the CVE idea might have been a bit ambitious.
My memory is a bit hazy on this point, but I believe that the problem was their ability to project force over long distances. Their planes didn't have the same range as ours, and they continued to have their code systems broken. There was a major effort to put airstrips out on the occupied islands (that was how Yamamoto got killed), but they simply weren't able to effectively implement that plan.
Also, our carriers left their carriers up in flames after Midway. That significantly reduced their airpower. The Japanese weren't concerned about it at the time, because their Wargames had told them that Battleships were superior. (Actually, one of the Japanese admirals changed the results because he didn't believe that one of his battleships could have been sunken by aircraft.)
Possibly. But Japan was screwed no matter which way you cut it. They'd invested most of their naval resources into the Yamoto class battleships in an attempt to outclass anything that the U.S. could safely fit through the Panama Canal. (Nearly all our warships were built, and are still built, in Newport News/Norfolk.) They were then forced to watch as their Top of the Line Battleships were almost completely ineffective against the U.S. carriers. Once the Essex came online (barely six months later!) it was all over. She had a shakedown while the Enterprise held down the fort, then went on to be the harbinger of an incredible number of Essex class carriers.
The best the Japanese could have hoped for was a protracted land battle on the pacific islands and our west coast. They simply didn't have the resources to actually win a war against the U.S., nor was that their intention. They had hoped to render the U.S. impotent, then make peace after the Axis objectives were completed. Had they never attacked Pearl Harbor, they probably would have done far more damage to the U.S. war effort.
Admiral Isoroku Yamamoto. He spent a significant amount of time in the US before the Japanese attacked. He felt that the pre-emptive strike was a mistake, and that it would only buy them about 6 months reprieve before the American war machine was fully geared up and ready. Thus his "I fear I have awakened a sleeping giant" comment.
He was right. Six months later, the U.S. turned the tide at the Battle of Miday. The Japanese Navy was nowhere near as resilient as the U.S. Navy, and their losses hurt them deeply. Combined with the incredible number of carriers the U.S. began to manufacture, the six month turning point was a deadly one for Japan.
I actually posted that right before Taco announced the problems. It's now showing up because the kind Slashdot staff have gone through and reparented the lost posts. But thank you for your assistance. It is appreciated, even if it ended up being unecessary. :)
That would be a procedural tool on a very different order than the ones being discussed here. :)
Ah hah! Now I understand why the Infinity FAQ has an answer to this very question.
:)
Procedural is not the same as random. Procedural is a set of parameters that can be mathematically unfolded into a large amount of information. Random is a set of numbers that are unpredictable by nature. The confusion probably comes in because many Procedural methods use pseudo-random number generators. However, a pseudo-random generator is not random. For a given seed, you will always get the same sequence of numbers.
The seed is usually one of the parameters used to decide the look of the texture, so there ends up being nothing random about procedural texturing.
Ok, so let's recap.
Q: Is it important that an artist understand Perlin code?
A: NO. As * I * said, a tool could be created for them to create the textures.
Q: Does it make sense for a Photoshop plugin to be used.
A: NO! As I said, a procedural texture tool would have nothing to do with bitmaps.
Q: So that means it should be a Photoshop plugin, right?
A: NO! What, am I talking to a wall?
Q: But Photoshop can do text! You could use it as a Word Processor!
A: What the FSCK are you people talking about?
Q: See! You should take these infinite calculations and plug them into Photoshop. Then we be all warm and fuzzy. Ahhh.
A: GAAAAAAAAHHH!!!!!!!
Q: But you mentioned having Perlin Code to point out that you know what you're talking about. Therefore, you must be suggesting that Artists should become programmers.
A: You're a utter looney, you know that?
Q: Ah hah! Proof of a Photoshop plugin. I need to pat myself on the head for my intelligence.
A: Listen, I'm gonna go make waffles. You weirdos can think whatever you want.
----------------------
This has been another production of: All the smart people have apparently left Slashdot. Tune in next time when CowboyNeal gets modded up for swallowing and then regurgitating a whole egg.
I was reading the USA Today this morning, and they had an interesting outlook on the PS3 vs. the Wii vs. the XBox 360. It basically came down to:
n sole-cover_x.htm
PS3: You're not getting one. Ha!
Wii: Risky, but inexpensive.
XBox: Just fork over the cash for instant gratification.
I think that says a lot about the mainstream views on this generation of console.
The article can be read online here:
http://www.usatoday.com/tech/gaming/2006-11-09-co
The article is full of them. My personal favorite is the photo of the XBox 360 where the PS3 should be. (First set of images, even!) I almost have to wonder if 1UP has been hacked...
No, not specifically. But the principles are similar.
We're saying the same thing, I think. I'm pointing out that zooming in on a block of wood using traditional texturing will result in a pixelated mess. Zooming in on a procedurally textured block of wood will give you the detail of the wood. Ideally, you'd start to see that the solid lines of the wood are actually a marbling. As you get closer, you should be able to make out the ringed texture from cutting. Even closer and all you see is the roughness of the surface.
The formula could give as much (or as little) detail as you want. It's up to the texture creator. In theory it's possible to provide an infinite amount of detail. In practice, you're limited by both computational time and the practicality of computing such microscopic detail. It's a bit like calculating Pi. Getting each digit gets computationally harder and harder. But the ability does exist to make a texture good enough that an observer in a virtual world would never be able to detect its artificial nature.
Procedural textures are not bitmaps. The fact that you think they're the same shows just how little you understand about the subject at hand.
In fact, most procedural texturing tools map the display to different objects like spheres, boxes, and cones. The purpose of doing this is to show how the texture will look in actual usage. The only "bitmap" is the one dumped into the framebuffer during rendering. When the artist zooms in, a new preview is generated. When he zooms out, a new preview is generated. When he textures a new object, a new preview is generated. There is NO bitmap.
Hey everyone, Control Group thinks that the text handling in Photoshop is good enough for Word Processing! (rolls eyes)
I mean, seriously. I'm drawing blood from my tongue not to throw an insult at your lack of understanding. I honestly realize that not everyone understands the inner workings of computers, mathematics, and computer software. But you're taking stupidity to new heights here. Maybe you should take a step back and pay attention to what everyone is saying? They're not just talking out of their asses here. Some of the people on this forum have done actual, honest to God work on procedural texturing. I still have my own Perlin code sitting around on my hard drive. (Originally intended for a super-small FPS that was going to compete in a competition.) We know a few things about the subject that you obviously don't.
Did I say it wasn't?
My point is that procedural texturing has the ability to be a lot more than just lossy compression. It can be used to generate textures down to any level of detail necessary. Done in real-time, it would mean a revolution for video game graphics.
All I said was that Joe Average wouldn't understand that.
(raises eyebrow) Do you download wordprocessor plugins for Photoshop as well? Because that's about how much procedural textures and Photoshop's framework have in common. Sure, you could "write a plugin". But that plugin would have to manage everything from the parsing of the file format, to the full interface, to the handling of the files. It would make just about as much sense as a Microsoft Office "plugin" for Photoshop. i.e. None at all.
We're not talking about script-fu type of stuff here. (Which is, BTW, a type of procedural texturing.) We're talking about creating the textures without generating a bitmap at any point in the process. The two are not even close to the same. That is, unless Photoshop recently obtained an infinite zoom feature, handling of images of infinite size, and no longer has any pixel manipulation tools?
Now give back those mod points. You're perpetuating stupidity.
Indeed it is. I always liked waffles.
You're still missing the point. Procedural textures are procedural. There is no bitmap to edit, only a set of parameters to pass to the function of your choice. Converting the result of the procedure to a bitmap would be superfluous, as it would defeat the size gains provided by doing procedural texturing!
What you usually find in procedural texturing is a tool with various sliders and controls to modify the parameters (e.g. roughness, marbling, scaling, color, etc.) of the texture. When the artist obtains the look he's going for, he saves those parameters out. There is no need for a bitmap until runtime.
The really great thing about procedural texturing is that texture libraries become even more useful. Want a marble floor? Grab a library texture. Applied to the final product, it will look like a fresh texture rather than a rehash of an existing bitmap. The texture can be as large or as small as you need, so there's no obviously tiling like the type that makes traditional textures stand out so much. When the full potential of procedural texturing is realized in gaming, it will all but remove the need for a dedicated texture artist.
I think the key thing to understand is that real-time texture generation happens on a textel level. So the computational power needed is a function of how many textels you need to push. Poor man's procedural texturing is already available with pixel shaders. If you can imagine a pixel shader where the only input is the screen coordinates translated into a point on the surface of the polygon, then you pretty much understand how real-time procedural texturing can work.
As a result, the cost of generation will vary depending on the procedure used to generate the texture. Perlin Noise is a fairly fast algorithm that can be used to generate marbled textures. You might consider studying it to come up with a good feel for how many computations per pixel would be required.
Of course, if the desire is to simply shrink the size of downloads, then the cost of computations doesn't matter. One could quickly and easily generate all the textures needed when the software is installed, then forget all about procedural texture generation.
Technically speaking, you'd batch in texture generation in with the polygon rendering. Each textel rendered would be a set of U,V coordinates to run through the texture generator. The generator would chew on the floating point coordinates a bit, then spit the result out as a color value. That's part of the reason why procedural generation is so popular in Raytracing. You can simply and easily punch in non-integer coordinates for each pixel to always get the correct value. There's no need to interpolate an image, and the result looks just as good no matter what your angle or distance is.
Depends on the quality, precision, and whether or not you get a high-end GPU involved. CPUs are poorly suited to procedural texturing, but they're still able to do basic Perlin Noise Generation in real-time. If you get the DSP computing and multiprocessor capabilities of a GPU involved, the rendering time will drop like a rock. With the new 8000 series of NVidia cards, you could potentially generate dozens of textures in parallel.
Of course, the first-gen stuff will probably generate the textures when they're installed. In which case the user will notice that the 50 meg file they downloaded just decompressed into 10s of gigs of data. He'll probably just comment on how "cool" the compression rates are.
One thing the article doesn't quite touch on is the fact that procedural texturing can produce superior quality. We currently use tricks like trilinear mipmapping and ansitropic filtering to produce the best quality out of a resampling of a static image. However, this doesn't remove the fact that the textures are still of a fixed size, and will break up or look wrong depending on how close you come to the texture.
Procedural textures don't suffer from this. If greater detail is needed, it can simply be calculated from the texturing formula. As a result, a woodgrain will continue to look like a woodgrain (to the limits of the resolution), no matter how close or far away you get. Raytraced scenery has used this advantage to good effect in the last few decades. If procedural texturing finally makes the jump to gaming, the results could be incredible.
Of course, there is a downside. Real-time procedural texturing is costly. So if the hardware isn't up to it, the advantages of the texturing will go unrealized. It wouldn't surprise me at all if the first generation merely generates static textures on load, then uses them as if they were bitmaps included with the game. Still, once the box is opened, the potential will be too tempting to ignore.
I presume the article means to say that the Tamarin engine will be coupled with SpiderMonkey's APIs? Because I don't see how you could "combine" two separate Javascript engines and expect a usable result. That would be like "combining" Windows and Mac OS X to make a better operating system. It doesn't quite work that way.
You're confusing your technologies. The RAM used on video cards these days is effectively the same RAM you use with your CPU. The memory cannot lose data or very bad things will happen to the rendering pipeline.
What you're thinking of is the intentional inaccuracy of the floating point calculations done by the GPU. In order to obtain the highest absolute graphical performance, most 3D drivers optimized for gaming attempt to drop the precision of the calculations to a degree that's unacceptable for engineering uses, but perfectly acceptable for gaming. NVidia and ATI make a lot of money by selling "professional" cards like the Quadro and the FireGL to engineering companies that need the greater precision. A lot of the difference is in the drivers (especially for the low-end models), but the cards do often have hardware technologies better suited to CAD-type work.
Odd? Not really. The "PC super chip" design is practically the same thing as the "GPU Supercomputer" design. The big difference is that the PC Super Chip design adds in general processing capabilities while the GPU Supercomputer design merely shrinks existing supercomputer designs onto high performance Graphics chips.
GPUs actually share a lot in common with traditional supercomputer designs. So it's not surprising at all that the massive amounts of R&D done by the GPU market would have real-world applications for the supercomputer market. Similarly, the PC market has already played out the clock-speed trick. It still needs general purpose processing, but getting a 3.5 GHz chip just doesn't improve things much. Instead, the PC market is starting to look at using that processing power more effectively by dividing it up between truely parallel tasks. Especially those tasks that require massive number crunching.