Not logged in, Join Here! or Log In Below:  
News Articles Search    

Submitted by Kim Pallister, posted on September 15, 2000

Image Description, by Kim Pallister

Attached is a screenshot of procedural terrain/world I and a co-worker have been working on. There's no clever terrain LOD schemes, just a brute force method of throwing loads of triangles at the HW (the terrain is ~100,000 triangles, of which 25% are rendered in any given frame).

The cool thing is that everything is procedural. The terrain, terrain/detail/mask textures, clouds, trees, tree impostors, flocking birds, etc, are all procedural. It's a <200k .exe file that doesn't load any artwork.

We still have some work to do on it, but will be releasing the whole thing with source as part of a webcast training on developing procedural content for 3D applications. (Uh oh. Here comes the plug).

If anyone's interested in the webcast, here's the info:

Real-time Procedural 3D Graphics on the PC, or "How to Send the World through a 56k Modem", with Kim Pallister & Dean Macri.

Learn how to use the horsepower of the processor to generate 3D content algorithmicaly, saving valuable artist time & download bandwidth. Understand procedural generation of terrain geometry, textures, trees, clouds and more. We'll discuss and demonstrate performance implications and experiments we've tried in DirectX*. This session should interest persons familiar with 3D graphics programming and/or Microsoft DirectX.

When: September 21 9:30-11am Pacific Time

These webcasts will feature slides, live audio streaming, demos, and a chat window where you can meet with peers and ask questions of the presenters.

To register, see under "Spotlighted Courses".

A couple archived webcasts on scalable 3D apps & cloth animation are already up there.

Kim Pallister
Staff Technical Marketing Engineer
Intel Corporation

Image of the Day Gallery


Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.

September 15, 2000, 07:21 AM

It looks really great !
The tree on the left looks amazing, how many tris are this ?

Perhaps you can add some [more?] lightning (some directional light or something).

Nice work !


Alex J. Champandard

September 15, 2000, 07:38 AM

> There's no clever terrain LOD schemes, just a brute force method
> of throwing loads of triangles at the HW

Who needs LOD anyway ;) Brute force is SO much more efficient...

More on that very soon :P


September 15, 2000, 09:51 AM

While we're on the topic: with the advent of hardware heirarchical z-buffers (HZB), brute force is actually likely to win.

Current z-buffers check 8x8 pixel squares before rendering. This means that 64 pixels can be eliminated from rendering in 1 cycle. Future ones will be able to check visibility on the entire polygon in O(log(n)) time in the largest dimension of the polygon, which is likely to be only a handfull of cycles.

If the terrain is immutable, data can be transmitted to the card once and the only bottle neck will be the T&L and rendering on the card. HZB coupled with a relatively high fill rate eliminates the rendering bottleneck, leaving only T&L, which is perfectly parallelizable and can be attacked by having very fast matrix multipliers running in parallel.

I expect to see PC hardware handling scenes with millions of triangles per frame using these techniques in the next three years.



September 15, 2000, 10:12 AM

> generate 3D content algorithmicaly, saving valuable artist time

Theres a basic flaw in this assumtion. Artists WANT to design the terrain. The artists and game designers want to control the way the game environment looks and is layed out. Its essensial to the process of making a game.

Now, I'm not saying that procedural methodologies don't have there use, what I'm saying is that they nead to be combined with a content control and manipulation scheam of some sort.

I've thought about this in the past, and proposed design systems that give the artist as much control as they want over a landscape, and yet let the computer fill the gaps. But for some reason people arn't interested. The artists actually want to design the whole damn world in MAX polygon by polygon.


J-S Perrier

September 15, 2000, 10:12 AM

Hi there,
The tree in the front is very nice! Seems to have a lot of polygons... If I may suggest something, it would be so much nicer with lighting. Just some simple static per vertex shading would help a lot to see the shape of the terrain and give a more realistic feel to the scene...

The Wolf

September 15, 2000, 10:34 AM

looks very nice. What is the FPS on this thing? (on what kind of system?), I like the idea of parametric terrain, no need for maps, the only problem is getting it right for a specific scene.

Sky is half a sphere! cool

Shadd - that tree is a bitmap (I think!)

cool terrain, could use more lights and shadows though


September 15, 2000, 10:43 AM

Will run only with 56kbps? that's amazing...
But you've said no LOD for now, well,
then you must trasnfer all the geometry
over, if there is something like LOD, only
nearer geometry will be transformed with
details, and then other one.
What about 1000 people in different places?
I don't know anything about netcasting techno-
logies, but it seems something to be connected
with. Because mainly these people will receive
one and same data through one and same bones
of the net. Is there something which can be
optimized? Maybe you'll show us...
I'm only with 33600kbps modem, will it be suf-
ficient to watch the show?


