Yes, in this example I have only use 128 triangles. You can easily achieve the effects you mention by a) using two or more triangle sizes b) off-setting 'blocks' of terrain (I daren't mention s-u-b-t-r...) and c) not trying to build everything in one go.

Your response is exactly what is needed - HOW do I achieve such-and-such effect quicker, easier, more accurately etc.

In Fmb_sm40 you can see some different effects (and I am not promoting this map as a paragon of terrain mapping, it was done in quite a hurry and has a number of flaws) but nevertheless, it has walls, floors, islands and caverns. Oh yes, and an 'organic' blob on the wall of the GoldKey area, which I forgot to texture with a suitable bloody, moving texture. Ho hum.

Mountains, canyons, caves, overhangs, parapets, bridges; all possible with a good generator. And much quicker and just as accurate as doing it by hand. But as always, if it works for you... 

i'm just one of those people that will never be comfortable using something to generate terrain.
i just like making the terrain by hand. all my terrain has been hand made and will continue to be so. :P

also:
a) using two or more triangle sizes
what do you mean exactly? if you mean to make all the triangles smaller... yes, that's *a* solution, but that means some areas will get super hires that don't need it, not to mention wpolys will go crazy and axe (or possibly hammer?) murder you.
b) off-setting 'blocks' of terrain (I daren't mention s-u-b-t-r...)
i didn't really understand what you meant -- offset in what way? i'm guessing it has something to do with substraction, but i can't quite think of anything..?
and finally, c) not trying to build everything in one go.
you still end up having to align smaller triangles to larger triangles in the end, which is 'by hand' work, so brings me back to my original argument of doing it all by hand. 

I wrote a little program that converts entity definition files for Quake. Currently it only converts the good old .def files into .ent files to be used with GTKRadiant 1.5. Additional file formats (i.e. .fgd) and games might be added in the future.

You can download the program here:
http://www.gomjabbar.de/_mdb/apps/entcon.zip 

When using the generator, it requires a triangle size e.g. 128. If ALL the terrain in a map used this one size, you would begin to see uniformity. In my opinion, this is no more an issue than when mappers use same size corridors or wall heights. However, it would be easy to have (say) distant terrain on 128 or larger triangles, and middle distance on 64. This would break-up the visuals.

By off-setting, I mean that one block of terrain with 128 triangles could be placed on a different grid referrence to another block, again, to break up the visuals.

By not trying to build everything in one go, and the terrain generator makes it very easy for you to try to do so, the visuals will get broken-up naturally - bit of terrain, now some water, now some brick work, now some terrain etc.

Finally, seeing the restrictions in the other tools in use should not stop you trying to improve things generally. After all, nobody wants aguirRe or metslime (and others) to stop developing their tools, do we?

Moving forward is the only way. If we stand still, we go backwards.

We all still play Quake because certain mappers and certain tool suppliers are always moving forwards. Don't stop them... please. 

hm... first of all, i'd like to say this business of standing still == moving backwards is rhetorical nonsense.

this is not a matter of standing still.

http://www.planetquake.com/necros/temp/edges.jpg

this is a little bit of terrain i tossed together in about 30 minutes, so -- didn't take me long, but agreed -- it does take longer to do than in a terrain generator.

i've highlighted the relevant edges, green for the lower ridge, and orange for the upper one.

you can see how the triangles follow the curve of the rock lending a more natural edge. also, you can see what i was talking about with variable sized triangles. you can achieve a smooth transition from one bit to the next while still allowing plenty of detail.

the uniformity i was refering to is the way terrain generators make all the terrain tris in the same fashion -- all aligned onto a large grid and no room for little bits of character to make the rocks stand out.

also, note how i was slowly expanding the size of the tris as i got into the higher up parts of the rock. eventually, they would have grown to about 256x256 sized tris to make up the bulk of the far away rocks.
you can do this in terrain generators by making two seperate terrain bits and then butting them up against one another, but the transition will be noticeable unless you spend the time to make the pieces of the smaller terrain grow into the pieces of the larger one and in that case, you may as well make the terrain by hand since you'd be doing that anyway.

cheers, dude. :) 

I agree with both point of view... terrain generator are very "easy" to use, and save a lot of time. On the other hand, that's true as well that hand-made terrain are more "customizable".. and give the mapper muchmore possibilities... There is here a trade-off to find between speed and design...
In fact mapper's experience will choose between hand-made and generated terrain...
OK, I think I have all the huge line of this design methodologie.. Thanks for this very interesting discussion, and all the advices in there... 

Is it necessary to have installed Quake3 for GTKRadiant to work properly? I get an error �GtkGLExt-warning: cannot create GdkGLContext� when starting the program. In the new release of GTKRadiant you can also directly choose the configuration for Quake1 maps. 

