Terrain mapping.

[^Ghost]

how do u guys feel about using other programs like gensurf or easygen to create terrain?
Ive been messing with easygen earlier today, its quite easy to learn, but I was wondering on how you guys felt about it.

[Hipshot]

I prefer using a modeling application.
However, it could be hard to keep the terrain simple enough for bots.

[TTI]

This one was made with a modeling app. It's quite a bit more complicated than the EasyGen method, but it's also far more flexible, as it allows the terrain polygons to have any shape, size and form. You may notice from the screenshot that the arch is kind of blocky but that is easy to fix. It's just me being lazy. :P

[jal_]

I go for modelling application too, but it's slower to get an ingame result (if you want to make it show). Otherwise, easygen is a nice tool. I didn't try the other one, but I guess too. In general, if you want to make a map that is a terrain, easygen is probably better than modelling unless you plan to dedicate it a lot of time. If you just want to add a terrain into a room (big one, but room afterall) modelling is a better option.

EDIT: TTI, that road texture looks like TF2. Is it?

[TTI]

Heh.. Most definitely not.
Everything you see in the screenshot (aside from the truck's cab) is based either on pictures taken with my Canon EOS 40D, or on stuff found at CG Textures. Both cases require significant amount of time to be spent in Photoshop.

[dONKEY]

As an unashamed fan of Blender (as I don't have access to 3dsmax, I can' afford it and I don't agree with warez) I would have to say modeling terrain is great...but there are some limitations.
q3 can not 'cut up' a model as it does with brush work during vis compile. This means a large mesh will be rendered in its entirety. You can get around this by breaking up a terrain mesh into 'chunks'. This however leads to other issues. Remember the meshes point of origin is included as part of the mesh in terms of vis, in Blender at least this means moving each section into place prior to export, rather than leaving sections in situ. This also assumes you have built and cut up your mesh with vis in mind so that each section absolutely follows vis portal lines.
The other issue is terrain blending. Blending will not work across multiple meshes. I believe this was something Kat tried to get added to q3map2 by ydnar, but it was to the best of my knowledge never done. The other thing to be aware of is how to set up an exported ase model for multiple materials. This is possible and I have certainly achieved it, but it's one of those things that can be done far more quickly with good old fashioned brushwork.
So for small meshes and small areas of terrain, models are excellent...for large terrain areas I'm really not so sure.

[jal_]

Well, if you want radiant to split the terrain mesh all you have to do is using a different shader name for each triangle group. Even if they draw the same shader later. It also splits it by blocksize as long as you forcemeta it, anyway (but if you forcemeta it, you better force a ligthmapaxis, or it will show shadow breaks). Anyway, I agree with your conclusion. IMO, modelling huge terrains for q3map2 just takes too much work, specially if you want nice blending of multiple textures.

[^Ghost]

hmm i have 3ds max 2010, but im still learning how to use it, found some nice tuts on youtube. as for making terrain on it, is way beyond me at the moment.

[Hipshot]

As an unashamed fan of Blender (as I don't have access to 3dsmax, I can' afford it and I don't agree with warez) I would have to say modeling terrain is great...but there are some limitations.
q3 can not 'cut up' a model as it does with brush work during vis compile. This means a large mesh will be rendered in its entirety. You can get around this by breaking up a terrain mesh into 'chunks'. This however leads to other issues. Remember the meshes point of origin is included as part of the mesh in terms of vis, in Blender at least this means moving each section into place prior to export, rather than leaving sections in situ. This also assumes you have built and cut up your mesh with vis in mind so that each section absolutely follows vis portal lines.
The other issue is terrain blending. Blending will not work across multiple meshes. I believe this was something Kat tried to get added to q3map2 by ydnar, but it was to the best of my knowledge never done. The other thing to be aware of is how to set up an exported ase model for multiple materials. This is possible and I have certainly achieved it, but it's one of those things that can be done far more quickly with good old fashioned brushwork.
So for small meshes and small areas of terrain, models are excellent...for large terrain areas I'm really not so sure.

Meshes are split up, they are not, as in many other games, rendered as a whole, contrary to what you just said.

Blending two textures between two models should ofc not be a problem, it's like blending between two brushes.

Super simple to export the material(s) needed, you just input the shadername (as you would in a face on a brush), however, you might need to clear the "bmp" data from the material, else Q3map2 seems to confuse the real shader from the bitmap (sometimes, don't know the rule about this error).

[jal_]

Well, blending (we are talking about vertex blending here, right?) 2 materials is easy when using a model, but when you want 3 or more the thing requires planning, finding the ways to subdivide in different meshes, etc. The terrain generators handle that stuff for you pretty well.

[Kat]

Meshes are split up, they are not, as in many other games, rendered as a whole, contrary to what you just said.

Models are loaded based on their bounding box. Back-face and vis culling in relation to what's drawn onscreen are different issues. So no, models have never been (treated like brushwork and) cut up in the way you seem to be implying.

[Hipshot]

Meshes are split up, they are not, as in many other games, rendered as a whole, contrary to what you just said.

Models are loaded based on their bounding box. Back-face and vis culling in relation to what's drawn onscreen are different issues. So no, models have never been (treated like brushwork and) cut up in the way you seem to be implying.

I didn't imply that. I just said as an answer to Donk that they are split, by that I meant by the VIS in the game. When you move between PVS-zones, a single mesh will sometimes be split up and not fully rendered.
I never ever experienced in source that a large model will do this and those are rendered from the origin, not the bounding box, AFAIK.

[Kat]

Models are loaded based on their bounding box. Back-face and vis culling in relation to what's drawn onscreen are different issues. So no, models have never been (treated like brushwork and) cut up in the way you seem to be implying.

I didn't imply that. I just said as an answer to Donk that they are split, by that I meant by the VIS in the game. When you move between PVS-zones, a single mesh will sometimes be split up and not fully rendered.
I never ever experienced in source that a large model will do this and those are rendered from the origin, not the bounding box, AFAIK.

"source"? You mean HL Source? I'd be *very* surprised if that does things any different to what everyone else does in that what you're talking about something that relates directly to how triangles are drawn to screen rather than how models are generally processed and handled; which is what donkey was refering to - BSP, compilation etc, treats models as 'volumes' contained within a bounding box (within which the point of origin is contained), so an entire model is loaded in for use (if any part can be seen, it's loaded in) and then goes through the culling process to draw to screen only the triangles you can generally see, which is pretty much what you're describing.

[^Ghost]

well im looking for something that will be easier to do for eye-candy rather than gameplay.

[sock]

I have used gensurf to create terrain landscapes and then tweaked them in the editor afterwards. (This was before the fancy q3map2 dotproduct days) I even got one of the GTK programmers to add a feature to GTK 1.13 to allow triangle flipping with a single button, it was really easy to tweak stuff after that. I wrote several tutorials on some of the systems I used if you are interested and want to learn some new tricks. I would recommend you setup your gensurf grid first so that the frame rate can cope with all the triangles you are going to generate. A good starting point for large terrain sections is 192 and for small 128.

[^Ghost]

yeah ive tried blending maps with dotproduct2, but when i actually tested the maps they would never blend. i remember a friend telling me that i needed to upgrade my q3map2. i am currently using whatever came with version 1.4.

[AEon]

...q3map2. i am currently using whatever came with version 1.4.

That would be v2.5.11, it would probably be good to get v2.5.16 (see Hipshot's sig).

[^Ghost]

ok so i downloaded that, and copied all the files into my gtk folder but i get this error when i try to open it...
http://img99.imageshack.us/i/capturebw.jpg/

[jal_]

Models are loaded based on their bounding box. Back-face and vis culling in relation to what's drawn onscreen are different issues. So no, models have never been (treated like brushwork and) cut up in the way you seem to be implying.

I didn't imply that. I just said as an answer to Donk that they are split, by that I meant by the VIS in the game. When you move between PVS-zones, a single mesh will sometimes be split up and not fully rendered.
I never ever experienced in source that a large model will do this and those are rendered from the origin, not the bounding box, AFAIK.

They are split by blocksize. I has proof :P

These shots are taken with r_speeds 4 which draws only the tris of the mesh in the crosshair (i love it for optimizing). The terrain is a single mesh, single material. The map has assigned a big blocksize so it actually splits it in big blocks since that's more optimal for this case with nothing being ocluded.

[Hipshot]

I think kat talked about how it is loaded into the level, not how it is rendered in the scene when playing... (?)

Because it's pretty simple to show that they are split when rendered.

[jal_]

I don't know what do you mean by loaded into the level. Do you mean before compiling? Because the terrain is just part of the bsp tree after the bsp stage, as anything else.

There is a difference between forcemetaed and not forcemetaed, tho. I think Kat is refering to not-forcemetaed, in this case the trisoup may not be split. I'm not sure about that.

In case of forcemeta it splits by blocksize... in the simplest case. Because it will also split by shaders, and if hills are high enough, by lightmap axis. In normal cases it splits way too much, tbh.

[Kat]

I think kat talked about how it is loaded into the level, not how it is rendered in the scene when playing... (?)

Yes. Although like I mentioned above, I'm not specifically familiar with the way HL Source treats terrain entities, so based on what Valve did with it in HL2 they may have done some more interesting optimisations to a terrain mesh entity (tri souped brushwork) to get it to work over much larger areas. Just to clarify, I was referring to models used as terrain, rather than a terrain mesh made from brushwork, they're both generally treated in different ways when loaded into a game.

@Ghost: read the tutorials sock linked to (his tutes), they'll give you the best grounding in mucking about with brushwork and terrain.

[dONKEY]

...slightly off topic I love it when we wake the slumbering Kat

[obsidian]

Heehaw to that!

[Hipshot]

Yes. Although like I mentioned above, I'm not specifically familiar with the way HL Source treats terrain entities, so based on what Valve did with it in HL2 they may have done some more interesting optimisations to a terrain mesh entity (tri souped brushwork) to get it to work over much larger areas. Just to clarify, I was referring to models used as terrain, rather than a terrain mesh made from brushwork, they're both generally treated in different ways when loaded into a game.

I was talking about models in specific, not just as large terrain. In Source they use displacement maps for their terrain, not models. And I was only talking about the renderer not the compile.

But, how would you say a very huge terrain model would work in Q3? Cause I have an entire CTF level build with only a single mesh... I never saw this as a problem here really.