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


Submitted by ogotay, posted on December 13, 2000




Image Description, by ogotay



I am working on a 3D terrain engine at the moment (working name eXodus ;) ), and here are some pictures showing the features of the engine itself as well as the tools I wrote for the engine so far.

The first tool, I called it TGenTex takes two simple textures (shown on the pic in the top-right corner) and a grayscale image containing heightmap information for the terrain and computes an unique world texture for the terrain (bottom-left corner).

The second tool, a simple radiosity calculator (uhm, I called it TRad, what else? ;) ), takes the same heightmap file used before with TGenTex and a position vector of a point light source (well, only one, don't need more for my engine at the moment, one light source simulates for example the sun shining over the landscape) and outputs a lightmap showed in the middle-top area of the above picture. The last tool finally, which I called creatively TMelt (hmm... ;) ) mixes both the lightmap and texture files generated by the other two proggies and computes the final World Texture (tadaaaaa) - you can see it in the top-left corner.

The last part of the pic in the bottom-right shows the engine in action (again, tadaaaaaaa ;) ).

Maybe some words on the engine itself. It is still under development but there are already some nice features implemented (like multiple animated sky layers =) ). What's important, I want it to become a full game engine one day, supporting physics, multiplayer support and all the other stuff. Well, yes... I think that's all for now :). Oh yeah, almost forgot, for anybody interested: the engine uses OpenGL and is written completely in C and inline Assembler (didn't use the last very often 'till now, however).


[prev]
Image of the Day Gallery
www.flipcode.com

[next]

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

December 13, 2000, 04:10 AM

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

 
Wolfgang Engel

December 13, 2000, 05:07 AM

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

 
Raspberry

December 13, 2000, 06:09 AM

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?

 
Ogotay

December 13, 2000, 07:11 AM

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.

 
StiNKy

December 13, 2000, 07:45 AM

Looks pretty damn impressive! Great textures and lighting!

 
The Wolf

December 13, 2000, 12:13 PM

Very Nice.. are you thinking of using quadtrees?

 
Paul

December 13, 2000, 01:04 PM

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 :)

 
Ogotay

December 13, 2000, 01:36 PM

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 :).

 
Aragorn

December 13, 2000, 02:11 PM

looks really nice

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

 
Ogotay

December 13, 2000, 03:02 PM

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.

 
fluffy

December 13, 2000, 03:50 PM

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.

 
Ogotay

December 13, 2000, 04:04 PM

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.

 
Ogotay

December 13, 2000, 04:22 PM

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.

 
d@t@m@n

December 13, 2000, 07:33 PM

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 ?

 
zed zeek

December 13, 2000, 11:03 PM

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

 
Ogotay

December 14, 2000, 02:24 PM

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.

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