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

Submitted by Tim C. Schröder, posted on December 24, 2000

Image Description, by Tim C. Schröder

Here you see a few screenhots of my new terrain engine. The upper left picture shows the detail texturing and the sun. You can see the glitch where the sun's flare shines trough the mountain. Thanks to the Octree and my triangle class, this problem is gone now. On the right side you can see the Octree, red nodes contain more triangles. The pics in the middle show various heightmaps. I think you can see how nicely the procdedural generated texture looks. In the lower-left corner are some screenhots of early version of the engine. The last pic is a water-only view. The cubic environment mapped water looks so cool that I think it deserves its own picture ;-) I hope you enjoyed the view. If you want further informations and want to download source & exe (when it's released ;-( ), visit my homepage . Some of the source that was used to create the engine is already in my code archive. I also would like to hear a few ideas on what to include into the engine. I'm currently thinking of some kind of algorithm that removes occluded montains. I also want to do lensflares and a moving cloud layer. Bird, butterflies, fishes and trees would also be cool. Oh, and underwater fog and rain and... Way to much...

Tim C. Schröder

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.

December 27, 2000, 02:40 PM

Very cool. The shadowing looks nice, although off slightly(?), I was curious as to what those numbers in the upper left corner mean?


December 27, 2000, 02:57 PM

Well, I'm happy I've done with my lighting stuff, even when some people bitch on me and my method (hi fluffy ;)). Even if you use precalculated lightmaps it does not mean you can't use dynamic lighting for local objects emitting light, and to me even for landscapes with a lot of details (read a-lot-of-small-triangles) static lighting just looks better and is faster (you can use per vertex dynamic lighting to compute approximately the amount of light falling on a surface but with the usual per vertex lighting you can't get realistic results - how do you want to handle the case when a bigger hill covers a smaller hill and puts it in shadow? (argh sorry for my bad english I hope you know what I mean). You can try to use some methods of realtime shadow casting which are slow and produce minor results or use lightmaps (sure, all have their advantages and disadvantages and on the long run I'm pretty sure real-time will take over but it will take some years until then...)


December 27, 2000, 03:05 PM

Sorry, I can't give you much advice on all this, I jus wanted to leave me a few options open. I go for the precalculated per vertex stuff...

The numbers are the poly counts that are visible...

After my setup dialog is done and most other stuff is polished, I try to get my lighting/shadow stuff working. I still have lots of issues with parallel/conic rays, shadows, abient brightness and illumination models.

Can anyone give me to some meterial about this topic ?



December 27, 2000, 03:46 PM

U know... I feel that there are some strange things is going on. Same IOTD for 3 days... it's really one of christmas miracles ... hehe

Phil Carlisle

December 27, 2000, 03:51 PM

Well, from my own experiments Tim, per vertex lighting using a byte per vertex (in exactly the same way as the heightmap) works great.

I cant remember where I saw it, but I saw a DX8 demo of a landscape similar to yours with this type of lighting, and it worked just great. I used a similar thing in my own landscapes, but "baked" it into the generated texture I was using (save on texture mem).

Only thing I'm interested to try out is the use of a filter on the lighting values to soften the lighting somewhat.. Its an easy step if you calculate the lighting values into a bitmap and use photoshop to filter it in different ways (multisample blur for instance).

Definitely a nice looking landscape, youve got the quality of the textures down really well. My own stuff is kind of similar, but I have a more pressing need to support larger area's (using a Quadtree and some simple LOD manangement).

I'm interested to see where you go next with this tim :))



December 27, 2000, 04:16 PM

Ogotay: I didn't mean that making a texturemap of the lighting (i.e. a lightmap) is bad, just in combining your landscape texturemap with the lightmap for the single texture. It makes dynamic lighting MUCH slower, since you can't just upload a new lightmap but have to recalculate/reblend your entire texturemap, or waste a lot of texture memory by having both an unmodulated and a modulated version of the texture for the purpose of dynamic lighting, or whatever.


December 27, 2000, 04:37 PM

I don't have any external storage of lightmaps or so... I just calculate EVERYTHING at startup, even the texture is procedurally calculated from some small base textures. I just need to get a few sunlight issues worked out ;-) If I decide to handle dynamic lighting, I'll do it per-vertex...



December 27, 2000, 08:00 PM

I think it's just a communication problem between the two of us. I don't have to TOTALLY disable cube mapping. When done using it, THEN disable it. So the code would be like this

unsigned long CWater::DrawWater()
unsigned long iPolyCount;

// Save current states, need to recover later

// Set correct blending mode
glBlendFunc(GL_ONE, GL_SRC_COLOR);

// Set up texture coordinate generation for reflections

// Turn on the coordinate generation

// Use the water cube map, this does

// Place the surface at the correct height
glTranslatef(0.0f, m_fWaterHeight, 0.0f);

// Draw the surface
iPolyCount = DrawSurface();

// Restore
// now don't need cube map, disable it,
// perhaps there should be an Unbind function in CCubeMap

return iPolyCount;

So here's my theory. GL_TEXTURE_CUBE_MAP_EXT state is not saved by the Radeon drivers when you do the glPushAttrib so it is not disabled when you do glPopAttrib. So to make sure it is turned off, I manually disabled it when it wasn't needed anymore.

Hope that helps clear up the communication problem. It does with WITH CUBE MAPPING on the Radeon if you remember to turn it off when you are done with it :)


