This topic is 2 pages long:   1  2  |
Author Topic:   Texturing Terrains
Bryan T
Member
posted April 26, 2000 03:42 PM            
Some new topics for discussion..

I'd love to hear about algorithms for texturing a terrain. I feel the current method (streching a pre-made texture across a patch) is a poor-mans method. I would like to see added detail on steep slopes, procedurally-generated textures, etc.

Also, physics-based models, like grass growing along slopes, water/snow flowing down mountainsides, lakes in a valley..

And more specificly: how to get patches textured without seams between them (I tried this on my demo but never could find a good method).

--Bryan

IP:

Chris C
Member
posted April 26, 2000 06:49 PM         
I've had an idea about adding blades of grass to a terrain engine - has anyone taken a look at nVidia's Grass demo or read their white paper on elevation maps? For close-up detail, grassy areas of terrain can have the elevation map technique used on them to create what should be quite convincing blades of grass.

Elevation maps are just normal texture maps, but with an alpha map that encodes the height at each texel, just like a regular height field. By using a subtractive alpha channel texture blend mode (OpenGL extension or DirectX7 standard feature), multiple slices (each one slightly above the other) of the texture are rendered. At each stage the diffuse alpha is reduced by the alpha subtract operation causing the texels with lower height values to become transparent. So the result is a very simple volume-like rendering of a height field. This could be used to render grass, additional surface detail etc. without loads of extra tiny polygons. nVidia use their dot-product texture blending extensions to add shading to their blades of grass, but sadly this is only possible with the GeForce or large numbers of passes.

I should mention that by rendering slices there is the problem that if you view any of this detail from side-on gaps will appear, but for close-up detail this may not be an issue.

I reckon this could be a nice extension to detail maps, what do other people think?

Chris

IP:

Klaus Hartmann
Member
posted April 26, 2000 07:46 PM            
Okay, I'll write a small paper about the algorithm I use to synthesize surface textures. This will take a couple of days, though, because I'm pretty busy.

In the meantime I'm offering some screen-shots. The first three images show some effects:

PICTURE1: Synthesis is based only on elevation.

PICTURE2: As picture 1, but slope-dependent ecosystems have been added (the brownish stuff).

PICTURE3: Same as 2, but elevation skewing has been added.

The other three images are just... well... some other screen shots.

Note the following:
-- the images would look much better if I had better textures.

-- you should be able to see some detail mapping. The detail map itself is rather bad, though.

Each image is about 110K: http://www.thecore.de/TheCore/picture1.jpg http://www.thecore.de/TheCore/picture2.jpg http://www.thecore.de/TheCore/picture3.jpg http://www.thecore.de/TheCore/picture4.jpg http://www.thecore.de/TheCore/picture5.jpg http://www.thecore.de/TheCore/picture6.jpg

If you have any questions, before the paper is finished, then feel free to ask.

Niki

IP:

Bryan T
Member
posted April 26, 2000 10:20 PM            
Cris,

I have a GeForce and played with a demo of the feature you are describing. It was nice, but the edge of the alpha mask was very sharp in the demo. You could easily see where one slice ended and the next began. This may be an artifact of the demo and not the feature itself. It would have been much more impressive to antialias the edge of the mask to blend it with the layer below.

At higher 'slice' resolutions, the artifacts were less noticable, but then again you're drawing the texture 32 times at that point. For close-up textures it would definitely be faster than rendering individual blades of grass...
--------------------
Klaus,

Very Nice! The shading is gorgeous, is it baked-on or dynamic? And what type of mountains are these? Fractal, artist-created, or GPS dataset?

So on to the texture-generation... Looks like you have a palette that is chosen from based on elevation with some form of stippling? (pic1) I can't tell the difference between stippling and a separate detail texture though.. I'd have to guess stippling since the green band arrives gradually instead of a sharp line.

The elevation skewing (pic3) makes the scene much more 'organic'. The green is not in a well-defined band across the middle of the mountain. It also appears to have an afinity for the lit areas. The brown didn't seem to budge though. And I notice the shading changed also?

