| Thursday, September 29, 2005 |
 Another terrain prototype video |
Posted - 9/29/2005 7:42:27 AM | I think this video is much more impressive.
Get it here (20 Mb Divx 4)
| |
 Terrain texturing (continued) |
Posted - 9/29/2005 4:21:32 AM | 
So, i've fixed the normals bug i mentionned in the previous entry. Just to have fun, i also added back the heightfield geometry, so that the terrain's no longer flat. Cracks and seams are present but i don't care since it's only the texturing prototype, not the terrain one. For the same reason, i'm rendering in OpenGL's immediate mode, so the framerate suffers, but since i know it's not due to the texturing process.. i'm not worried.
Above you can see a screenshot of a mountain side. I've got a couple more nice screenshots to show, but i decided to submit them in a new image of the day :)
| |
| Wednesday, September 28, 2005 |
 Terrain texturing (continued) |
Posted - 9/28/2005 8:06:38 AM | 
So, i've discovered a major bug in my texturing code. I'm not scaling the normals amplitude with the terrain patch's size. I think this is the cause of the mismatching look between low-altitude slopes and high-altitude slopes. More on that later, hopefully i'll fix it soon.
Am i posting screenshots too often and boring you to death ? Or should i continue at the same rate ?
| |
 Terrain texturing prototype video |
Posted - 9/28/2005 4:50:51 AM | I promised it a few days ago, here it is:
Terrain texturing prototype video (10 Mb Divx 4)
I've fixed a lot of little details, implemented blending to hide transitions (although some popping might still be visible sometimes), but keep in mind that what is shown in the video is only the texturing prototype: the terrain itself is made of flat quads, hence not really 3D. It's obviously missing all the final effects (clouds, vegetation, atmosphere, etc..) until i integrate it in the final code.
As usual, it is 100% real-time and nothing is preprocessed (everything is generated on-the-fly)

| |
| Tuesday, September 27, 2005 |
 Ain't it Terragen-like ? |
Posted - 9/27/2005 8:52:01 AM | 
It's nice not to see any repeating pattern, thanks to procedurally generating uniquely every terrain patch. This is a shot of a mountaineous area as seen from 5 km above.
Here is one closer to a coast line:

| |
 Terrain texturing (continued) |
Posted - 9/27/2005 4:34:35 AM | 
So i've finally implemented the texture manager and the cache. I've also added a simple quadtree that refines the textures based on the distance to the terrain patches. It's working pretty well.
I'm a bit disapointed by the terrain textures though. It looks pretty good in the screenshots, but quite repetitive when you see the whole world with similar texturing. I have to add some variety.
The terrain patches that are far away, especially when you descend at ground level, become "aliased". Adding mipmapping didn't help. It's not a big deal since in the final code they'll most likely be hidden by atmosphere haze, but still, i'd like to improve a bit their look.
Getting nice coastlines is not easy. If i reduce the amplitude of noise to get realistic coastlines, i get a lower quality in the landscape, like in the grass or rock areas. If i increase the noise, coastlines start to become a mess of noisy fractals. To fix that, i'll have to add a per-pixel parameter which determines how noisy the area is.
I can't seem to get good lighting at all scales. If i tweak the parameters to have some nice shading at ground level, the terrain as seen from a few kilometers away becomes noisy, and vice-versa. I think one of the solutions is to drop the lower octaves depending on the camera distance, but implementing that in a pixel shader 2.0.. hum.
Then there is the detail textures, the blending to hide the popping between different texture levels, and a lot of small details like that..
| |
| Monday, September 26, 2005 |
 Terrain texturing (continued) |
Posted - 9/26/2005 7:57:58 AM | 
By adding more noise octaves and adjusting the parameters, i succeeded to make the texture look less blurry and generally, have more details than the last one.
In other news, i've discovered a driver bug on ATI cards, from Catalyst 5.5 to 5.9. Some operations in a pixel shader get corrupted, and some random, blocky pixels of flashing colors appear in the texture. It does not happen in Catalyst 5.4 nor on NVidia cards. I've email ATI about the problem, now waiting for an answer.
Things are getting quite exciting: my next step is to make a manager and a cache for the terrain's texture, and to generate multiple terrain textures at the same time. I'll then "simulate" what's happening in geo-mipmapping, but on a flat, single-quad patch only, and apply on each patch on of these textures. Then i can work on transitions and potential "seams" problems. If i succeed i'll make a video demonstrating it in the coming days.
The terrain above is generated at 120 fps on an X850.
| |
| Sunday, September 25, 2005 |
 Farenheit |