December 27, 2000, 08:34 PM

Damn, sorry ;-) I never realized where you put this statement... the glPushAttrib call doesn't save anything like multitexturing or cubemapping, but nVidia drivers seem to disable it when texture2d is active, thanks a lot ! So I can finally announce that the demo is Radeon compatible ;-)

BTW: I'm made some nice chnages to the lighting code, it's simpler now and works good. Need to tweak it a bit and fix some errors in the water code...



December 28, 2000, 08:55 PM

Hey, Tim:

Your terrain demo fails to run on my computer.

I get the message "Can't load terrain data!" and then I get a nasty
illegal operation.

I compiled your source and traced the failure back to InitVertexArrays().
I'm guessing some extensions failed.

How can I fix this?

My machine: P3, Intel 810 AGP 20MB VRAM.

Oh, I downloaded the demo today, so it is the newest one.

BTW, where can I get a OpenGL program that can dump all extensions
that my 3D card supports?

Mark Friedenbach

December 28, 2000, 09:55 PM

Hemp: the following program should work (I haven't tried it)

#include <string.h>
#include <GL/gl.h>

char *ctemp, *ext = (char *) glGetString(GL_EXTENSIONS);

ctemp = strtok( ext, " " );
(NULL != ctemp)
puts( ctemp );
ctemp = strtok( NULL, " " );

Stefan Karlsson

December 29, 2000, 02:52 AM

bah.. opengl code making this iotd thread looking like shit


December 29, 2000, 05:33 AM

So what?

I've read a couple of your previous posts and they are all
so very constructive. I think you make an ass of yourself more
times than I can count. I would like to get this program running,
so if you nothing good to say, then shut your hole.


December 29, 2000, 10:19 AM

I'm not sure thats going to work because you dont have an active GL context anywhere. I'm pretty sure you have to set up a window and create a HGLRC before you can call glGetString. I could be wrong, it's just my experience that you need an active context. E-mail me if you need a small program that will show you what extensions you have. Or go to NeHe's tutorial site, he has one all about extensions.


December 29, 2000, 05:55 PM

You're right.

glGetString returned NULL and the program gave me an
illegal operation.

I'm new to OpenGL as you can tell, so I'll give NeHe
a try.


December 30, 2000, 04:59 PM

Woops, Slyce is right. I don't actually work with OpenGL, and I took that piece of code right out of the OpenGL Programming Guide (with a few modifications). I guess I should have checked to see if that code depended on anything. The following piece of code does work (I've tested it):

#include <string.h>
#include <GL/gl.h>
#include "glut.h"

(int argc, char** argv)
glutInit (&argc, argv);
glutInitDisplayMode (GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH);
glutInitWindowSize (640, 480);
glutInitWindowPosition (100, 100);
glutCreateWindow ("test");

char *ctemp, *ext = (char *) glGetString(GL_EXTENSIONS);

ctemp = strtok( ext, " " );
(NULL != ctemp)
puts( ctemp );
ctemp = strtok( NULL, " " );

This thread contains 76 messages.
First Previous ( To view more messages, select a page: 0 1 2 ... out of 2) Next Last
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.