Which of those numbers is your frame rate?

--Bryan

IP:

Klaus Hartmann
Member
posted April 27, 2000 12:43 PM            
Brian,

Here are short answers to your questions (the paper will be more detailed). When you read through the following answers, then you'll probably think things like "But I want dynamic lighting." Well, that's exactly why I'm writing the paper, because we can then discuss ways to compute the textures in real-time (and I believe this is possible).


-- The shading (Phong shading) is pre-burnt into the large surface texture. Gouraud shading doesn't look much worse, though (actually, it's tough to see the difference).

-- The mountains are fractals.

-- There's no palette of colors, but rather a palette of source-textures. These source-textures are blended together and the result is a large surface texture (bilinear interpolation). The choice of the source-texture depends on elevation, slope, and elevation skew. (It should also depend on the relative elevation, but as I said before, I haven't found the solution yet).

-- As for the detail texture. Look at the bottom-right parts of picture 2 and picture 3. Try switching between them with a program like ACDSee. You should able to see a slightly brighter pattern which doesn't change. This is the detail texture.

-- The elevation skewing: The brown didn't budge, because I didn't skew it. But I could easily do that by setting the brown's "skew-amount" to some value.
As for the lit areas. Yes, that's exactly what the elevation skewing is good for. Imagine some mountain. During a year, one side of the mountain will receive more sunlight than the other side of the mountain. Grass would, of course, prefer the warmer side (with more sunlight). This is what you can simulate with elevation skewing.

-- The shading did not change. It's just that my source-texture don't have equal intensity.

-- As for the numbers in the screen shots.
The left one is the framerate, the second is the number of visible triangles (inside the frustum), and the third number is the "desired resolution", which is part of the LOD algorithm I use. Note, that these screen-shots were taken in full-screen, and thus the framerate cannot go above 75 Hz. In addition, the rendering code is not optimized.

IP:

MarkBatten
Member
posted April 27, 2000 03:52 PM            
Klaus -- This is fascinating; I too was wowed by your beautiful shots. Tell me if I'm understanding correctly: in a preprocessing step you create a single large surface texture (how big?) by combining sources based on elevation etc., and then in rendering you stretch this large preprocessed texture over the whole map and then do a second pass with the detail texture? Is the detail texture the same everywhere? Thanks. Also -- remembering fondly our Rottger discussions in the other topic -- is your completed LOD code available somewhere? I'd love to peruse it.

IP:

Klaus Hartmann
Member
posted April 27, 2000 06:34 PM            
Mark,

-- The height field is 513x513, and the surface texture is 2048x2048

-- The source code to my LOD engine is not yet available. My current implementation (which now uses Direct3D) is not even complete... and it won't run on most hardware (not yet).

-- The detail mapping is the result of single-pass multi-texturing, and I use a single detail map (256x256).

-- As for the combination of the source textures. I first compute an ecomap that has exactly the dimensions of the height field. Each element in the ecomap is 1 BYTE, and serves as an index into an array of ecosystems (snow, grass, dirt, rock,...).
This is all the information you need to synthesize an unlit surface texture. This texture, however, is usually larger than the height field, and thus you need to compute more texels than you have actual elevation. I do this on a per-cell basis:

for each cell in the height field
..get the four involved ecosystems from the ecomap
..for all texels in the cell
....bilinearly interpolate the 4 ecosystems to find the final texel color.
..end-for
end-for

Well, I have to admit, that the above pseudo-algorithm-code is pretty much reduced But hey... it really takes a lot of time to describe the whole algorithm, and I don't exactly want to do that twice. So wait for the paper.

IP:

Bryan T
Member
posted April 27, 2000 08:39 PM            
*taps foot impatiently*

--Bryan

IP:

Klaus Hartmann
Member
posted April 30, 2000 06:32 AM            
Hi all!

Here's the first version of the promised paper.

PLEASE READ BEFORE DOWNLOADING THE PAPER:

(1) - The paper is not finished, yet. At this time it only explains the most important part of the algorithm (the ecosystems). Of course, I will finish the paper, but it'll take another couple of days. The remaining parts are pretty easy to implement, but I have to write a lot of text to explain them. For most of you, the information in the paper, will already be enough to implement their own algorithm, because all that's missing is stuff about "Combining materials with bilinear interpolation", and "Lighting". Those are pretty easy things, but they are cumbersome to explain.

(2) - You'll need Adobe Acrobat Reader to read the document.

(3) - Please let me know if you have trouble to understand the paper, or if you find any bugs or typos. You can find my e-mail address on the cover page of the paper. So please let me know about any problems. Also, I'm not native to English, so please let me know if the English in the paper becomes too terrible.

URL (about 1.8 MB) http://www.thecore.de/TheCore/synthesis.zip

Sorry for the size, but I did want to include some screen shots. I feel that papers about computer graphics should always include some color plates that show the final results.

IP:

Bryan T
Member
posted May 01, 2000 06:05 PM            
Klaus,

Looks good and very readable. Your English is fine, don't worry about that.

The results are remarkably lifelike. I think this technique could also be extended to work on non-heightfield datasets. My current terrain project does not load a heightfield at all but generates a few points at a time from a fractal (similar to Aelith's demo).

There is also a 'simulator' page that I found awhile back, I'll have to go dig it up again. Basically when generating fractal landscapes, they add additional layers for water, vegetation, ground type (rock/sand/mud/etc), etc. Then they ran a simulation, adding water around high points, which would flow to lower points. Adding vegetation where the water was high enough to 'support' it. And eroding away land types if running water crossed it, making river valleys, canyons, etc.

The results were not visually stunning as I recalled, but the algorithm was exceedingly simple too. Perhaps a blending of the two could improve the overall results?

Now I gotta get crackin' and write some texture generation functions!

--Bryan

IP:

Klaus Hartmann
Member
posted May 01, 2000 09:29 PM            
Bryan,

[1] remarkably lifelike
Quite some time ago, I was employed to some company, and I had to buy and understand a copy of Questar Production's World Construction Set. Back then, World Construction Set definitely was the defacto program to create realistic images of terrain. (This program is like Terragen, but much more involved, and much more expensive.) Anyway, I was so fascinated by their ecosystem editor, that I tried to implement some of the most important pieces of this system, and I have done that successfully. There's only one exception: the relative elevation effect.

So yes, I think the results are lifelike enough, if they are realistic enough for a $1000+ program.

I haven't tried this myself, but if you are going to raytrace a landscape, and then apply the ecosystem algorithm to each pixel on the screen (you'll, of course, need to add sub-samples to the height field), then you can produce those very realisic-looking images.
Have a look at the following *simple* image: http://www.3dnature.com/images/rainier3.jpg
You could really do that with the algorithm, if the relative elevation stuff would work.

[2] non-height-field datasets
Yes, you can easily use this algorithm with non-height-field datasets.

[3] 'simulator' page
I'll kiss your feet, if you can dig up the URL to that page. If they are able to make water flow downhill, then they did solve the relative elevation problem. As for "The results were not visually stunning...". Maybe this is due to limitations of artistic skills. Take my images for example. They could look much, much, much, much better, if I had a better feeling for texture, and if I didn't rely on seamlessly tilable "source"-textures. My textures are, for example too comic-like. You know what... I'll try to make some more realistic textures, and then show some screen-shots that look more real. It'll take a couple of hours, but I've always wanted to do that (I'm still using my first set of test-textures).

Good luck with the texture generation functions.

Niki

IP:

Klaus Hartmann
Member
posted May 02, 2000 01:03 AM            
Even though it's not my style to provide bad source code, I decided to make an exception. The link below points to a 4.3 MB ZIP file, which contains the full source code as well as a precompiled demo of my terrain engine.

Before you download:

[1] This source code is not free. Usually, I don't care about these things, but this source code is just too terrible to make it free source. You may read through it, and use the techniques to implement your own stuff, though. You may also use the source, if you just want to test a couple of things. Sorry, but I just want to make sure, that you don't clone any bugs into your projects.

[2]The LOD implementation is incomplete, and may cause cracks from time to time. It's also slow, because it's not optimized.

[3] I'm not responsible for any damages caused by the use of this demo and/or source

[4] If you are only interested in the demo, then you should only download it, if you have a GeForce accelerator (DirectX 7). It does run on my TNT-1, but textures look like crap (because of maximum texture size).

[5] If you are able to understand this horrible source code, then you are definitely a bright person

The URL is (4.3 MB): http://www.thecore.de/TheCore/Void.zip

Don't say I didn't warn ya...

IP:

Effin Goose
Member
posted May 02, 2000 03:17 AM            
Hey Klaus

Just thought I'd mention that when i opened your paper it said "Could not find Colour space 8 Cs8", and none of the pictures loaded. I have Acrobat Reader 3.0. Not sure what its about, do you?

Oh, and from what I've read of it the paper is really quite easy to understand and quite interesting.. good job..

Ryan

------------------
I dont like it, and Im sorry I ever had anything to do with it
- Schrodinger

IP:

Klaus Hartmann
Member
posted May 02, 2000 03:52 AM            
Effin Goose,

Normally I can configure the Acrobat Distiller to generate PDFs that are compatible with Adobe Acrobat Reader 3.0. However, if I create the PDF from within Word, then I don't have that option. So it's possible, that you need Adobe Acrobat Reader 4.0. That should work, because I didn't use any weird things, nor do I have any weird stuff installed on that machine.

Niki

IP:

Bryan T
Member
posted May 02, 2000 11:36 AM            
Klaus,

I recall the simulator being in the Graphics Links page (see below), but upon perusal I did not find it. Their algorithm just moved water/dirt/etc.. from the current point to one of the adjacent points on the grid (there was some discussion as to how to pick which point based on distance, and how much height difference there was). Then when enough simulation steps were run, they generated terrain and textures based on it.

Graphics Links: (Great Stuff) http://www.technomagi.com/links/graphics.html

Terrain Generation Survey: http://www.cg.tuwien.ac.at/studentwork/CESCG97/marak

Random Stuff: http://www.ridgenet.net/~jslayton/software.html

As for my own project, I now have it generating random fractal terrain on the fly, as well as 128x128 pixel textures which cover a particular quadtree. My question now is: why am I getting 1 FPS when I'm only sending 64 textures to the card?!? Anyone have suggestions for improving OpenGL performance here?

--Bryan

IP:

Revolver
Member
posted May 02, 2000 03:00 PM         
Hmm,

I created a 24bit bitmap with paint, sized at 128x128. It came out to be 64kb in size, so I'll work from that (even tho Windows bitmaps are not a very good image format).

code:

texture size: 64 (kb)
num textures: 64 (cnt) mul
============================
3072 (kb)
or 3.00 (mb)

Sending 3mb of textures per frame (even over the AGP port) is going to hurt, but I wouldn't have thought that bad... are you sure you aren't using the software implementation? =P

Then again, using a raw format would be somewhat less.

Are you sure it's the textures? Have you profiled and identified where most of the processing takes place in your app?

r.

IP:

Bryan T
Member
posted May 02, 2000 06:10 PM            
Revolver,

Oh, it's definitely the render function, and it's definitely the textures (runs 66 FPS with only one texture). You're right about size, I think it's about 4 Meg total (the textures are RGBA), but I have a 32 Meg card. Shouldn't be that tough on the card, look at Quake 3!