September 15, 2000, 10:44 AM

Here's a, perhaps relevant, example. On a 2.5d overhead view project we were working on recently, we started out by generating the terrain algorithmically as well as texturing it algorithmically, by normalizing the terrain height to 1, dividing it by the total number of terrain types for that level and bilinearly interpolating between the closest two textures to create a tileset for the terrain. Lighting was then applied by calculating the gradient field of the terrain and deriving the surface normals from that, then entropy calculations were used to generate a movement cost grid, etc. Well, once the project began approaching production stage, it became clear that algorithmic terrain wasn't going to cut it. We needed distinct terrain features such as rivers, mountains, etc, as well as enemy unit placement that simply couldn't be generated algorithmically. So one of my co-workers whipped up a heightfield editor which let the level designer create a level as a greyscale heightmap, and then hit a key and view the heightmap with the texturing, lighting, etc, applied. In other words, while ultimately the level data was created algorithmically, the artists had a lot of control over how it was going to be generated, and at the same time didn't have to spend weeks designing unique tilesets for each level. I really think that this sort of an approach cuts production time drastically while not sacrificing artistic quality or input in any way.



September 15, 2000, 10:50 AM

Ok.. say your world is 500000 polygons.
Is there any need to transfer everything to user?
Wouldn'be a better solution to transfer only
NON-OCCULED ONE... Or polygons just in users FOV.
There can be an extra fast server which is optimized
to choose for every connected user which polygons to
sent using simple FOV clipping, which can be though
highly optimized for parallel execution. Every poly-
gon can be have bitfield or some tree structure,
showing to which user to go. Otherwise there will be
too many traffic. I think soon people, will began to
care not only about power management savings, but
also for network traffic. Of course this idea is Ok
just for VISUAL WALKTHROUGH, not for realtime gaming,
but a lot of REAL ESTATE or similliar business wants

BTW: There is a cool terrain renderer (using voxels??)


September 15, 2000, 10:52 AM

malkia, i think the idea is that everything is generated procedurally, client-side. i.e., the server transmits a certain set of parameters, object placement, etc., and the client generates the geometry on its own, eliminating the need to actually *transmit* the geometry.


September 15, 2000, 10:57 AM

goltrpoat: yeah, i've missed totaly this... I was thinking about those cool quake like inside buildings, or Aifell tower like ones, or planes or non-terrain related, which must be transffered. Totally forgot about that world will be generated...


September 15, 2000, 11:01 AM

malkia, you'd be surprised how wide is the range of objects you can generate procedurally given a set of initial parameters. one example, although hardly the best, is the infamous teapot.


September 15, 2000, 11:03 AM

Looks pretty cool!

Malkia, since it's all procedural only the procedural parameters will be transfered, not the polys, afaik. So transfering the world through a 56k modem shouldn't be much of a problem.

Other than that I quite tend to agree with goltrpoat, design work is always needed and what Thad suggested about computers filling the gaps is probably the future.


September 15, 2000, 11:18 AM

goltrpoat, yes that's cool. But a lot of people just need to
see their favourite DRAG RACING car over the web, or their
favourite FEMALE MODEL or whatever which was real, created
over the millions of years by synthesizing and combining.
So mostly what you can express is something which nature
was able to produce in it's first days - which was almost
nothing. Well i'm not against it - it's look very cool,
especially Perlin noises and his hypertextures...
And it can be used not for modeling the main form, but
just the grooves around it - like the cool rap and hip-hop
tunes. But it really needs some ARTIST to look around.
Well people have now chomsky generators, beethoven midi
generators, world generators, behaviour generators, so
everything can be generated. It's just that we are something
created with billion of years trying to play with the
1hour caculation of the creature of the P3 processor.
I don't see processor speed increasing for next few years,
mainly because of this incoming XBOX and other consoles,
which will be TIGHTLY on internet. So you can't improve
so much the algorithms. The only thing you can improve
(again) is the SERVERS outside the world, and speed to
every CLIENT. I was hoping that at that time i'll have
16processor machine with say P3, and next year 32cpu's.
I've read that sony is going onto that direction, but
it will be out in 2001 or maybe 2002.

I've gotta to sleep, i think...


September 15, 2000, 11:28 AM

malkia.. you're not following. for instance, the project i'm currently working on is more than capable of creating, to use one of your examples, a recognizable model of the eiffel tower given a hyperellipsoid, a clipping plane, a few boxes and a boolean algebra equation. 50-100 bytes of information at best.


