Patch for q3map2 that needs testing (TERRAIN BUG)

[Rad Ished]

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.

[divVerent]

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)

[TVR]

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.]

[divVerent]

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.

[torus]

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.

[tZork]

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.

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.

[Rad Ished]

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

[TVR]

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.

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.

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.

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.

[torus]

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.

[divVerent]

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...)