I'm very new to OpenGL, so it's probably my inefficient use of GL calls that is causing the problems (thank God we don't use inner-texturing loops anymore! ugh!). Since these textures are not changing every frame, shouldn't I be able to leave them on the card? How would I go about specifying a texture for a set of polys and next frame drawing those polys in their new position without re-sending the texture? I assume there is something in OpenGL that does this...

Thanks,
--Bryan

IP:

CheshireCat
Member
posted May 02, 2000 06:33 PM            
It sounds like you're not using OpenGL texture objects, which allow you send the texture image once, and associate it with a name, and then later simply specify the name (where the name is some number) to select that texture instead of resending the pixels.

If you call:
glBindTexture(GL_TEXTURE2D, (int)name);
glTexImage2D(blah blah);
glTexParamter(parameter info);
glTexParamter(parameter info);
glTexParamter(parameter info);
...

for each texture, using a different name for each texture, you can then just call glBindTexture with the texture name that you want, and it'll select the appropriate texture into the context. You can not call glBindTexture between glBegin and glEnd.

Also, instead of pulling texture names out of thin air, and relying on your own scheme to avoid collisions, you can ask OGL to provide you with unused texture names:

GLuint textureNames[numTextures];
glGenTextures(numTextures, textureNames);

will fill in textureNames with numTextures unused texture names.

I think that this is what you want, if not I appologize for blathering =]

Jason

IP:

Bryan T
Member
posted May 02, 2000 07:41 PM            
Aha!

That's exactly what I was looking for. Now why does my "Super" OpenGL book not even have an index listing for glBindTexture???

Back to the book store... Any good (ie: advanced) OpenGL books you recommend?

Looks like I should go dig through www.OpenGL.org before asking basic OpenGL questions... there were two answers to the same question in the Beginners section. Doh! For anyone new to OpenGL (like me) here's the link to the Beginner board:
http://www.opengl.org/discussion_boards/cgi_directory/forumdisplay.cgi?action=topics&forum=OpenGL+coding:+beginners&number=2&DaysPrune=20&LastLogin=

--Bryan

IP:

CheshireCat
Member
posted May 02, 2000 08:17 PM            
http://www.amazon.com/exec/obidos/ASIN/0201604582/o/qid=957312765 /sr=8-1/ref=aps_sr_b_1_1/104-7031083-7373205

and
http://www.amazon.com/exec/obidos/ASIN/0201657651/o/qid=957312765 /sr=8-3/ref=aps_sr_b_1_3/104-7031083-7373205

are my two favourites. The first one is a "learning" book, and the second one is a reference manual. They both come from the OpenGL people, and cover basically everything.

It's possible that the book you are using now was written before OpenGL 1.1 - texture objects did not exist in the original OGL spec.

Jason

[This message has been edited by CheshireCat (edited May 02, 2000).]

IP:

Revolver
Member
posted May 03, 2000 01:30 AM         
Heh, Klaus, your code isnt that bad -- if nothing else, it's pretty damn readable, so don't be hard on yourself!

Hmm, I have a proposal: A community project. Perhaps those in the forum could pool our collective knowledge and work on an engine together...setting up a sourceforge project would facilitate this quite well.

Thoughts?

IP:

Klaus Hartmann
Member
posted May 03, 2000 03:01 AM            
Revolver,

-- You call that readable? Well, parts of it are indeed sort of readable, but the most interesting pieces are not. You should see when I write readable code

-- As for the community project... Theoretically, that's a cool idea, but the problem is to satisfy everyone who wants to work on that project. This is especially difficult with a terrain engine. Consider the following questions:

[1] Do you need a terrain engine, that allows virtually infinite random terrains with infinite detail (i.e. elevations are computed on-the-fly), or do you need to be able design a terrain for a particular purpose? Personally, I want to be able to design them.

[2] LOD or no LOD? For LOD engines you'll usually need to precompute enourmous amounts of texture data, because you are unable to assign a particular texture to a particular face. Also, the texture-detail decreases with increasing slope. Without LOD, you have more control, but sacrifice some performance on most hardware (no LOD should be faster on GeForce). My terrain engine, for example, uses a LOD approach, because that's just a hobby of mine. But in a real game I would prefer an engine without LOD, because it offers control.

[3] Direct3D, OpenGL, Windows, Linux?

