http://emptyset.endoftheinternet.org/~p ... bined.diff
http://emptyset.endoftheinternet.org/~p ... 080108.zip

Please apply this patch to your q3map2, and compile a map that with current q3map2 gets holes in the terrain. Also, try changing the misc_model spawnflags from 6 to 22. It looks like this patch actually fixes the big bug with models in maps, but I want it to be tested before I send it to the q3map2 guys.

The bug was that planes are snapped to axial planes when possible (otherwise, it creates too many planes) - however, the snap routine rotated the plane around the ORIGIN to change the normals. So the 0.25 degrees snap angle it allowed could become so much that it even destroyed brushes.

I modified the snapping routine so it ensures that a point of a triangle stays on the plane when it is rotated.

Seems to work fine for me.

Thanks alot. Great stuff.

I used Spawnflags 6 in Silvion, and so far I haven't seen any map holes. Would there be any advantage to using this new patch in the next build?

No, it would neither help nor hinder.

BTW, I could confirm that this patch fixes the hole on brokenworld. I'll make a version of brokenworld without the hole.

To check for holes:

r_showcollisionbrushes 0.6
r_showcollisionbrushes_polygonfactor -8

helps quite much.

Get a fixed version of brokenworld at: http://emptyset.endoftheinternet.org/~p ... 2-div0.pk3

Mended World?

What I wanted to say: Mappers, take this patch and build us some cool terrain maps

divVerent wrote:What I wanted to say: Mappers, take this patch and build us some cool terrain maps

Done, and working on another.

Rad Ished wrote:Mended World?

ahahah

I updated the patch a little. It now even closes the tiny grenade sized holes on testterrain that my patch did not get rid of before.

Div i use q3map2GUI on a mac is it possible to apply the patch to this?
I made a terrain map and yes it has holes.

Update: I put the patches I have together at http://emptyset.endoftheinternet.org/~p ... bined.diff

It now contains:
OBJ format support
Correct model normal display for scaled models in GtkRadiant (no huge "mikados")
Decompiler fix (handles texcoords now)
SnapPlane fix (what this thread is about)

