nice. how do you create the world texture? the rednered image looks a little bit "dirty".

Really nice work. Any chance to see a demo or source ?

Lighting seems good, are you using a directional light source? If you are, don't forget how nice point lights can look. It seems you have come up with a decent way to reduce the workload in applying a pointlight in real time (make lightmaps on the fly). Effectivley, you are lightmapping the texture before you render with it, no?

comella: Well, I did not really unterstand what you mean with "dirty" (?), but to answer your question: To generate the (unlit) texture I am using a simple method I came to via trial'n'error - for each texel I first calculate something I call a "mixing-factor" (MF) based on the vertex normal of the corresponding point in the heightmap that I clamp to the range of [0, 1] and calculate the final value like this

texel(u,v) = MF * texture1(u,v) + (1 - MF) * texture2(u,v)

Then I mix the texture I get this way with a precalculated lightmap.

Wolfgang Engel: Yes, I plan to release a demo, but before it happens I want to fix view things. Morover, the terrain drawing isn't yet optimized (except frustum culling) and I don't want to release crap ;). I hope to be able to release a demo quickly, but the college and work take a lot of my time that I need to make the necessary progress in the engine so that I can release it without shame. But it will happen :), I will post a link to here on FlipCode then.


Raspberry: I am actully using a point light. And it is NOT realtime, unfortunately. I am precalculating the whole texture and the lightmap, not doing it "on the fly" :(. And the tools I am using are everything but not fast, but they do their job, and I don't think I will ever optimize them for speed (however I may improve them to add new features, they're all put together very quickly and my code is a mess ;) ), because I have a lot of other stuff to code and sooo less time :( - and they are only supposed to be in-house tools.

Looks pretty damn impressive! Great textures and lighting!

Very Nice.. are you thinking of using quadtrees?

Very nice work!
I hope you're having fun with this project. Make sure you do a lot of work on it NOW... because when you graduate I can guarantee you that you will have MUCH less time to work on personal projects. :(
But then... if anyone said this to ME when I was in school, I would have laughed hysterically :)

Thanks for your comments guys :).

I am not sure what kind of algorithm I will actually use to finally optimize the terrain drawing, but I think there are faster algorithms than quad trees. I started implementing ROAM when I read Willem H. Deboer's (hope I write his name correct, if not please don't beat me ;) ) paper where he described his own technique - so after reading it I started to implement the algorithm he described. But his approach is not suitable for terrains that may change dynamically and this is an option I may want to keep (imagine a bomb or a rocket causing an explosion and deformation of a part of the terrain - the only problem would be how it would affect the static lightmap but I think I could use some tricks to avoid lighting artifacts). At the moment I think I will try something like this and see how fast it will be (and how good it will look like): I already "cut" the terrain in patches and make simple view frustum culling to them. The next step would be just reducing the triangles drawn in each patch based on the distance and doing some geomporhing to remove popping. It's a straightforward idea and should it be fast enough I will keep it. But I want to stay flexible, I may change my mind later ;).

Oh, and Paul: I hope to become a professional game developer one day so that my personal projects would be the same projects as at work :).

looks really nice

Q:How big are your final texturemap and your heightmap?

Both the size of the texturemap and the heightmap are free scalable, however they have to be 2^n for n > 1 (for the texturemap) or 2^m + 1 (for the heightmap, m > 1) and the width and height must be the same. In the above screenshot I used a 257x257x8Byte big height map and a 2048x2048x3Byte big texture map (the texturemap was converted to a 16Bit image at runtime and the heightmap to a 257x257 floating point representation - so the texture takes about 8MB of memory). This makes (expressed in triangles) a total of 256 * 256 * 2 = 131072 triangles.

Instead of generating a single static texture for the landscape, why not just generate blending values for each vertex based on your greyscale image and then draw the landscape in two passes, one with blending disabled and one with glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)? That way you don't need one big honking texture (or set thereof) for all your polygons. Of course, if your blending map is at a higher resolution than your landscape you'd want to use multitexturing instead (to modulate the second texture with the blendmap).

This is the typical way of blending between textures in heightfields, and although it's conceptually a little slower (takes twice the fill and vertex rates), it looks much better and can easily work out to being much faster when you account for the big savings on texture memory.

Hmm, interesting idea. But how do you calculate the blending values for each vertex (at runtime each frame if I understood right, otherwise you had to store this information somewhere in the memory ending up with the same memory usage)? And there is still the problem with applying the lightmap, not only I had to store the lightmap in the (texture) memory, I would furhermore need another pass to render it, so I would end up with 3 rendering passes.

Oops, I think I understand you now, my fault, needed a couple of seconds, LOL. Well, the idea is good, but the problem with 3 rendering passes (and this IS a problem with the amount of detail I plan to use unless you have an Athlon 800 and a GeForce 2 ;)) still remains and it does not allow unique textures. And it reduces my memory requirements "only" by max. 2/3 (if I store the lightmap in a 8Bit luminance texture). I think it's more suitable for large area terrains (massive multiplayer games?), but what I am actually aiming for is a kind of closed area battle game. Don't want to say too much at this moment, but it's best described as a mix of Worms and a FPS-kind of game with multiplayer support, where players can kick their a***s in a closed area with unconventional weapons and weird powerups/extras.

Very nice images.

I am using the same tech in my terrain engine. But ...my terrain is/will be very big ..some times... so i need to have a much bigger than 2048x
texture ...to see any detail.
The method of fluffy is an very good option....if it's well implemented .... only the multipass solution is discouraging (that's way i prefer to find
another way). Even for small terrain, more detailed texture(s) is an big advantage.

Before choosing a terrain subdivision/render tech...take time to read all possible articles. They will give you plenty of ideas ...and will avoid you
to fall in many traps.
You are considering ROAM. It's nice ...but it's slow ..it uses to much CPU.
The quad tree way is best for optimization on modern hardware.. especially when using hardware T&L ...and DirectX VBs.

Anyway ..the best way is to experiment ...

PS. Fluffy ..can you tell me more about your method of texturing ...or where i can read about ?

ive got a couple of examples of blended textures on my site with source code as well.
check gotterdammerung out for my landscape pictures (last 2 shots) rendered with one multitextured pass
http://members.nbci.com/myBollux

Well it's clear to me that the method described by fluffy has some advantages over the method I am using, but it all depends on what you are trying to do. I wrote why I don't think it'd be very useful for my project in one of my above posts. And the size of the textures that may be used by my engine are limited only by the memory capacity of your card or your system RAM (read one of the other posts, too). Btw I must say when using lightmaps the texture mixing method would save me actually not 2/3 but only the half of the memory space, since I convert the texture to 16Bit per pixel and the lightmap (if kept separated) would still take 8Bit per pixel.