[4] Do we want a full terrain engine, or just the "core" of a terrain engine? Take Crystal Space, for example. Sure that's no terrain engine (it's a really great portal engine), but... Personally, I would never use it, because it does too much of the work that should be on my end. I need control, and I don't want an all-in-one solution. Ideally, I would be able to incorporate such a terrain engine in my own portal engine. (not that I have one, but it should be possible).

[5] I would gladly join such a project, if the resulting quality is at least as good as that of Drakan, or (even better) Ultima IX Ascension. Also, it has to be free for commercial purposes.

IP:

Revolver
Member
posted May 03, 2000 11:53 AM         
...but the problem is to satisfy everyone who wants to work on that
project.

Hrm. Agreed. Perhaps a "community engine" is a goal too abstract; making it fairly difficult for everyone to push in the same direction.

What about a "community game"? An RTS/TBS perhaps? As such we would have relatively clear requirements of the engine, helping us build toward our goal.

==

1) I too would love to design them. When it comes to games and other interactive media, it's great to be able to craft everything that the user sees as they maneuver about the world. As well, it allows you to be more free when it comes to creativity -- if a particular area of terrain needs to be shaped in special way to meed the needs of the level/mission/whatever, you can do it.

2) I would love to support LOD...but I suppose this requires some more in-depth thought before committing.

3) All of them. =) It's more than possible to setup abstract rendering and
system interfaces... but I think if we needed something specific Windows is
obviously the predominant platform; both OGL/DX are available in this
instance obviously, but I'm not too mindful of using one over the other.

4) In the case that we work towards a game (or engine for a game) rather than an general engine, I think we solve this.

5) Free -- but of course... LGPL?

IP:

Klaus Hartmann
Member
posted May 03, 2000 01:13 PM            
Revolver,

Ask yourself the following question: "What makes a good terrain engine so cool?". Is it the fact that you can see some simple mountains, or is it because you are able to sneak around in just every corner of the terrain (i.e. behind a bush, behind a waterfall, into a niche in the mountain, take a dive, watch that willow tree in the center of a swamp). This reduces to the question: "Do you need a good overview of the terrain, or do you want sight-seeing?".

In a good RTS you'll need the overview, which basically eliminates the possibility sight-seeing.

So, in my opinion, an RTS game is not right type of game for a cool terrain engine. Of course, that's because (for me) the sight-seeing is the really fascinitaing thing. In my opinion there are four types of games that allow extensive sight seeing:

[1] role-playing (Ultima VII - The Serpent Isle)
[2] action role-playing (Diablo)
[3] action role-playing adventure (Quest for Glory)
[4] dumb shooter

My ultimate goal would be [1], because you are free to use your creativity to the fullest extent. But then again, you need more than just a terrain engine for these types of games.

IP:

Revolver
Member
posted May 03, 2000 02:26 PM         
My mention of an RTS was inspired from playing a lot of Ground Control; I'm on the beta, and the game is amazingly fun -- It's also my favorite genre. Black and White for instance, is pretty detailed...there's a video where Molyneaux is looking at an worm, zooms out to show a barrel, zooms out to show a house, then a town, then a whole countryside (what's amazing is this happens without any noticeable FPS or continuity changes).

While doing a full-fledged RPG would be cool, I'm unsure if it's doable in any realistic timeframe (same goes for something of Black and White's caliber). Perhaps something quick and fun -- but still with an element of complexity, and beautiful to look at. Perhaps an action role-playing game, but with a few different twists?

But then timeframe might not really be relevant, then a full-fledged RPG would be way to go -- I've always loved the Final Fantasy series (especially 7 & 8), but have always wanted to do something like that in a RT3D environment, and with different viewpoints.

Argh, now the idea is becoming clouded with questions needing answere and forks in the path of development... Looks like much more deliberation is needed than I thought before we can get things rolling. Admittedly, I didn't have much in mind when I first suggested it -- the idea just popped in my head. =P

IP:

This topic is 2 pages long:   1  2