probably u need to upgrade GTK

http://www.gimp.org/~tml/gimp/win32/

and no, you don't need to install q3 files 

Is this the half-crown argument or would you like the five shilling one :-)

Everything you highlight could be done in the generator. But that is not the real point: compare the original game of Quake that you bought in the store with the latest set of map releases played in the latest engines using the latest tools. People have moved it forward - same game but better.

Not rhetoric just fact: stand still to go backwards. Don't stop people trying to improve themselves. That's all.

JPL: nice bit of refereeing. 

forwards, not backwards, upwards, not forwards, and always twirling, twirling, twirling towards freedom! 

i'll be going backwards then. lates. ^_^ 

Necros expressing a contrary opinion is going to set the community back. He is just giving advice concerning what he feels is the best method for achieving decent looking terrain, and he is not trying to lead a counter-revolution to dismantle the last six years of Quake mapping history. That is the rhetorical component in the previous argument. 

If the terrain is done in half the time, but is twice as shit, who wins? 

Just to confirm, all of Marcher's terrain was build by hand (one of the reasons it took a while to make!). This was essential so that I could have complete control over the geometry, polycount, and to ensure that the terrain elements matched up vertex-for-vertex with the adjoining castle architecture.

Using an automatic terrain generator like gensurf would have made it a hideous compile nightmare, as the terrain would intersect with the castle brushwork. Also, I don't believe there is a satisfying way to make hollow terrain formations (like caves) with gensurf, so you might get problems there as well.

(PS: greetings from Minnesota :D) 

Like I said in #3181, regarding the previous posts, I now really think it's for the mapper just a trade off to find between speed and design, and clearly, it also depends on his experience..
Some prefer using generator, other prefer using hand-made terrain... Anyway, do we really care how the terrain was made if the map is good in the end ??
I have now a clear overview of the pros/cons about terrain generation/hand-made and now I just have to test the stuff, and see what will be the "good" method (in my opinion) when I will use generated terrain, or not, etc.. etc.....
Thanks again for this interesting discussion, and all the precious advices I can found here... 

...as it was ME that was disagreeing with the implication that terrain SHOULD be done by hand.

I am saying that it doesn't need to be. And the point about moving forward to avoid going backwards is supplemented by the fact that certain editors now provide 'displacement mapping' built-in. But hey, I'm not after an argument here. If you don't like my generated terrain, and if it spoilt your enjoyment of my maps, I am sorry.

(Spend an extra week building some terrain by hand or an extra week compiling - who's paying my wages anyway and where's my fishing rod?)

JPL: I also use Nem's Terrain Generator. It took me about 2 minutes to build the main cavern in Fmb_sm40 (behind the silver-key door) and import it into the map. And (wait for the screams) I used subtraction, although I don't use Quark.

I will surely be hung, drawn and quartered for this outrage. 

I will surely be hung, drawn and quartered for this outrage.

I'm sure nobody will blame you for a good map, in anyway the terrain has been generated, so don't worry ;) 

no problem, I've enjoyed your maps quite a bit over the years, Mike, and I thought the terrain in your Rogue-ish map was quite decent.

I just fealt some points could use a little clarifying to avoid things getting ugly, but, hey, if they did, it may be the first flame ever sustained around a Quake map making issue without delving into politics or ego. 

GTK 1.5 gives me this error:

.\plugin.cpp: 316
runtimeerror: Parse Primitive Quake: invalid primitive type

What is this, why did it just start happening (working on my Lost Chapters map) and how do I fix it? 

Have you recently installed a newer version of GTKRadiant? I've heard of something similar to this cropping up in newer builds, try the most recent build and see if SPOG has fixed it already. 

No sweat. 

I did download the latest version, I still have a problem. :( 

Argh! Textures are fine in Worldcraft 1.6, but when I compile with aguirre's utilities, some small textures are out-of place. (They are textures that have offset and scaling.)

Check shots from:
http://www.hut.fi/~tmaja/temp/

This must be a bug. And there must be way to correct it.

The map is Czg's terra6, I've modified it a bit. The original has the textures perfectly, but if I just open the given rmf or map in wc and save it again to map, it's fucked up when compiled. (Of course i can't compile the original .map because I don't know where Czg keeps his wads or their names, so I can't test if its Wc's or qbsp's fault.)

I've extracted the textures straight from the map using bsp2wad so that should not be a problem either, they should be identical.

All the material is here.
http://www.hut.fi/~tmaja/temp/ 

Seems compiling works allright with old id utils (and iklite)... (see _oldutils.png at the same address)

What's the best qbsp to use? Or should I have some wacky options in treeqbsp so it would work right? 

try -oldaxis? or -alternateaxis, or whatever the hell that option was renamed to