Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Parallel

Graphics, Games, and Multi-core


Today's guest is Sebastien Deguy, president and founder of Allegorithmic.

DDJ: Sebastien, the Allegorithmic web site mentions "procedural textures." What does that mean?

SD: Procedural textures are textures defined according to an algorithm. Instead of painting (by hand) the texture pixel by pixel, you define the way these pixels have to be lit to produce the texture you want. It's basically like writing a program, and with that program comes all the power of algorithms over frozen (bitmap) data -- compactness, data amplification, parameterization, and the like.

When the procedural texture is defined, you launch an engine for actually generating the bitmap textures. These are called realizations of the procedural description, and it's a lot like the difference between a -- possibly random -- process and the realization of that process.

In the case of Allegorithmic's procedural textures, you'd define the procedures in a nice visual way using our product MaPZone, then use our other technology ProFX to rasterize the images, producing the final result to be displayed by a game engine or any renderer.

There are many advantages to using procedural textures instead of bitmap textures, one of them being that procedural texture files are typically 500-1000 smaller than bitmaps (making them ideal for online games).

DDJ: I'm familiar with 3D textures. But what are 4D textures?

SD: 4D here stands for 3D + Time. 4D textures means evolving textures, evolving environments and games. On our web site we showcase a demo around that idea, where a bathroom goes from a clean state to a dirty state in real-time.

Procedural textures, because they are driven by parameters, can be driven by time. And by letting time go by, the aspect of the textures can be changed, going for example from a clean state to a deprecated one.

Now imagine that applied to a game, where the whole environment and characters are changing, evolving, according to time but also to your actions within that environment. Actual PCs and consoles can handle this, and I must say I can't wait to see games using this as a feature.

DDJ: If I recall from your web site, a platform you will shortly be supporting is Playstation 3. What benefits and challenges do multi-core processors bring to the scene?

SD: Procedural techniques are demanding in terms of power, so the more power you can get, the better it is in that respect. Going multi-threaded is quite easy generally speaking for image-based work (you can divide the image in several pieces and work in parallel), and so the more cores you can get, again, the better it will be.

That said, programming the PS3's eight Synergistic Processing Units (SPUs) can be quite challenging from time to time, but there is definitely a lot to gain from the architecture, and ProFX on PS3 should run impressively fast. (We should get confirmation on that by the end of the year or so ;)

A very cool side effect of the PS3's architecture is that ProFX should be able to continuously stream textures -- using one or two SPUs to compute the textures to be given to the GPU to be displayed, that's a huge bonus for adding rich content to games without having to stream that content from the BluRay or overloading the sole GPU of the machine.

You should see more graphically impressive games than ever with that kind of combination.

DDJ: We've seem to have made great strides in terms of texture mapping and other forms of 3D modeling. What's the next big challenge?

SD: There are many technical challenges that I could point out here. But I'd like to focus on one. Game developers now have a lot more content to produce, store, and distribute than ever before. MMORPGs are a good example here, filling up a BluRay of 50GB of content (instead of 5GB for a single layer DVD) is another one.

The question is then, for producing 10 times more content, do you want to grow your company by a factor of 10? Although I like the idea of allowing the industry to grow significantly, and although I love the idea of providing the maximum people with a cool job, I don't believe it's feasible that way.

Therefore game developers have to find new ways of not only producing that content, but also storing and delivering it.

I strongly believe procedural techniques for content creation are a major solution to that challenge:

  • It's proven that, because defining procedural content is a highly non-linear process, you produce more content faster than with traditional techniques by reusing a lot of the base elements you've been producing along the line.
  • Procedural content can be easily customized and created by gamers, and user-generated content is another key element for producing never-ending content.
  • Procedural content files are typically parameters or code, which is usually extremely small compared to what it can produce. And that makes them ideal for the storage and furthermore the delivery of that content.

Of course, going from a traditional approach for content production to using generative techniques can be quite a challenge by itself, but it's worth the effort, and one of the only ways I see for raising the bar in terms of next-generation content creation.

DDJ: If readers want to find out more about these topics, can you suggest a web site? [okay to point to www.allegorithmic.com - YES]

SD: First, I invite readers to take a look at the web site dedicated to ProFX, Allegorithmic's middleware for procedural texturing, where they can find a lot of information regarding procedural texturing for games:

They can also check the Wikipedia webpage about procedural generation as a whole, and see that it's quite a hot topic right now (waiting for Spore! :)


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.