Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Math

Procedural Textures the Future of Games? 132

Posted by Zonk from the teeny-tinny-prettiness dept.
An anonymous reader writes "bit-tech has posted an interview, with the head of Allegorithmic, Sebastian DeGuy. In it DeGuy again makes the statement that his software (which was used to make the Roboblitz game released on Steam recently) will be used to make games 90% smaller than what they currently are. He comments on why his procedural texturing technique is an evolution of the infamous .kkreiger. demo and how procedural texturing compares to Carmack's 'megatexturing'. The article includes some pretty extraordinary pictures of scenes rendered with just a few bytes as opposed to the ridiculous sizes of modern games." From the article: "Despite some similarities, technique-wise, we are quite different in several ways. First, the inner technology (the maths) that we use is based on modern maths. We use 'Wavelets', instead of classic maths method of 'Fourier Transform', which was the mathematical technique used in the past by all the procedural texturing techniques (including .kkrieger). Our technique works on a new mathematical model that I developed whilst studying for my PhD."
This discussion has been archived. No new comments can be posted.

Procedural Textures the Future of Games? More

Procedural Textures the Future of Games?

Comments Filter:

  • isn't it slow? (Score:3, Interesting)

    by Nf1nk ( 443791 ) <nf1nk@@@yahoo...com> on Friday November 10, 2006 @11:48AM (#16794912) Homepage
    I use a program called animation master, that hsa supported procedural textures, (they call them materials). The file size for thee things is generaly around one or two k, and they can be amazing, I did a dirty tile floor using it and it was still less than 2k. The downside is render time. it drove my near realtime render to a 30min crawl. I can't imagine using procedural textures for a video game it would just kill the frame rate.

    • Re: (Score:1, Redundant)

      by WilliamSChips ( 793741 )
      Yes, it's slow. I tried .kkrieger and although it was very impressive visually, it was slow and choppy.
    • If the game baked the textures into a traditional bitmap in memory then it would just mean longer load times. Or maybe not, depending on how slow the storage you're loading from is.

      You could even generate the textures to various detail levels (mips) asynchronously depending on the mip levels that the game tries to render.
    • 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'r

      • Re:isn't it slow? (Score:5, Insightful)

        by grammar fascist ( 239789 ) on Friday November 10, 2006 @12:58PM (#16795998) Homepage
        He'll probably just comment on how "cool" the compression rates are.

        He'd be right, too. Procedural texturing is just another form of compression. The big difference is that in generating textures, you work directly in the compressed space rather than letting a machine compress the finished product, so you can get totally mad compression rates.

        In other words, his intuition just spanked your geeky arrogance. ;)
        • 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.
        • that isn't entirely fair. It's more like decompression. When you can compress other textures to small files with similar rations using wavelet transforms (for example), you can start calling it compression. The other way round (generating interesting-looking textures) is much easier..

    • Prerender (Score:1, Insightful)

      by Anonymous Coward
      It's slower to load, but in action it's just as fast as 'normal' textures. The only difference is the texture being rendered was generated on your machine during the game's loading sequence instead of in photoshop on some artist's machine. They're both just pixels when it gets to drawing.

      • Re: (Score:2, Insightful)

        by bestinshow ( 985111 )
        From some of the animations on the product website, it looks like the software can actually procedurally generate the textures at render time. Hence the 'aging room' videos, as the parameters to the procedural textures are altered subtley over time. I imagine the code must be running as a shader. A lot of overhead for a mere shader though, most games would simply pregenerate the textures at load time.

    • Re: (Score:1)

      by maxume ( 22995 )
      It'll only kill the frame rate until it doesn't. That is, the hardware will probably catch up.

  • Quality (Score:5, Informative)

    by AKAImBatman ( 238306 ) * <akaimbatman@gmaiBLUEl.com minus berry> on Friday November 10, 2006 @11:49AM (#16794938) Homepage Journal
    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.

    • Re: (Score:2, Informative)

      by Bieeanda ( 961632 )

      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.

      Having played through the Roboblitz demo, and having sat through about five to ten minutes of it claiming to unpack procedural textures before the game actually began, it's pretty clear that

    • Re:Quality (Score:5, Interesting)

      by Chris Burke ( 6130 ) on Friday November 10, 2006 @12:31PM (#16795590) Homepage
      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.

      Yeah, I bet it will be a while until they are generating the textures on the fly every frame. However, as an intermediate step one could imagine being able to easily generate a larger number of textures for varying levels of detail, rather than having to pre-determine what levels you're going to include on the disk.

    • Re: (Score:2)

      by Jerf ( 17166 )

      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.

      I would expect that if a company like this can find a powerful-enough mathematical abstraction for producing these textures, that nVidia and/or ATI would leap at the chance to put it in hardware, where it ought to speed up a

      • Note I did notice them talking about working on the XBox 360 already and talking to Sony about the PS3; my point was that it's too late for the consoles to get full hardware support, not that procedural textures are impossible. It may be impractical to use procedural textures on current hardware with games that are more demanding than a standard FPS, which in computational terms is almost negligible in most cases; the average FPS is pretty much all graphics, if the textures end up eating a lot of the CPU du

      • Re: (Score:2)

        by OoSync ( 444928 )
        Maybe not up to "realtime", but probably to something a bit more useful

        Useful, in this case, is defined as: less time to compute than load from the disk

        In other words, the usefulness of this technique is that the latency of computing the textures can be made better than loading them off of the disk. This is especially true if you must load a compressed texture into memory and then decompress it before loading it into the rendering hardware. That ways it saves the memory size, memory bandwidth, and co

      • Re: (Score:2)

        by mikael ( 484 )
        The techniques are called "texture analysis" and "texture synthesis". Before the advent of framebuffers in the late 1960's, psychologists tried to understand the human perception of texture. After this time, many researchers have tried to find ways
        of synthesizing new textures from existing textures, particularly from aerial imagery. These have included quilting methods (copying and pasting small bits of texture from one image to another larger image). Other methods include using the FFT to convert an image

    • Re: (Score:3, Insightful)

      by Das Modell ( 969371 )
      I would like to nitpick by pointing out that "infamous" does not mean what "anonymous reader" thinks it means. An "infamous" game has a notoriously bad or evil reputation.

    • 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.

      You mean fractal texturing? The difference here is that from different distances, you should be getting different images -- you shouldn't be able to recognize wood-grain from all distances. I.e., from 20 feet you should be able to see surface contours but not the fine wood-grain, from 1

      • You mean fractal texturing?

        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 cl

        • 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.

          an important question about generated stuff is how much is random and how much is predetermined. Random is more interesting, but different each time unless the result is stored. There is a ba

          • Ah hah! Now I understand why the Infinity FAQ [fl-tw.com] 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 see
            • 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. :)
              There ya go. I think I have always just assumed that this would end up being... boring. because they shouldn't be all the same. but then, this is jumping a bit ahead of the game.

    • Re: (Score:2)

      by Profound ( 50789 )
      static : procedural is a time/space tradeoff. Graphics card technology is starting to bottleneck on bandwidth between insanely fast procecessors so in the future it looks like procedural will see the advantage tipped its way.

      But there is also the business side of it:

      Static looks as the designers indented it, can be made by artists (though requiring a lot more work)
      Procedural requires surrendering some design vision to randomness only works on some things and requires more programmer time.

      Pretty cool though,
  • Are there tools to create the texture? It's not going to take
    the industry by storm if it requires a highly specialized programer
    to create a proceedural texture. Is there a Photoshop plug-in?

    Great images though!
    • Is there a Photoshop plug-in?
      Hm let me think. Can I come up with a better way to show lack of understanding of the topic.

      No. You win.

      • Re:Creation issue (Score:4, Interesting)

        by RightSaidFred99 ( 874576 ) on Friday November 10, 2006 @12:13PM (#16795296)
        The ironing is delicious. You do know that traditional textures are often created in, you guessed it, Photoshop? Ergo, his question is perfectly valid, and his point is more valid. Do you need to sit down and write code to do these procedural textures, or can ordinary tools be modified to create them.

        Please try to keep up with the conversation before you mock someone else.

        • Re: (Score:2)

          by oc255 ( 218044 )
          I agree, his point was artists doing the art. Although I wonder if Gimp's script-fu goes into this space, I've never done anything with it. My best guess is that it's perl doing filters which is procedural effects maybe and not really creating game assets.
        • The whole POINT is that they're made of code instead of pixels. Since Photoshop is a bitmap editor, the answer is no to the plugin (Gradient layers in PS are procedural textures for example, but exporting a gradient as a gradient is more in the realm of what a vector-based resolution-independent app like Illustrator or Flash is good at.)

          Artist-friendly procedural texture makers exist, though, check out Darktree [darksim.com] for an excellent (albeit slow-rendering) example.

          • Re: (Score:2)

            by Dunbal ( 464142 )
            The whole POINT is that they're made of code instead of pixels.

                  Eww, who wants to look at code???

                  Sorry, couldn't resist...

        • The ironing is delicious. You do know that traditional textures are often created in, you guessed it, Photoshop? Ergo, his question is perfectly valid, and his point is more valid. Do you need to sit down and write code to do these procedural textures, or can ordinary tools be modified to create them.

          I was thinking about that question actually. I ended up with the conclusion that the way I see it, it would be just the same as integrating a Perl parser or something like that into Photoshop. A procedural tex

        • Re:Creation issue (Score:4, Informative)

          by AKAImBatman ( 238306 ) * <akaimbatman@gmaiBLUEl.com minus berry> on Friday November 10, 2006 @12:40PM (#16795716) Homepage Journal
          The ironing is delicious.

          Indeed it is. I always liked waffles.

          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.

          • Re: (Score:3, Interesting)

            by Control Group ( 105494 ) *
            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!

            But unless you want your game levels to be made up of completely random textures, someone still needs to decide/design what the textures will look like. And the question is, can they do that in Photoshop.

            • Re: (Score:3, Insightful)

              by AKAImBatman ( 238306 ) *

              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

            • Re: (Score:3, Insightful)

              by arose ( 644256 )
              Which is exactly what the original poster was asking about, and sounds like it could easily be a Photoshop plugin.
              And why exactly would you bolt large amounts of bitmap manipulation tools to a procedural texture designer? Making it a Photoshop plugin adds nothing to a procedural texture designer that can't be done with the black art of copy and paste.
              • And why exactly would you bolt large amounts of bitmap manipulation tools to a procedural texture designer? Making it a Photoshop plugin adds nothing to a procedural texture designer that can't be done with the black art of copy and paste.

                True - but the original question wasn't whether Photoshop would be the ideal tool for technical reasons, but whether it could be incorporated into Photoshop because that's the tool artists already know how to use. Or, more generally, the question was: are procedural textur

                • Re: (Score:2)

                  by arose ( 644256 )

                  While Photoshop would add nothing to the procedural texture designer, it might still be worthwhile from a UI/learning curve standpoint.

                  No it wouldn't be, the designer wouldn't get any more familiar just because you call it via a menu in Photoshop, it would use none of the Photoshop's tools or workflow concepts.

                  Or, more generally, the question was: are procedural textures something current artists could learn to create fairly easily, or would they have to become "programmers lite"?

                  Not only could they, bu

            • ... when it is already available in most 3D design packages?

              If you have used a 3D package (Blender, Maya, etc.) the first time you texture a model is probably done with a procedural texture. If you have special needs for a texture, then you might start thinking about UV mapping or projection mapping. If you just need rock, grass, water, wood or skin, reach for the procedural materials first and worry about overlays later.

              Now there is a gap to be filled between the material properties available in a 3D e

              • Then that's also an answer to the question - artists can use their current tools, they'll just shift texturing from one current tool (Photoshop) to another current tool (Maya).
          • There is no reason the set of functions used to generate the procedural texture couldn't be exactly the tools that Photoshop provides, and the arguments to those functions the mouse movements and other inputs the artist gives to Photoshop. Then Photoshop would be exactly the right interface for constructing procedural textures.

            Basically you would just save out the entire Photoshop undo history to a file and use it later to reconstruct the image. Of course, unless you're Adobe, reconstructing the image wou

    • Re:Creation issue (Score:4, Interesting)

      by Andy_R ( 114137 ) on Friday November 10, 2006 @12:06PM (#16795214) Homepage Journal
      U&I software's "Artmatic Voyager" (successor to the much better known but non-procedural landscape renderer Bryce), and it's 2D companion Artmatic Pro are excellent tools for creating procedural art. No programming experience is necessary to create quite stunning stuff, and there is a wealth of possibilities under the hood once you start building your own algorythms. Take a look at the Artmatic Voyager Gallery [uisoftware.com] for some beautiful procedural planets.

      • Re: (Score:1)

        by iainl ( 136759 )
        Really? I could have sworn I played around with procedural textures in Bryce. But that was at least 8 years ago, when one of the mags had version 3 on a coverdisk.
    • Maybe you should read the interview more closely (I know that this is slashdot).

      The point has been addressed:
      1. There are tools out there (this technology is old).
      2. Several other companies have had tools for a while, but his method uses waveletts instead of fourier transforms.

      The whole Photoshop plug-in thing is missing the point, because procedural graphics are very different from bitmaps. Photoshop does bitmaps. Also, converting a procedural texture to a bitmap defeats the purpose.
      • But converting a bitmap to a procedural texture would be hella useful.

        Note I'm thinking close enough technology here, obviously the bitmap cannot be entirely replicated.

        Take Valve's HL2 texture from photo (W/ lightmap + reflectionmap + bumpmap) add proceedural texture to make textures manageable size (approximations of the actual textures used) = one step closer to photo to .bsp(or whatever) technology.

      • Re: (Score:2)

        by sammyo ( 166904 )
        I don't get it... Well actually I do.

        Ok, who uses the tools?

        Who creates images/textures?

        Who creates a cutting edge killer game with NO ARTISTS?

        How many artists have high expertise developing algorithms?

        Artists. Not programmers.

        How many tens and hundreds of thousands of great textures have been developed by programmers? Not
        a couple neato keen demos. High volume, rapid turnaround production?

        Sheesh, yes I'm slightly off topic if the only issue worth discussion is the relative performance
        between FFT's and Wavel

    • Re: (Score:2)

      by Lerc ( 71477 )
      Actually this is the only part of the issue that chould have any impact.

      fr-08 fr-019 and a decent number of 64 k demos have shown thad good quality and small size is obtainable. Even older there are procedurally generated data in 8 bit games. That wasn't so much revolutionary as obvious that you'd be an idiot to try and store things in raw data form.

      I don't know how people can present these ideas as something new and wonderful, It's more like they are finally getting around to doing something that they s

  • Will it decrease loading times? (Score:3, Interesting)

    by CastrTroy ( 595695 ) on Friday November 10, 2006 @11:51AM (#16794976)
    Will this actually decrease loading times? It seems to be that as games get bigger, the loading times get longer, would the decrease in space needed make it require more or less time to load the game. Obviously reading the information off the disk would be faster, but I imagine you'd have a lot of computation to do to figure out what the texture is supposed to be. Kind of like how it takes less CPU power to decode a WAV file than to decode an MP3 file.
    • My guess is that the load time will decrease for consoles. It seems that the bottleneck there is IO - takes a certain amount of time to load large files from the disk. This would result in smaller disk sizes. Then the programs will be run to produce images at the desired resolution on the CPU. So, there is a possibility that if the shader programs are complex enough, it'll take longer, but as IO lags behind CPU speeds, my guess is that it will still be faster to produce most textures procedurally, or vi

  • Tradeoff... (Score:4, Insightful)

    by HaeMaker ( 221642 ) on Friday November 10, 2006 @11:54AM (#16795028) Homepage
    They are trading file size for CPU performance. While the impact of reduced file sizes are clear, the impact on CPU is not. The question is, is our ability to add storage and bandwidth slower than our ability to add CPU and memory?

    I think storage and bandwidth will start winning over CPU as we seem to have hit another Ghz wall and are throwing cores at the problem. While RAM, hard disk and flash are all getting cheaper and bigger at a faster rate.
    • 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.

      Granted, Valve's engine now utilizes multiple cores and we will see multi-core engines emerge, but still a core or two (of a 4/8 core processor, speaking in the future) to batch textures is not unreasonable.

      • 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

    • I think this kind of response shows a flagrant lack of understanding of how computers even work. Have you ever heard of a bottleneck? Regardless of how trends may or may not continue, the average current PC is facing such a tiny bottleneck on disk loading time compared to the amount of processor time available. I have a *very* low end dual core PC, yet it is still difficult for me to max out my processing power for any kind of sustained amount of time due to the amount of effort it takes my (hardware) Ra

  • "Elite" used this technique over 20 years ago (Score:5, Informative)

    by Andy_R ( 114137 ) on Friday November 10, 2006 @11:56AM (#16795056) Homepage Journal
    Way back in 1984, the game "Elite" used procedural techniques to generate it's galaxy maps, allowing 8 galaxies with 256 individally named and described stars to fit in a tiny fraction of it's 32k memory. A derivative of the fibonnaci sequence saved the BBC's 1Mhz processor having to do FFTs. The idea of using procedures to generate 3D graphics has been around since another BBC game, "The Sentinel", where 9999 levels of 3D landscape were generated at up to 1fps (if you were lucky!)

    Sony has been hyping procedural texturing recently, the PS3's Cell architecture is supposedly ideal for doing this kind of thing.
    • The idea of using procedures to generate 3D graphics has been around since another BBC game, "The Sentinel", where 9999 levels of 3D landscape were generated at up to 1fps

      Did this generate the data on the fly then? I always assumed that it generated the landscape at the start of the level and would just draw from a buffer during the actual game.

      the PS3's Cell architecture is supposedly ideal for doing this kind of thing

      It's true that parallel systems work well for this general class of tasks. Some

    • Re: (Score:2)

      by rev063 ( 591509 )
      This is a great example of using similar procedural techniques to generate entire environments, not just textures, and Elite was indeed a pioneer in this area.

      The most recent example I can think of is Oblivion, which used procedural techniques to generate the forests. The branches and leaves of each tree were generated procedurally, not pre-defined. (The same may also be true of the positions and species mixture of the trees in the forest, but I'm not sure about that.)

  • Watch the video's. Amazing. Infinity [fl-tw.com]
  • Quality of texture is a huge advantage of procedural textures, not just for the fact that they don't pixelate as you approach them, but your ability to multisample is limited by computation speed, not bandwidth. Which brings up the biggest advantage of procedural textures: Bandwidth For every pixel that is written to the framebuffer, hundreds (if not thousands) of bytes are read from memory in texture sampling. Scaling the clockspeed and adding more processing cores is easy and cheap, increasing bandwidt
    • But thats not how things are done in games - the textures are generated, then cached as traditional textures for use on the video card. So you don't have any quality benifit from procedural techniques, and in most cases loose quality because an artist cannot simply grab the brush and paint some pixels. If procedural textures are going to become a mainstream in game graphics, it's not going to work the way it does now. These approaches are mathmatical in nature, and require a special kind of thought process

      • Re: (Score:1)

        by sowth ( 748135 )

        Procedural textures can be created by the GPU, so creating them on the fly is not as big a problem as you think.

        No shit you will need "artists" who know how to create procedural textures rather than someone who uses photoshop. Why the hell are so many bringing this up as if it isn't obvious. Do you people work for the government or something?

        Would you take someone off the street who happens to know how to sculpt clay and ask her to make 3d model on a computer? I don't think so. It has about as much chan

  • Details? (Score:2)

    by Tom ( 822 )
    Interesting, but low on details.

    Does anyone know just how much computing power the constant (re-)generation of textures takes? How long the load times are?

    I guess procedural textures have their place. They look to have some fractals inside, and it appears they are great for wood, stone, grass, etc. - basically the same things that 3D animation software has been using procedural textures for since at least 1999.

    • 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 un

      • You are quite mistaken if you think that's how people are proposing to use procedural textures in games in the next few years. It's all "generate bitmap in main memory, upload texture to graphics card" right now. Per-pixel procedural textures for realtime graphics are a long way off.

        Personally, I'm not sure it will ever make sense to do per-pixel procedural textures. Why would you do computations every frame when you can do them once and amortize the cost over hundreds of frames? That way you can use hu

        • Why would you do computations every frame when you can do them once and amortize the cost over hundreds of frames?

          Okay. Why would you do computations for 3d all the time, when you can just create a RGBA bitmap once, and move it around the screen/ zoom all you want? It certainly would cut down CPU usage. Why have 3d acceleration at all?

          The answer is it looks better. The main reason it is in the "generate bitmap, upload to vid card" stage is more because enough programmers aren't experienced with using th

          • Your analogy is spurious, and your "answer" isn't convincing. Care to explain what exactly makes a per-pixel procedural texture "look better" than one precomputed with sufficient resolution (but still procedural), when you can spend 100+ times more processing power on the precomputed one?

            I can see per-pixel procedural textures being useful if the texture is changing rapidly. But for the vast majority of textures, precomputing makes so much more sense. It allows you to do computations that simply aren't f
  • Comment removed based on user account deletion
  • What we're saying is that graphics can be small, good-looking, or fast... pick any two?

  • From the itsatypo dept. (Score:3, Funny)

    by Control Group ( 105494 ) * on Friday November 10, 2006 @12:20PM (#16795406) Homepage
    I've never heard of "tinny" graphics before.

    • Re: (Score:2)

      by gold23 ( 44621 )
      I've never heard of "tinny" graphics before.

      Oh yeah, they're used for shading metallic surfaces.

    • I do so abhor tinny graphics. Oh, how I do appreciate a good, woodsy graphic instead....
    • Actually, I think "tinny" might be a good description of procedural graphics as they are now. How do you create a formula that looks natural? It can create a decent approximation, but not quite perfect if you look closely. So it's "tinny [reference.com]".
  • Some of us in the game industry have been using variations on these methods for years, I'm building a game now where most textures are procedural. Use of wavelets for this is nothing new either, I started playing with it myself ~ a decade ago, its always been the best approach for certain classes of image, especially for generating MIP levels. I hope the "new" idea here isn't trying to patent it...

    One clarification w/r/t loading times, slow speeds, ect (simplified): With normal textures, you load your tex
  • I remember hearing that Spore is going to be highly procedural. Textures, models, walking animations, etc. There's a lot of room for this approach and it's not limited to just the graphics.

  • kai's power tools (Score:5, Insightful)

    by Speare ( 84249 ) on Friday November 10, 2006 @12:52PM (#16795922) Homepage Journal

    This debate, traditionally painted textures versus mathematically derived textures, reminds me of the feeling I got when I would use any one of the (in)famous Kai's Power Tool suite.

    These tools were image processing tools with (to be polite) quirky user interface concepts. The output was always interesting, but never what you really planned. Throughout the literature and documentation, there were sprinkled sentences straight from my Jr. High School art teacher, about "happy accidents" and "explore" and "try a few different things to see what's exciting." The interfaces didn't explain themselves, you had to fiddle with them, and in the process of fiddling, you might get some image output that was astounding, exciting, bizarre, cool, inspiring. The creators of KPT saw that as a good thing.

    However, there's a big difference between opportunistic art and production art. The opportunist is the lady on the edge of town who boldly wields an acetyline torch and welds together scraps of iron to sell as mobiles or unique garden fairies or whatever happens to come up. The production artist is told to make a Chanel No 5 ad, which entails a certain palette, a certain wispy but crisp attention to lighting, an interplay of gravity and weightlessness, and above all, black garments on gaunt 30-something models. Things are constrained very tightly for the production artist, and they let that constraint drive their creativity.

    KPT is great for opportunity artists, but not for production artists. Write down a concept on a Post-It, and just *try* to achieve that concept with their tools. You can't figure out what the third blobdot widget from the left is doing, so you try to get it to where it is somewhat close. Then you hope the fourth blobdot widget from the left doesn't fuck up any progress you've made when you touch it. You may find a thousand really cool accidents on the way, but you will never really achieve that concept you wrote down on the note paper beforehand.

    This comes back to procedural textures.

    • You can tweak and tune and adjust for hours, just trying for the perfect simulacrum of a chunk of oak woodgrain, trying to achieve the ultimate blend of four levels of grain periodicity through natural variations in density, allowing for convolutions that resemble knots and sawblade artifacts, all within a neat 16 parameters.
    • Or you can snap a photograph of the boardroom table, use some morphing and blending tricks to make it tile if necessary, and be done.

    Which approach do you think will still be in use when they make Final Fantasy XXXIV?

    • Re:kai's power tools (Score:4, Insightful)

      by Control Group ( 105494 ) * on Friday November 10, 2006 @01:05PM (#16796082) Homepage
      I'm not an artist, so I could be way off on this, but - I would think that the level of per-pixel detail you're talking about isn't necessary for a lot of textures used in games. How much control do you need to have over the specific wood grain of a door, for example? Wouldn't it be good enough to specify that it's a mahogany tone, with a range for grain tightness, with the grain running vertically?

      Essentially, what they did with the trees in Oblivion - it doesn't matter for almost any of the trees that they look a specific way, just that they look like various flavors of deciduous tree.

      I would think an awful lot of textures could be like that - anything plantlike, marbles, anything with an actual repetitive pattern (screen doors, cyclone fence, brick walls, etc). Sure, there are no doubt plenty of textures that need to be just so, but an awful lot of the game world is stuff that doesn't matter at the degree of detail you're talking about - as long as there actually is detail there.

      But again, I don't do texture creation for games, so maybe I'm way off base. But the fact that it was definitely used for Oblivion, and both MS and Sony have said that they tried to design into their machines facilities to handle procedural textures more easily lead me to believe that it's not the lost cause you make it out to be.

    • Re: (Score:1, Insightful)

      by bumchick ( 201482 )
      Great post, thanks.
      I never used procedural texture tools, but it seems creating a large library of textures using the 'explore' approach, and selling the library as middleware, could be perfect for many game studios.
    • I know exactly what you mean about Kai's Power Tools, which was more like a kaleidoscope than actual image editing tools.

      I think that in general, though, the constraints on texture artists aren't that great. The art director may call for "wood paneling", but isn't going to necessarily want a particular species of oak. In fact, a randomly-happened-upon wood grain that looks nice may be better than one designed to look like a particular grain. Seeing as how today textures never have enough detail to convey
  • I would imagine something like nvidias CUDA may do wonders for generating procedural textures.

  • Not only textures (Score:4, Interesting)

    by ichigo 2.0 ( 900288 ) on Friday November 10, 2006 @01:24PM (#16796364)
    Not only textures, but animations, models & sounds will eventually be generated procedurally. Everything natural around is procedural, with the laws of physics, evolution and genetics deciding the look, feel and sound of our environment. Having artists produce textures, animations etc manually has been just a hack & shortcut to better graphics; now that it is becoming infeasible to produce the art required by the most realistic games manually, we'll finally start to get procedural games. I look forward to seeing a rebirth of the industry, with small developers being able to compete with bigger studios thanks to the increased cost-efficiency gained from procedural art.

  • Not procedural: Simply, compressed. (Score:4, Interesting)

    by TerranFury ( 726743 ) on Friday November 10, 2006 @01:41PM (#16796570)

    I'm not sure that 'procedural' is really what we want. Good textures often involve real source images, for instance.

    Wavelets may be more useful to compactly encode textures generated more traditionally, and to provide better upsampling than traditional polynomial interpolation methods (bilinear, etc). Rather than generating points between samples using just the adjacent pixels, points are generated from a sum of wavelets generated by looking at all of the pixels.

    An example of an image format that does just this is JPEG2000.

    The interesting conclusion is that maybe graphics cards should be manipulating images in the frequency domain instead of as bitmaps.

  • Actually, despite what a lot of replies are saying it's exactly <a href="http://en.wikipedia.org/wiki/Embarrassingly_ parallel">the sort of thing</a> 3D graphics cards are designed for. Make it fast enough, and you might not even need to store the entire decompressed texture in RAM.
  • In all these comments? Sheesh, and I thought you guys were nerds :)

    Demos have been doing procedural textures for years... almost a necessity when you're trying to squeeze x number of minutes of... stuff into a 64k binary file. Take a look at fr-08: .the .product [pouet.net] by farbrausch [wikipedia.org] for a pretty stunning example of the amount of compression you can get when you need it. They've also got a proof-of-concept FPS [wikipedia.org] that uses all procedural textures and fits into a 96k binary.

    They've even released a tool [wikipedia.org] for procedural g

    • Re: (Score:2)

      by Etcetera ( 14711 )

      Wow... so how did I comment on this story while totally missing what was already put in the summary -- and TFA? No more posting before coffee. =/
  • At least it doesn't work right, or well like that.

    Play Just cause and Oblivion. Which one uses Procedural generation.

    Answer: both of them. Just causes uses it for almost everything, it has 300 square miles of land, that while it's all procedurally generated, they did NOTHING with. The ground looks like crap on the 360, the gameplay is about the same all over the place, and the buildings are.. well sparse and dull.

    Oblivion has 16 miles of land. Oblivion doesn't use it for everything. However every tre
  • So, anyone know when the patent on wavelets expires?

    Does anyone still care about algorithm patents?

Slashdot Top Deals

"An idealist is one who, on noticing that a rose smells better than a cabbage, concludes that it will also make better soup." - H.L. Mencken

Close