there's a bug in info_intermission description in the entities.def that goes with gtkrad 1.4.

here's the right part, replace it if you want less puzzlement with info_intermission:


/*QUAKED info_intermission (0 1 1) (-16 -16 -16) (16 16 16)
This is the camera point for the intermission.
Use mangle instead of angle, so you can set pitch or roll as well as yaw: 'pitch yaw roll'
If there is more than one info_intermission in the map, Quake will randomly pick one.
If no info_intermission entity is in the map, Quake uses the player start.
pitch -10 (look up10 degs) yaw 10 (look 10 deg left) roll 10 (tilt 10 degs right)

Keys:
"mangle"
set 'pitch yaw roll'
*/


gl 

Cool information you give here guy !!! Thanks as well for the related link...
BTW, I agree with necros when he says generated terrain can be perhaps too much uniform... but at least it's a good starting point, in order not to do the all work manually... 

Doing the work manually builds character. 

For a few unreleased Day of Defeat maps I worked on months and months ago I created all the terrian by hand. Using the popular triangle method you can have good looking terrain in no time by vertex maniping them. I tried using Gensurf but found it to over-complicate the process and wasn't worth the hassle. Just sit down, copy/paste a bunch of triangles, and goto work. It's simple, and quick once you get into it. 

Sorry, but I disagree with the suggestion that terrain should be built by hand: it just is not necessary.

No doubt people will pick holes but look at these screenshots - the terrain took less than 5 minutes to create, and I haven't even started to tidy it up yet (I'm not going to as I only did it for this post). It's hardly uniform.

http://img41.exs.cx/img41/2810/quake179fo.jpg
http://img41.exs.cx/img41/9215/quake184yv.jpg
http://img41.exs.cx/img41/7899/quake198zg.jpg
http://img41.exs.cx/img41/7433/quake203zc.jpg

All of the terrain used in Fmb_sm40 was generated and I bet nobody noticed... because that's the point, if it doesn't blend in to the map, it doesn't matter whether it was done by hand or not.

Sure, it is not perfect but if more people embraced it they would help improve what is, after all, just a tool to aid a task.

And yes, I am anti-Luddite. So, JPL go ahead and generate your terrain. 

well, to my eyes it is kind of uniform. it's good, but it's not something i'd do with my own map.

all the subdivisions are the same size, and the edges of the terrain start and end on those uniform subdivision sizes.

if there was a way to change the subdivs so that some areas got more attention than others and to promote more than just height maps with outcroppings, overhangs, etc... 

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?