Other mappers from other games have done terrain for quite a while - without holes, because those savvy enough to do terrain are also savvy enough to use tri-soups instead of models [Which don't block vis, cast shadows, etc.]

Can't imagine anyone making such a map in GtkRadiant. It drops down to less than 1fps with a 128x128 grid of brushes... and 128x128 is not even near enough.

TVR wrote:Other mappers from other games have done terrain for quite a while - without holes, because those savvy enough to do terrain are also savvy enough to use tri-soups instead of models [Which don't block vis, cast shadows, etc.]

I don't know why you feel the need to carry on this vendetta against modeled terrain. Like it or not, models are not only easier to accomplish, but they offer greater flexibility and much more detail and realism. If Nexuiz is going to move into the 21st century, it is imperative that mappers get comfortable with using modeled geometry. Thanks to Div, this is possible.

divVerent wrote:Update: I put the patches I have together at http://emptyset.endoftheinternet.org/~p ... bined.diff

It now contains:
OBJ format support
Correct model normal display for scaled models in GtkRadiant (no huge "mikados")
Decompiler fix (handles texcoords now)
SnapPlane fix (what this thread is about)

I still cant get this patch to work on my radiant 1.5 source tree.

TVR wrote:Other mappers from other games have done terrain for quite a while - without holes, because those savvy enough to do terrain are also savvy enough to use tri-soups instead of models [Which don't block vis, cast shadows, etc.]

Dont cast shadows? thats a plain lie. Have you ever tried to do a viscompile on a decently sized souped terrain map? it takes forever and produces crappy vis.

I like to make models because there are a lot of interesting manipulations that you make in Blender that you just cannot do in radiant. Although for ease of use i way prefer radiant. Also, can you not do your lighting in Blender and export it with the texture?
I made this map and it has a .ase in it that seems to be lit in radiant, am i missing something here?
http://www.mediafire.com/?2ymkojmzezn

divVerent wrote:Can't imagine anyone making such a map in GtkRadiant. It drops down to less than 1fps with a 128x128 grid of brushes... and 128x128 is not even near enough.

Grid decimation using GTKGensurf... increases in-game performance as well.

torus wrote:

TVR wrote:Other mappers from other games have done terrain for quite a while - without holes, because those savvy enough to do terrain are also savvy enough to use tri-soups instead of models [Which don't block vis, cast shadows, etc.]

I don't know why you feel the need to carry on this vendetta against modeled terrain. Like it or not, models are not only easier to accomplish, but they offer greater flexibility

and much more detail and realism. If Nexuiz is going to move into the 21st century, it is imperative that mappers get comfortable with using modeled geometry. Thanks to Div, this is possible.

Using Models is not necessarily the superior method for terrain, as Nexuiz intends to remain playable, brute force detail can cause plethora of relating problems.

For example, misc_models, an entity, is not split by the BSP, generates no Vis data, requires a key for light mapping and shadows... which are horribly ineffective without Vis data.

In a game, clever techniques are employed in order to incorporate detail on tri-soups while maintaining the ability to play the game [frame rate and map layout], details such as greater terrain resolution must be simulated using texture *maps and shading techniques, both of which garner a higher detail for performance ratio than sheerly using models.

Besides, Nexuiz is a game of Quake deathmatch, nice and simple; it comes with no surprise that the developers intend to keep it as so.

tZork wrote:

TVR wrote:Other mappers from other games have done terrain for quite a while - without holes, because those savvy enough to do terrain are also savvy enough to use tri-soups instead of models [Which don't block vis, cast shadows, etc.]

Dont cast shadows? thats a plain lie. Have you ever tried to do a viscompile on a decently sized souped terrain map? it takes forever and produces crappy vis.

I was thinking about Blasted Lands' Patch mesh terrain while typing, but that doesn't cause it to be completely false. Light mapping, and by extension, shadow casting, require an additional key; this is ineffective without Vis data.

GTKGensurf's auto-hinting and grid decimation are favourable tricks to reduce compilation time.

Rad Ished wrote:I like to make models because there are a lot of interesting manipulations that you make in Blender that you just cannot do in radiant. Although for ease of use i way prefer radiant. Also, can you not do your lighting in Blender and export it with the texture?
I made this map and it has a .ase in it that seems to be lit in radiant, am i missing something here?
http://www.mediafire.com/?2ymkojmzezn

If you were to export lighting as the effect on a texture, the result would be a full bright map where you cannot detect contrast, as q3map2 requires entity lights to create space light, the difference between an open area & a nearly pitch black cave is the space light.

On a final note, export models as maps for further editing, and terrain isn't an excuse for the lack of map flow.

How is light-mapping ineffective? The 2 maps I've seen so far (my own proof-of-concept Silvion, and Brokenworld) that use mesh terrain shadow splendidly, and the former compiled astonishingly quickly (took approx 30 minutes). The only problems I've encountered have been resolved as well: the "hole" problem, and normal display.

As for performance, that doesn't seem to be a problem either.

TVR wrote:

divVerent wrote:Can't imagine anyone making such a map in GtkRadiant. It drops down to less than 1fps with a 128x128 grid of brushes... and 128x128 is not even near enough.

Grid decimation using GTKGensurf... increases in-game performance as well.

MAYBE that helps, but where to get GTKGensurf? It is not included in GtkRadiant.

Using Models is not necessarily the superior method for terrain, as Nexuiz intends to remain playable, brute force detail can cause plethora of relating problems.

For example, misc_models, an entity, is not split by the BSP, generates no Vis data, requires a key for light mapping and shadows... which are horribly ineffective without Vis data.

Wrong. misc_model does not CAUSE splits (as it is treated as detail brushes), but it normally inserts into the existing BSP tree. q3map2 converts misc_model models into a triangle soup when compiling. You may be confusing misc_model with misc_models, a QC driven entity that nobody uses except for debugging purposes.

In a game, clever techniques are employed in order to incorporate detail on tri-soups while maintaining the ability to play the game [frame rate and map layout], details such as greater terrain resolution must be simulated using texture *maps and shading techniques, both of which garner a higher detail for performance ratio than sheerly using models.

You can use the very same shading technologies with models too (namely, phong shading is the way to go). However, q3map2 has a bug regarding "brush soup" terrain: even when q3map_nonplanar or -np 179 is used, it won't convert the terrain to a single surface, so there are still some visible seams in the terrain. When using models, YOU have full control over the normals, and thus can avoid that problem completely.

I was thinking about Blasted Lands' Patch mesh terrain while typing, but that doesn't cause it to be completely false. Light mapping, and by extension, shadow casting, require an additional key; this is ineffective without Vis data.

You are confusing things. The issue is that terrain is detail brushes, and thus doesn't take part in vis calculation. However, brush soup terrain would be the very same in this regard... otherwise q3map2 gives up fast with error messages about built-in memory usage limits.

GTKGensurf's auto-hinting and grid decimation are favourable tricks to reduce compilation time.

If only GTKGensurf would actually exist. It's part of the GtkRadiant source tree in a directory gtkgensurf/, but not included in the build - and when I manually add it, it misses a file qetypes.h. This thing is vaporware.

Also, grid decimation is probably something most modeling apps can do. Creating appropriate hint brushes isn't, so that would have to be done manually by the mapper when using models for terrain.

On a final note, export models as maps for further editing, and terrain isn't an excuse for the lack of map flow.

You make it sound like map exporting actually works. But when using Blender's map expoter, texcoords get lost (that is, texture alignment gets completely broken) and - as if this weren't already bad enough - texture gets changed to caulk. So it has to be retextured face by face... (ten years later...)

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

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

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.

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.

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

Sorry.

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.

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.

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

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.

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.