Patch for q3map2 that needs testing (TERRAIN BUG)

[shaggy]

Div, I'll test the terrain patch out on my new map I'm working on. I hope to be of assistance.

[Rad Ished]

Shaggy i thought you said that your map wasn't using models?

[tZork]

Exelect mythbusting divVerent

Modeld terrain are alot easier to optimize then brush soups. The only real advantage of brushes, imo, are that modeld terrain tends to be a pita to integrate with brushwork (navigation is fubar with a humongus model in radiant). that and prehaps DotProduct2 textureblending, but thats possible to do with models (be it a bit messy at times) and dont work in Nexuiz anyways.

Now if your heart still craves brushes: Model your terra in whatever app you like, optimize & export it. then use this guide: http://en.wikibooks.org/wiki/Q3Map2#Cre ... _brushwork but replace

Code: Select all

"C:\path\to\q3map2.exe" -convert ase -game [game abbreviation] "C:\path\to\model.bsp"


with

Code: Select all

"C:\path\to\q3map2.exe" -convert map -game [game abbreviation] "C:\path\to\model.bsp"


And it should spit out a brushbased version of your model.

[divVerent]

Other problem with brush-based terrain: the maximum resolution q3map2 can take is 64x64 brushes (at 128x128, it already gives up when compiling). The result looks like this (ignores the broken texturing, it was a quick attempt at demonstrating it without aligning textures):



Lots of seams... as you know, the solution is phong shading. For brush based terrain, you do it by putting q3map_nonplanar in the shader, or -np 179 on the command line, and by adding -shade to the light stage flags.

Result:


Much better... but not good yet. You still see some (not many, admittedly) seams in the lightmaps... why are they there? Shouldn't q3map_nonplanar merge the whole terrain to a single surface, and make lighting seamless?

Nope. Lightmaps are limited in size, and thus q3map2 doesn't merge as much as it would have to. With r_showsurfaces, you see what happens:



It built a jigsaw out of the terrain... and where tiles meet, you still have the usual lighting seams.

How to fix this? Simple - use a model. Preferably, for vis reasons, build it out of multiple meshes so it doesn't need to be completely drawn all the time. In a modeling app, YOU have control over the normals, and can make the lighting work out fine and seamless... and STILL put multiple lightmaps on the model. In workflow, I'd recommend first making one big surface, and later using some clipping feature (I bet most modeling apps have such a thing) to cut it in smaller parts. A good modeling app will take care of the normals at the split points to match.

[shaggy]

Yes, it isn't a model. I now see I can't help.

Sorry.

[TVR]

Light mapping is ineffective because patch mesh requires the key -patchshadows or -patchmeta; Vis data will cull what is not seen, but as patches do not generate Vis, the multitude of faces simulating what appears to be curved in patch mesh must all be scanline rendered.
Say if the patch mesh were completely replaced with a rougher approximation in tri-soup, what possible impact would occur to the compile time?

DivVerent, you seem to be questioning the very existence of GTKGensurf, I will debunk you with THIS, or THIS.
Which solves the problem of using terrain for visibility, as suddenly, hint brushes, grid decimation and vis limitation allow greater freedom until fog-culling comes in 2.4.
FATE is also capable automatically generate a shader allowing for non-distorted [Different than DotProduct2, but has the ability to generate DotProduct2 shaders] texturing, if required.

Judging by the Shaggy's screen shot, the map exporter for Milkshape 3D has done it's job, and now Shaggy may continue with the exported terrain; as terrain is neat by itself, but is certainly much more so with the additional interiors where necessary

Would such contrivance align with the axial grid, tZork? Otherwise it appears to be the method to use a modelling tool for terrain.

[divVerent]

That's not GtkGensurf, but a plugin for OTHER map editors (QERadiant, Q3Radiant). My claim that GtkRadiant has no GtkGensurf still stands.

It looks like GtkGensurf is PLANNED to be added to GtkRadiant (as it is in the source tree), but not done yet (as it won't compile and source files are missing).

Light mapping is ineffective because patch mesh requires the key -patchshadows or -patchmeta;

Wrong for two reasons. 1. We are talking about a model, not about a patch. 2. Then why don't you just specify the keys?

Vis data will cull what is not seen, but as patches do not generate Vis, the multitude of faces simulating what appears to be curved in patch mesh must all be scanline rendered.

You again confuse patches with models. Models are actually saved as tri-soup in the BSP (and using my latest patch, they can also generate BSP splits if you specify "surfaceparm structural" in the shader, so you can create the required caulk brushes from your modeling app too and don't need GtkRadiant for that task). Only thing you have to do is split your model into multiple "groups" (like, a grid of 256x256 or 512x512 sized terrain squares), which shouldn't be a problem in a decent modeling app.

Say if the patch mesh were completely replaced with a rougher approximation in tri-soup, what possible impact would occur to the compile time?

Nobody WANTS a ROUGHER approximation. But again, we are talking about models, not patches.

[TVR]

Notice that I was referring to Torus; GTKGensurf, standalone executable.

[SavageX]

GTKGenSurf appears to be dead. That tool existed in old Radiant builds, it seems to be defective in current trunk.

As for runtime efficiency it makes no real difference whether terrain is modeled with brushes (and the shader for the terrain surfaces set appropriately) or embedded with model_misc. Both end up in the triangle soup and are subject to vis provided there are visblockers around (e.g. caulk in mountains and walls etc.).

Done right brush vs. model doesn't really matter and both have their ups and downs. Anyway, I'd advise against doing terrain with patches.

[divVerent]

Yes, but for another reason. With patches, you tend to get sharp edges all the time, and it's very hard to make two patches that smoothly meet each other. Patches only work for small stuff, like bridges, pillars, but certainly not for terrain - and you can't use multiple patches for one object as they tend to get subdivided differently which causes odd holes.