Posted - 9/25/2005 7:57:46 AM | So, i just finished "Farenheit". I don't regret buying it, especially as it's an adventure game, a genre that is pretty much dead now. Unfortunately, it's far from being perfect.
The good:
- the scenario (at least the beginning - the end is.. hum... too much Matrix like for me)
- the user interface: pretty original, easy to play.
- everything is logic - you will not find actions where you have to combine item X on item Y to trigger action Z, and only then understand why you had to do that :)
- the musics
- the animations with motion capture
- the replayability (for a solo game), and some of the bonus
The average
- the graphics: after testing the demo i would have said they were just "bad", but the full game is much better than what i was expecting after trying out the demo. There are many little effects, dynamic shadows, glows, noise filters, that are really nice. On the other hand, the textures are generally ugly, except on some of the characters, which even if they're not normal mapped, look quite nice.
- the action sequences: press the right combinations of keys at the right moment. Not my cup of tea, but didn't bother me too much either.
- the freedom: i was expecting much more than what's delivered. So, depending on your actions in the past, you might miss a few character thoughts, or a few sequences.. but globally, the story is extremely linear.
The bad
- the end of the scenario: as if it was badly rushed. The Matrix sequences just didn't seem to fit very well. And i must say, that love story between Carla and Kane.. what the..?
- the psychological system: although i think it's a good idea, it is violating one golden rule of game design in my opinion: when you fail an action, you should immediately know it. But here, you can fail and continue to play, which means you'll only see the consequences a few scenes later. Sometimes the game is basically "lost" and you don't know it until a while.
- the cameras.. just no.
| |
| Friday, September 23, 2005 |
 Improving terrain textures |
Posted - 9/23/2005 10:56:04 AM | So, i have improved by a lot the way the color table is generated.
It's similar to texture splatting; i have a set of layers (12 here), that each contain some conditions on the altitude and slope, an interpolation power, and a color. In the color table, for each texel i get the slope and altitude, and determine the layers affecting it. These layers are then blended together.
Don't forget that the generation of this color table is done once per planet, at construction time. So, i do not really care if there are 12 or 100 layers. In theory this allows me to make some planets with extremely varied terrain, although with "only" 12 layers, i think the results are starting to look good..
I can't decide which of the two textures is the best:


The first texture uses the layer which has the best weight, while the second one blends all the layers which have a weight > 0. The second one has smoother colors, but i'm not sure i really want this, as it'll make the textures less precise when appearing on the whole planet.
Opinions ?
| |
 Starting to work on the color map |
Posted - 9/23/2005 5:04:53 AM | 
I'm using a 2D lookup table where i encode U as the slope of the terrain, and V as the altitude. This table is pre-generated on the CPU, and so far only contains 4 constant colors (for a quick test).
In the pixel shader, i sample the terrain and get the normal / altitude. I then use normal.y as the cosinus of the slope angle to do the lookup.
It's a very quick test and will only improve as i add more shades of colors and better parameters.
Ultimately, i think i will try not to encode colors in the table, but weights to texture layers. As a single color can only store 4 channels, i might end up using 2 lookup tables like this, which will give me up to 8 texture layers. Similar to texture splatting.. but on a per-pixel level :)
At the moment, the texture shown above is procedurally generated at more than 60 fps on a PIV 1 Ghz + Radeon 9700. I'm not worried about the performance though, as these textures only need to be generated once when the terrain patch is loaded. After that, everything is cached.
For the full planet, i think i will not have to generate textures more than a few times per second.
| |
| Thursday, September 22, 2005 |
 Improved (and faster) terrain normals |
Posted - 9/22/2005 11:56:18 AM | I successfully removed the blur passes, which increased the performance by a lot, and should help to avoid the seams problems in the whole terrain.
It's a bit tricky, but it now works that way:
1. I'm generating a 33 x 33 normal map.
2. I'm upsampling that normal map into the 512 x 512 texture; normals are filtered and renormalized at that step.
3. Instead of adding a scalar noise to the heightfield, i'm now adding a 3D vector noise to the normals. I'm using 6 octaves. Each having different weights. Then i'm renormalizing the final vector.
I'm also storing the heightfield in the alpha component, which means the same process is done for free for the heightfield (except the renormalization of course, since it doesn't make sense for heights).
The quality is IMO a bit better, and much faster:

Next step is to use both normal and heights to generate the diffuse color.
| |
| Wednesday, September 21, 2005 |
 Terrain texturing |
Posted - 9/21/2005 6:13:34 AM | I started to work on the texture synthesis for the terrain chuncks of my planet.
In the past, i have tried many different approaches. Namely:
1. Texture splatting: i've got many texture layers (grass, rock, sand, snow, etc..) and for each vertex of the chunk, i assign some weights to these textures. This work is done on the CPU asynchronously.
2. Unique procedural texture, on the CPU: for each chunk, a unique texture is procedurally generated, by using the heightfield and some noise functions.
The results:
1. Moderately fast, average quality. Dependant on tesselation. Morphing hard to implement since you must morph the weights too.
2. Awfully slow, better quality. Became unusable when you started to zoom on the planet's surface. A few mipmapping problems.
So, for the next (and hopefully last) version of the terrain engine, i'm going to try a different technique: a unique, procedural texture.. but generated on the GPU instead of the CPU. This should solve the performance problem.
At the moment i'm first trying to generate some good normals to, later, do lighting, but also texturing (based on the slope of the terrain, which requires normals).
The input is the heightfield for the terrain patch. It is currently 33 x 33. That's very low resolution. Assuming a 512x512 unique texture to cover this patch, the question is.. how to upsample that heightfield, add some noise (for more details), and generate normals.. all of that... without any artifact ?
I spent hours working on that. Some problems:
- upsampling using bilinear filtering: when differencing the heights for the normals, the derivatives are not continuous -> lots "grid-based" artifacts
- 8-bits heightfield -> normals are of low quality -> lighting is very bad
- so i tried to encode the heights as f32 into an RGBA vector, and to decode it in the pixel shaders. Works better, but still some quality artifacts.
- i switched to floating point textures. Problem: bilinear filtering is not available on them.
- so, i had to implement filtering myself in a pixel shader. I tried to smooth-step the filtering parameters, too. Improved the quality a bit.
- but even after that, artifacts were still visible. So i had to blur the upsampled, filtered heigthfield twice (with a 15x15 kernel size) in a pixel shader. This smoothened the heightfield (hence the normals) by a lot.
- finally, noise is generated by taking N pre-generated 2D Perlin noise textures and adding them together with varying weights. The noise is then added on top of the upsampled, filtered heightfield.
The result is rather nice, and is generated 100% on the GPU (which means real-time):

It's not finished though. I'm concerned about the blurring. It works well here, but when two terrain patches will be adjacent, the pixel shader will not have access to the adjacent texels. This means, an ugly seam might potentially appear. To avoid it, i'd have to not use blurring.. but i have to find a way to avoid artifacts too.
| |
| Thursday, September 15, 2005 |
 The gamedev effect |
Posted - 9/15/2005 4:44:04 PM | The gamedev.net effect
Fortunately i upgraded my web host a week ago, in prevision of the opening of my site..
| |
 Minas Tirith demo available |
Posted - 9/15/2005 12:50:25 PM | I have finished to upload the latest version of the Minas Tirith demo. Get it here.
Please note that it requires a good graphics card (128 Mb of video ram, 256 Mb advised), the latest drivers, and also a solid amount of RAM (512 Mb min, 1 Gb advised).
| |
Page: 1 2 »»
All times are ET (US) |
|
| S | M | T | W | T | F | S | | | | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | | 12 | 13 | | | 16 | 17 | 18 | 19 | 20 | | | | 24 | | | | | | | |
OPTIONS
Track this Journal
ARCHIVES
October, 2009
August, 2009
July, 2009
May, 2009
April, 2009
March, 2009
February, 2009
January, 2009
November, 2008
October, 2008
July, 2008
June, 2008
May, 2008
April, 2008
March, 2008
January, 2008
December, 2007
November, 2007
October, 2007
September, 2007
August, 2007
July, 2007
June, 2007
May, 2007
April, 2007
March, 2007
February, 2007
January, 2007
December, 2006
November, 2006
October, 2006
September, 2006
August, 2006
July, 2006
June, 2006
May, 2006
April, 2006
March, 2006
February, 2006
January, 2006
December, 2005
November, 2005
October, 2005
September, 2005
August, 2005
July, 2005
June, 2005
May, 2005
April, 2005
March, 2005
February, 2005
January, 2005
December, 2004
October, 2004
September, 2004
August, 2004
|