September 15, 2000, 11:29 AM

err.. i meant superellipsoid. a hyperellipsoid is something else entirely :).


September 15, 2000, 01:34 PM

I think this is exactly what I need for a MMORPG engine Im workign on, however I can wait until thursday for this, where can I find info about procedural terrains meanwhile?

I agree that you need to give artists room to play, but tell them they have to design an entire world, and they wont be happy, this could really help...

This may sound silly ut how could you do the same with buildings and such?


September 15, 2000, 01:36 PM

This is one fine looking bit of 3d work in the wireframe, but the polygon one looks a little ugly, and unlit. Good work though.


September 15, 2000, 06:07 PM

I'm sure it could. Not all objects are defined as 1 procedural equation. Quite the contrary. During the pre-load phase your client would recieve a texture or object which would be a series of layered procedural equations. Textures could be 1 for the base, 1 for grit, 1 for cracks, 1 for moss. Okay, sure its a lot of layers, but considering the size of a texture, its peanuts. I'm sure many objects can be created through the general basis of clipped geometry and such. There will be the enviromental objects that wouldn't be very reasonable to be created with equations though, such as a car. Most of it really depends on what your target genre is I would assume. I doubt FPS games could benefit from this nearly as much as games such as EverQuest or Asherons Call.


September 15, 2000, 07:42 PM

I'm sure with a fancy bit of footwork, one could procedurally generate a car - some companies are experimenting with similar techniques for "evolving" new automotive engines. Just decompose the car into components (quarter-panels, hood, etc.), and further turn the description into points on a patch. Find a way to generate similar point distributions procedurally, and viola. Of course that's way beyond just over-simplification, but you get the idea - it's all ultimately in how you look at the data, and how you break it down. That's why they say math is the universal language, I guess.

While directly generating an indoor FPS level procedurally would be a nightmare undertaking, it doesn't seem impossible.

Mark Friedenbach

September 15, 2000, 09:16 PM


Not much more needs to be said. They proved it works, even if it's mostly 2d.


September 15, 2000, 10:17 PM

man, i have got to catch that presentation.


September 16, 2000, 12:59 AM

Here's something I've been playing with lately, in an attempt to get the best of both worlds. The terrain editor tool proceduarlly generates a terrain, and then the artist can rework patches of it, and run a few simple filters over it. The editor stores the generator paramaters, and the deltas for any changes the artist makes (usually tweaking areas to add buildings, etc). This is much smaller than storing the entire landscape as a mesh, but still gives artistic control where needed.


September 16, 2000, 05:55 AM

Brute force is one thing, but you don't want to get silly :) If you generate and cache your data ahead of time, you can VIPM it (which is very quick) and you can also add in a precalculated visibility set (a quickly generated one). The visibility set can be very quick at runtime (similar to the Quake PVS idea), and the VIPM is just a handful of fast integer instructions per collapse.

Kim Pallister

September 16, 2000, 06:43 PM

Wow! Glad to see this generated such a thread. Some comments to the comments of others:

- A couple people asked about performance: IIRC (I'm mailing from home, not work), it's about 20-50fps on a Pentium III Processor running at 600Mhz, using a GeForce2, SW T&L. (I'm getting comparable performance with HW T&L).

- Several people commented on lighting. I had ambient a bit high there, but there is lighting going on. In the demo, a 1D noise function animated over time determines the cloud level, the amount of cloud varies the lighting from low ambient/hi directional (no cloud) to medium ambient medium directional (full cloud cover). This is a hack but looks OK.

- A couple people asked about the poly count of the tree. Umm... A lot. That's where we get the jump from 55 down to 20 is when you get two of those in the picture. yikes. There's a variable that we use in our tree generator that varies the 'density' of the tree, so you can generate them with less leaves.

- trees are swapped out for impostors at some distance (20m?). The impostors have been generated using the polygonal trees, so they look pretty good.

- On the LOD scheme or lack thereof, I'm not saying that brute force is better or worse. There's a ton of debate there and I don't know which is right. The point is that I was just trying to do procedural generation, and an LOD scheme would have meant more time and obfuscating the code.

- The sky isn't exactly a dome. It's a plane that's been bent down into a dome shape. Picture dropping a 1 meter tablecloth over a sphere with a 1.5 meter diameter.

- On the 'give the artists control' school of thought. Absolutely. They need to be (a) given control over how the generation occurs (function values, seed values) and (b) the ability to modify the result. I beleive integration with authoring tools will be the key to successfuly using procedural techniques. On the other hand, have your artists try generating trees without procedural assistance.



This thread contains 25 messages.
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.