Ive got to admit I can see 360 games developers using this a lot more in the future. Considering that 360 games are limited to just 8.5Gig of space (considering they don't want to make a multi-disk game), compared to Sony's possible 50Gig, this could have a massive impact in a few years once we see several itterations of games on next gen from games developers make more advanced content.
Not only that but faster access from the disk as well as there is less to read.
Considering the fact it's highly math based I can see the PS3's cores being used to simultainiously decompress and render textures on the Cells quite efficiently before sending them to memory.
Maybe I didn't read the article well enough, but what are the performance gain/loss with this type of texturing, compared to regular bitmap-texturing?
I imagine not reading large textures from the hard drive could be a performance gain, but the CPU would have to actually "render" these textures into memory, so I'd say that's a performance loss as opposed to regular bitmap textures?
Originally Posted by Bindibadgi Ive got to admit I can see 360 games developers using this a lot more in the future. Considering that 360 games are limited to just 8.5Gig of space (considering they don't want to make a multi-disk game), compared to Sony's possible 50Gig, this could have a massive impact in a few years once we see several itterations of games on next gen from games developers make more advanced content.
But would the X360 hardware be able to use it? I mean, I got the feeling that in order to use procedural textures, the hardware has to be built with support for them. If so, does the Xenos GPU have this support?
My computers run SETI@home (never got into folding) and their system is hevially dependent on Fourier transforms for signal processing. I'm wondering if the mathematical systems he's talking about would be beneficial to that system.
Second is what is the processor overhead to decompress these textures? I'm assuming that the maths involved are interger based and so current processors are well positioned to handle them, but the sheer volume of calculations to decompress each texture could be intimidating. I suppose it depends on how it's implemented by the developers. If all the textures for a level are decompressed and stored into memory when the level is loaded then it wouldn't be so bad. However if they won't all fit into memory or if for some reason they have to be processed "on the fly" then there could be a potential performance hit as the CPU struggles to keep up with that many interger operations per frame.
I wonder what similarities exist between the calculations involved for texture decompression and physics. Both are (AFAIK) heavially interger based math routines and so therefore could end up competing for the same resources. As hard as it may be to believe, I think we could be seeing the beginning to a return of games being processor limited but to the number of operations such as physics and texture decompression being dumped on the CPU. Perhaps these two operations could be combined into a unified API (DX11?).
EDIT: Christ, you guys are fast. I sit down for two thoughts and you post 5 messages before I can finish!
Originally Posted by Iago But would the X360 hardware be able to use it? I mean, I got the feeling that in order to use procedural textures, the hardware has to be built with support for them. If so, does the Xenos GPU have this support?
Or have I got this wrong?
Nope, it's a software algorythum. They've already stated that current Xbox Live games use it and you can farm out the caclulations onto the unified shader FPUs or the three CPU cores. It doesn't even need a dashboard update, the program will hold the software to tell the hardware to do the calculations. They are a middleware company: like an engine maker or a physics engine maker or a sound engine maker etc
Originally Posted by Cthippo Second is what is the processor overhead to decompress these textures?
I imagine that the textures are created and stored in memory like current (graphics-based) textures. As far processor time goes, he states in the article that to load and calculate the textural procedures is faster than loading and decompressing normal textures.
Originally Posted by Cthippo My computers run SETI@home (never got into folding) and their system is hevially dependent on Fourier transforms for signal processing. I'm wondering if the mathematical systems he's talking about would be beneficial to that system.
I doubt it. A huge range of computing systems are based on Fourier transforms. If this guy had discovered an algorithm that was a lot faster and simpler than the FT algorithms he wouldn't be aiming his technology games. A lot more significant applications could benefit from a discovery like that.
Quote:
Originally Posted by Cthippo Second is what is the processor overhead to decompress these textures? I'm assuming that the maths involved are interger based and so current processors are well positioned to handle them, but the sheer volume of calculations to decompress each texture could be intimidating. I suppose it depends on how it's implemented by the developers. If all the textures for a level are decompressed and stored into memory when the level is loaded then it wouldn't be so bad. However if they won't all fit into memory or if for some reason they have to be processed "on the fly" then there could be a potential performance hit as the CPU struggles to keep up with that many interger operations per frame.
If you think about it, the main advantage of this technology is to save disk space. When the game is running, it would work in exactly the same way as games do now. When the level is loaded instead of loading textures from the hard disk, the texture algorithms do their work and load the textures into memory. If during the game, a new texture needs to be generated they you might have to wait a while for that texture to appear. But that would be no different from if the textures had to be loaded from disk during the game.
In fact moving the load from hard disks which have pretty much not improved in speeds very much at all in the last few years to the CPU whose speed is increasing all the time makes a lot of sense. It is likely that when loading a level, the CPU can be working out all the textures and at the same time the disk can load the level geometry and models into memory. This should result in much faster loading times and finally unburden our slow mechanical spinning hard disks until they are replaced with better things.
Originally Posted by Iago But would the X360 hardware be able to use it? I mean, I got the feeling that in order to use procedural textures, the hardware has to be built with support for them. If so, does the Xenos GPU have this support?
Or have I got this wrong?
its already been used hasnt it? in the article it says about some small dev making a game for xbox live, roboblitiz or something
I have a distinct feeling this will end up like the subject of another Bit's articles, anyone remember Brightside and their IMLED technology? It sounds good, but unless it attracts major players it'll end up being lost in the mists of time
I like the fact that hes not a megatexturing fanboy. This type of texturing is exactly what the industry needs! Not bloat like J Carmaks approach.
He's spot on in all areas and he's very knowledgeable. I just hope more companies address this technology, because simply, the graphics are real time real life.
I just hope it's also optimized for slower technology. Not something that's a couple years old but not where we would have to spend a couple grand in an upgrade path just to run Unreal 3 with this great visual eye candy.
As we know from computing, there is the time/space trade-off. If you want things to take up less space, you have to spend more time processing. If you want to take less time processing, they need to take up more space. The question then becomes is the saved space worth the extra time?
A few interestings points
- How intensive are these calculations, and when would they happen? Is this only on level/data load? So that once textures hit the GPU they are just like our standard bitmap textures? How about when they want to change data during the game, will it cause stuttering? (I'm being a bit dramatic here, but it is worth considering how relatively intense these operations may be).
- The main point: He mentioned in the article how it might aide in making development quicker. Does this mean that procedural textures are helpfull only in terms of saving storage space, or ALSO in terms of texture creation? Ie. Do you create your texture the normal way first, then try and figure out how to "fit" that into a procedural model. Or do you design the texture itself using the procedural tools, so that conceivably it's much faster?
- On a related issue to the last point: Are their limits to what types of textures can be created procedurarly, or rather what types of textures can be procedurally represented. Can you simply go to an existing game, look at the textures, and procedurally represent/shrink them, or must the game/textures be designed with this in mind? Ie. "Sorry, that texture can't work. But if you get rid of those specs of dust here, and darken the shading over there, then we can procedurally generate it".
I'd also like to know explicitly if the time it takes to generate 50MB of texture is FASTER than the time it takes to pull 50MB of "normal" textures off the disk. (It's suggested in the article, but not explicitly mentioned)
Interesting ideas. I'd say the "modifying textures on the fly" is the most interesting aspect. While saving storage space is nice, it's not exactly all exciting. And doesn't really have an actual impact on the game itself. (Aside for maybe loading times).
It looks great, I want to download a little tech demo to see how much this will take out of my computer to run. I just think about developers filling up all the space that it saved to make things look even better.
Originally Posted by aggies11 Sounds very interesting.
1. - The main point: He mentioned in the article how it might aide in making development quicker. Does this mean that procedural textures are helpfull only in terms of saving storage space, or ALSO in terms of texture creation? Ie. Do you create your texture the normal way first, then try and figure out how to "fit" that into a procedural model. Or do you design the texture itself using the procedural tools, so that conceivably it's much faster?
[...]
2. I'd also like to know explicitly if the time it takes to generate 50MB of texture is FASTER than the time it takes to pull 50MB of "normal" textures off the disk. (It's suggested in the article, but not explicitly mentioned)
Originally Posted by speedfreek It looks great, I want to download a little tech demo to see how much this will take out of my computer to run. I just think about developers filling up all the space that it saved to make things look even better.
that's not really true. you need to convert the procedural texture into a traditional texture in order to do stuff with it in the rendering pipeline. once it's a normal texture it's just as large as any other texture, so you still need to take into account memory requirements.
the only real advantage here is that the textures stored on disc are tiny. that game you have taking up 5GB of space on your HD would take up 400MB.
so it's a really good thing for digital distribution.
I admire people that can think in such complex way very much. Math is fantastic and I would like to pick their brains so I maybe could understand a bit more. Looks very interesting
Just downloaded Roboblitz. A few problems....
- The download was 350MB
- It took 30 minutes to start the demo, for the first time, it has to cache the shaders and build all the procedure textures. (it did this for the whole game, even though the demo doesn't need it)
- It didn't look that good. Some textures were nice and detailed. But the floor wasn't too sharp.
- The game's install folder is 441MB
I do realise that my system is a bit out of date (3.2 P4 Northwood, 875p, X850pro) but it's not THAT old; I can run HL2 at max settings 1920X1200.
Maybe this game uses just the basics of this procedule texture system, merely for distribution. But it did seem to take a VERY long time building those textures. I think it might be a few years before it will be able to work on mid-range systems quick enough. Without that, it's not very consumer friendly.
Comments 1 to 25 of 43
I quote myself "We need blu-ray space my arse"
Not only that but faster access from the disk as well as there is less to read.
Considering the fact it's highly math based I can see the PS3's cores being used to simultainiously decompress and render textures on the Cells quite efficiently before sending them to memory.
I imagine not reading large textures from the hard drive could be a performance gain, but the CPU would have to actually "render" these textures into memory, so I'd say that's a performance loss as opposed to regular bitmap textures?
But would the X360 hardware be able to use it? I mean, I got the feeling that in order to use procedural textures, the hardware has to be built with support for them. If so, does the Xenos GPU have this support?
Or have I got this wrong?
My computers run SETI@home (never got into folding) and their system is hevially dependent on Fourier transforms for signal processing. I'm wondering if the mathematical systems he's talking about would be beneficial to that system.
Second is what is the processor overhead to decompress these textures? I'm assuming that the maths involved are interger based and so current processors are well positioned to handle them, but the sheer volume of calculations to decompress each texture could be intimidating. I suppose it depends on how it's implemented by the developers. If all the textures for a level are decompressed and stored into memory when the level is loaded then it wouldn't be so bad. However if they won't all fit into memory or if for some reason they have to be processed "on the fly" then there could be a potential performance hit as the CPU struggles to keep up with that many interger operations per frame.
I wonder what similarities exist between the calculations involved for texture decompression and physics. Both are (AFAIK) heavially interger based math routines and so therefore could end up competing for the same resources. As hard as it may be to believe, I think we could be seeing the beginning to a return of games being processor limited but to the number of operations such as physics and texture decompression being dumped on the CPU. Perhaps these two operations could be combined into a unified API (DX11?).
EDIT: Christ, you guys are fast. I sit down for two thoughts and you post 5 messages before I can finish!
Especially since the X360 GPU is unified.
Nope, it's a software algorythum. They've already stated that current Xbox Live games use it and you can farm out the caclulations onto the unified shader FPUs or the three CPU cores. It doesn't even need a dashboard update, the program will hold the software to tell the hardware to do the calculations. They are a middleware company: like an engine maker or a physics engine maker or a sound engine maker etc
I doubt it. A huge range of computing systems are based on Fourier transforms. If this guy had discovered an algorithm that was a lot faster and simpler than the FT algorithms he wouldn't be aiming his technology games. A lot more significant applications could benefit from a discovery like that.
If you think about it, the main advantage of this technology is to save disk space. When the game is running, it would work in exactly the same way as games do now. When the level is loaded instead of loading textures from the hard disk, the texture algorithms do their work and load the textures into memory. If during the game, a new texture needs to be generated they you might have to wait a while for that texture to appear. But that would be no different from if the textures had to be loaded from disk during the game.
In fact moving the load from hard disks which have pretty much not improved in speeds very much at all in the last few years to the CPU whose speed is increasing all the time makes a lot of sense. It is likely that when loading a level, the CPU can be working out all the textures and at the same time the disk can load the level geometry and models into memory. This should result in much faster loading times and finally unburden our slow mechanical spinning hard disks until they are replaced with better things.
its already been used hasnt it? in the article it says about some small dev making a game for xbox live, roboblitiz or something
they used this technique there and it worked!
http://www.digg.com/programming/Interview_with_the_Procedural_Texturing_developers_the_future_of_gaming
Same, it looks amazing.
And if anyone has seen the textures used in Roboblitz, they look U3 engine quality!
He's spot on in all areas and he's very knowledgeable. I just hope more companies address this technology, because simply, the graphics are real time real life.
I just hope it's also optimized for slower technology. Not something that's a couple years old but not where we would have to spend a couple grand in an upgrade path just to run Unreal 3 with this great visual eye candy.
One could only imagine what Gears of War would look like with procedural textures!
As we know from computing, there is the time/space trade-off. If you want things to take up less space, you have to spend more time processing. If you want to take less time processing, they need to take up more space. The question then becomes is the saved space worth the extra time?
A few interestings points
- How intensive are these calculations, and when would they happen? Is this only on level/data load? So that once textures hit the GPU they are just like our standard bitmap textures? How about when they want to change data during the game, will it cause stuttering? (I'm being a bit dramatic here, but it is worth considering how relatively intense these operations may be).
- The main point: He mentioned in the article how it might aide in making development quicker. Does this mean that procedural textures are helpfull only in terms of saving storage space, or ALSO in terms of texture creation? Ie. Do you create your texture the normal way first, then try and figure out how to "fit" that into a procedural model. Or do you design the texture itself using the procedural tools, so that conceivably it's much faster?
- On a related issue to the last point: Are their limits to what types of textures can be created procedurarly, or rather what types of textures can be procedurally represented. Can you simply go to an existing game, look at the textures, and procedurally represent/shrink them, or must the game/textures be designed with this in mind? Ie. "Sorry, that texture can't work. But if you get rid of those specs of dust here, and darken the shading over there, then we can procedurally generate it".
I'd also like to know explicitly if the time it takes to generate 50MB of texture is FASTER than the time it takes to pull 50MB of "normal" textures off the disk. (It's suggested in the article, but not explicitly mentioned)
Interesting ideas. I'd say the "modifying textures on the fly" is the most interesting aspect. While saving storage space is nice, it's not exactly all exciting. And doesn't really have an actual impact on the game itself. (Aside for maybe loading times).
Aggies
Most of these informations can be found on Allegorithmic's website : http://profxengine.com/index.php?PAGE=HOME
1. You design the procedural texture directly with the tools.
(You can check the gallery to see what kind of material can be made)
2. It's faster, you can see some example of this in the Gamefest presentation I think :
http://profxengine.com/resource/specifications/allegorithmic_profx_gamefest_2006.zip
that's not really true. you need to convert the procedural texture into a traditional texture in order to do stuff with it in the rendering pipeline. once it's a normal texture it's just as large as any other texture, so you still need to take into account memory requirements.
the only real advantage here is that the textures stored on disc are tiny. that game you have taking up 5GB of space on your HD would take up 400MB.
so it's a really good thing for digital distribution.
- The download was 350MB
- It took 30 minutes to start the demo, for the first time, it has to cache the shaders and build all the procedure textures. (it did this for the whole game, even though the demo doesn't need it)
- It didn't look that good. Some textures were nice and detailed. But the floor wasn't too sharp.
- The game's install folder is 441MB
I do realise that my system is a bit out of date (3.2 P4 Northwood, 875p, X850pro) but it's not THAT old; I can run HL2 at max settings 1920X1200.
Maybe this game uses just the basics of this procedule texture system, merely for distribution. But it did seem to take a VERY long time building those textures. I think it might be a few years before it will be able to work on mid-range systems quick enough. Without that, it's not very consumer friendly.