realtime procedural textures
polycounter lvl 18
pretty cool article on a company that is making realtime procedural shaders. i think this is really cool, i mean there are tons of pros for this, the size will be A LOT smaller, allowing for tons more content, and they will hold up no matter how close you get to them, you can say goodbye to blurry textures.. i am sure there are cons.. i mean i would much rather paint textures.. but the screens look great and the end product is really all that matters.. so here is the article
http://www.bit-tech.net/gaming/2006/11/09/Procedural_Textures_Future_Gam/1.html
and here is the company bringing you this fancy stuff
http://www.profxengine.com/index.php?PAGE=GALLERY
http://www.bit-tech.net/gaming/2006/11/09/Procedural_Textures_Future_Gam/1.html
and here is the company bringing you this fancy stuff
http://www.profxengine.com/index.php?PAGE=GALLERY
Replies
Thanks for the link!
all the old 3d software like Imagine and Real3d has procedural / fractal textures as the norm, and that was over 10 years ago.
Which is possible.
It seems to me that this scheme is about pre-creating assets procedurally that will be "decompressed" and loaded into graphics memory as bitmaps, with the aim of reducing the size of games on disk. As such this has zero benefit over artist-painted bitmaps other than massively reduced disk space, unless I totally misunderstand the whole thing.
Which is possible.
[/ QUOTE ]
well, its a good help if you stream so much data the disk cant handle to stream it;the cpu will always be faster than the disk, so streaming procedural textures from the cpu instead of bitmap textures from the disk will be alot faster.
also, you can do alot of funky stuff with the procedural textures that you cant as easily do with bitmap textures, like change them over time for example.
File size is actually one of the more minor gripes regarding textures. This solution solves much more than just squeezing file sizes down. Procedurally generated textures are resolution independent. Their actual pixel resolution when applied to a scene is theoretically infinite. It is also scalable. (meaning that textures on objects farther away can be rendered at lower pixel resolutions)
And of course, there is the issue of time. I don't know about the rest of you, but it takes me a while to paint textures. It can actually take me more time to paint a skin than it did to make the model I'm painting it for. Now imagine that you are producing the environmental textures for an entire next-generation game. All those high-resolution textures. All that detail. Although I wouldn't recommend a method like this for character textures, it would be ideal for environments.
Can you make, say, a dirty, cobwebbed, bullet-ridden concrete wall in under an hour just by tweaking procedural nodes and values? How mathematical does an artist need to be to know how to get the best out of textures like this?
I look forward to working with tech like this though. Having textures nice and sharp even when right next to them would be awesome.
If you could have procedural skin texture, then use some low resolution, painted texture maps for specific things, I imagine some good results could be achieved.
For example, procedural skin all over a character, and a 512 texture map to darken the appropriate areas, such as for muscle definition. And procedural metal for the funky sci fi armour at least one character will be wearing, with a texture map containing decals added.
Or maybe using weightmaps to control blending of procedural textures, allowing you a bit more control.
you'd have to avoid that "so ninty-ninties" pre-render look
Its the same process as is used for your favorite 3d programs' fractal noise textures, marbles, woodgrain etc.
[/ QUOTE ]
I don't think it is. What I think of procedural texturing is where a renderer derives texture values on the fly algorithmically rather than fetching data from memory, whereas this seems to be using normal bitmap textures that are generated procedurally, once, and then just left alone.
One of those approaches gives you infinite detail, no tiling, etc and the other does not. I'm fairly sure this is the latter.
A problem with procedurals is that they aren't as easy to make as textures. With a texture you want a speck of dirt and you paint a speck of dirt, with a procedural you have to find a way to mathematically describe a speck of dirt so your computer understands how it should look, where it should occur, etc. Preferrably in a solution that is not computationally expensive. Try using a procedural to add weathering to an object, not only do you have to teach it how the material weathers (e.g. concrete erodes, darkens, forms moss, etc while steel rusts and paint chips), you have to teach it the conditions causing it and let it simulate the weathering over the shape of your mesh if you don't want the wear and tear to appear random. Then you have to start adding specific treatment for some parts of the mesh (e.g. movable parts) so the wear on something that keeps scraping over another surface looks different from something that just takes a bit of rain.
You are pretty much teaching the PC how to do art, it's easier the more you do the thinking for it but that also makes your procedural more static (e.g. if you hardcode the position of a rust spot it's going to look the same on every instancce of the procedural). To get the full power of procedurals including flexibility (so your steel material can be used on a trash can as easily as a tank and needs only minor changes each time) and variation (same surface won't look tiled no matter how large the area) you have to teach the computer how to make art. Unlike you the computer has NO understanding of the world and you have to teach it EVERYTHING, basically turning the computer itself into an artist. When you can do procedural photorealistic textures and meshes you've got the make art button.
It uses some basic fractal algorithims to generate a normal map in memory to denote etches in the shell like material. It also controls the specular on it with a falloff material.
Very efficiant. Very difficult to master. Most likely a visual application will come into play for common use shaders.
I mostly use it to avoid objects looking exactly the same. You could technically have two of the same tank sit side by side, and make one paint sample look more sunworked/faded and rusted than the other. Even have teh rust come from different areas. Both dynamic, both of the same algorithms, just using different randomization seeds. Makes for a little less repetitivness.
Polish your knowledge of complex math and fourier transformations gentlemen, you're going to write your textures as formulas soon!
[/ QUOTE ]
i use procedural textures all the time for base textures, its not that complicated and there is no formulas involved what so ever. it all comes down to tools. darktree is a perfect example of this, i just adjust a few sliders and i have no problem getting what i want. i use max's as well as blur's procedural textures quite frequently and i do it because its much faster to get the desiered result than painting. i have yet to use any math while doing a procedural shader or texture.
This is still a budding technology, and won't find widespread use for some time yet. In my mind's eye, I'm imagining a game engine that works hand-in-hand with this sort of programming. Instead of rendering actual textures and loading them to memory, the engine will apply the textures to polygons at run time. It would determine the exact pixels that need to be drawn given the scene displayed. A kind of automatic culling and scaling for procedurally generated textures. As such, no actual 2D pixel images would be used at any point of the process. No painting, all pure math.
I've actually thought up the exact same thing years ago, only using standard vector graphics as textures. I never understood why no one tried to to do this. Vector image formats are mathematically generated given vector curves and shapes. They have no actual pixel resolution, and scale infinitely large or small. Why not use them for texture maps instead of pixel images?
I don't see this replacing quality hand painted textures but a nice way to speed up certain areas no one really wants to texture anyway, hahaha. I'm sure it will be abused at first just like bloom, normal/spec maps are being screwed up more times than they are correctly used.
Vector image formats are mathematically generated given vector curves and shapes. They have no actual pixel resolution, and scale infinitely large or small. Why not use them for texture maps instead of pixel images?
[/ QUOTE ]
I don't think typical graphics cards accelerate that kind of thing. Software renderers do it already.
Now, naturally, there would be obvious drawbacks. There always are. The style of textures that could be used for this would be limited. It would be best for solid color blocks. Gradients would probably be possible, but not necessarily advisable. Textures generated in this fashion would likely always have a very "cartoony" look to them, and realism would almost be out of the question. So use of such an engine would limit the game stylistically. For some games that would be perfect, for others it would be a huge problem. Cel-shaded games, though, would benefit immensely from such a system.
Actually procedural textures are great for characters. Beards, dynamic player controlled skin tones or entire skin shaders. You could make a 'dirt' texture layer that is dynamically grimed up if the player walks through mud, and conversely washes off in the rain. We are using a procedural layer for wetness on our models, and it actually moves downward untill dry, when they are out of a rain/water volume. Camo clothing texture for military games etc. It's all done after the base assets are done in my case, in a 3rd or 4rth pass if we have resources availible, but it is night and day when you have these small details.
Hmmmm...that really does sound like an excellent application. I had forgotten that procedurals also benefit from a greater degree of interactivity. Because they are mathematically generated, their properties can be altered or animated at run-time. Making various procedural layers that react in response to environmental conditions would look spectacular in-game. (the water drying effect you mention sounds kick-ass, can't wait to see some videos of it in action)
Needless to say, this technology holds a lot of potential for the industry. Although its still in its infancy, it may not be long before it is a driving force in game development. It will be very interesting to see how it progresses and is used. (I wonder if DirectX10 will have any features that support it/make it easier)
The key thing about this tech isn't procedural textures, but it's use of wavelets to create and I would assume (and hope) display the textures. From what I gather from looking at screenshots of thier authoring tool, it looks like it can take a bitmap and convert it into a CWT or DWT, search it for patterns then make it a repeating pattern, so in theory any bitmap can be made into a procedural. Finding a pattern in a signal isn't exactly the hardest thing in the world.
The potential for this kind of technology is huge and it goes way beyond just texturing, unfortunately there are very few people who understand wavelets well enough to implement them in a practical way. Once they catch on it will change the computing world forever.
oh wavelets also make mip-mapping obsolete.
It seems to me that this scheme is about pre-creating assets procedurally that will be "decompressed" and loaded into graphics memory as bitmaps, with the aim of reducing the size of games on disk. As such this has zero benefit over artist-painted bitmaps other than massively reduced disk space, unless I totally misunderstand the whole thing.
Which is possible.
[/ QUOTE ]
The chief benefit of using wavelet texture encoding is that all of your textures will only ever take up as much memory as your frame size so for instance at a resolution of 1920x1080 all of your textures combined will only take up a maximum of about 6.2mb of ram. However the hardware implementation of dxtc on on most video cards really gets in the way of pulling off an elegant texture wavelet encoding in realtime.
Also you can encode handpainted textures as a wavelet, so it doesn't apply only to procedural textures.