Quake3World

I recreated the arch as mentioned here and while it looks good from one side now, for some reason the patches don't line up on the other side of the arch, as can be seen in the screenshot below:

[lvlshot]http://dl.dropbox.com/u/18687963/map/shot0053.jpg[/lvlshot]

I marked the seams with red. When watching the arch from the opposite side, the patches line up perfectly. Anyone have any idea what's going wrong?

I'm really messing around now. Can't seem to get it right at all anymore.
I recreated the arch once more. I created a brush that's 88 units wide and 64 units high (on grid 8 that's 11x8). Then tell GtkRadiant (1.6.2) to turn it into a bevel. Then I tell it to thicken by 32 units (the "seams" checkbox is checked"). That leaves me with the odd "heartshaped" kind of arch:



I also tried creating the inner bevel, inverting the grid matrix and thickening it then. It leaves a slightly better shaped arch, although it's kind of pointy at the top:



worse though, it has the seams effect shown in the first post on both sides of the arch.

What am I doing wrong?

Arte those parts of arch made by whole >one< cylinder? Or is that half-arch formed by 4 patches?

4 patches. I create a bevel and then use the "thicken" option. Always done it that way. Is it a bad habit?

Eraser, the handling points in the editor are not the problem. LOD cracks are quite common in patchwork with concentric trim like yours.
You have a number of options.
The first (which has never worked for me) is to func_group all the patches, in theory (as I understand it) the same entire object is assigned the the same LOD. Like I said, for me this never worked.
The next two options are kind of the same. Compile the arch separately and convert it to an ase model. To do this you will need to set -patchmeta -sudivisions x (where x is the number of subdivision you require, for example 6), in order that the patchwork can be converted into an ase model.
The other solution is just compile with -patchmeta -subdivisions x (again I normally use 6 as I prefer rounded arches). This I believe converts all patches into brush work during compile, and will eliminate all LOD cracking issues. On a side note it also fixes sparklies for all those sloppy mappers that haven't bothered to pay due regard to t-junc errors.

Again, side note....thicken isn't an issue so long as you snap to grid and delete unwanted faces.

As dONKEY said.
Third possibility is to make cilinder, it can map only one twxture - but without any problems.

The thing is you'll have that problem when using 1.5.0 or anything based on it... yet another reason to use 1.4.0 instead of that. I'd also suggest doing things the good ol' manual way - automating things can cause problems imo.

[lvlshot]http://i744.photobucket.com/albums/xx87 ... age2-1.jpg[/lvlshot]

Make a bevel, clone it, press v and move vertex points as shown. Take note of the whole arrangement of the vertex points. In a normal archway (and most curve work) the tangents should be 90 degrees to one another, otherwise it'll be pointy (like yours) or caved in.

[lvlshot]http://i744.photobucket.com/albums/xx87 ... 6/arch.jpg[/lvlshot]

Here's the map file for that...
http://www.mediafire.com/?h61xfnsij9yoc2r

I'm using 1.6.2 which is based off of 1.4 right? Anyway, I'll try some of the things you guys suggested. Thanks.

Oh how did you get the texture?

Am pretty sure 1.5 does not cause this issue. It about patch subdivisions and LOD.
1.5 shows the tearing in the editor, where as 1.4 does not. To me that is an advantage, as you don't waste time compiling a group of patches that the editor did not show would exhibit LOD cracks.
100% -patchmeta and -subdivisions fix this.

Eraser wrote:Oh how did you get the texture?

Well, now you know why your computer gets slower and slower...

Eraser wrote:which is based off of 1.4 right?

1.5

Eraser wrote:I'm using 1.6.2 which is based off of 1.4 right? Anyway, I'll try some of the things you guys suggested. Thanks.

Oh how did you get the texture?

http://cgtextures.com/texview.php?id=18703

dONKEY wrote:Am pretty sure 1.5 does not cause this issue. It about patch subdivisions and LOD.
1.5 shows the tearing in the editor, where as 1.4 does not. To me that is an advantage, as you don't waste time compiling a group of patches that the editor did not show would exhibit LOD cracks.
100% -patchmeta and -subdivisions fix this.

Well for me it's always a case of 'what you see in the editor is what you get in the compile'. I never have a problem with the subdivisions messing things up and I don't use those switches you mentioned.

dONKEY wrote:This I believe converts all patches into brush work during compile, and will eliminate all LOD cracking issues. On a side note it also fixes sparklies for all those sloppy mappers that haven't bothered to pay due regard to t-junc errors.

No, it does not convert patches to brushes, it forces a static LoD value to the entire patch. Patches usually change subdivisions depending on distance from the player, patchmeta disables this and forces a fixed value. It is not a fix for t-junc errors though it may in certain situations help with hiding symptoms of t-juncs, but I certainly wouldn't rely on it as a fix for sloppy work.

themuffinman wrote:The thing is you'll have that problem when using 1.5.0 or anything based on it... yet another reason to use 1.4.0 instead of that.

Big misconception. What a patch looks like in the preview window of the editor (any version) and what occurs in-game are entirely different stories. Whether or not you have a seam in the editor, the control points saved in the map file are the same. Q3Map2 takes these control points and compiles them into the BSP. Quake3 reads these values from the BSP file and generates LoD values for the curves in-game. At no point is a seam in the editor indicative of whether or not there will be a seam in-game. 1.5's preview window is a little buggy with drawing patches, but whether or not the seams actually weld has nothing to do with the preview. Just like how a light entity may have those little light radii around them in the preview window is by no means an indicator of exactly how brightly it will illuminate the room.

I do agree with bending patches manually, it takes away some of the guesswork that the plugin might be doing. Or as dONKEY mentioned above, snap to grid. Eraser's control points are most definitely not on a grid point. Select all grid points, hit CTRL+G.


Also, GtkRadiant 1.6 is built off of the 1.4 branch. NetRadiant is based off of 1.5.

Heh, thanks for clarifying how -patchmeta actually works Obs I knew how to apply the fix but wasnt clear on the technical reason it worked.

Seems to me like -patchmeta is a potential performance killer? If it takes away all LOD functionality it'll have high triangle counts even when viewed from far away, right? Is there perhaps some entity key we can use to indicate we want a fixed LOD for a single patch instead of specifying it for the whole map?

Noruen wrote:As dONKEY said.
Third possibility is to make cilinder, it can map only one twxture - but without any problems.

I did this and got a good result out of it. Thanks

Solve problems-use a model!

I wonder if its a feature of Enemy-Territory, but there it works well, when the patches which do align - have the same amount of control points and are matched up perfectly.
http://wet.peyote.ch/netradiant/subidivisions

I think that just shows patchmesh LoD. You can scale values using a cvar, r_subdivisions. It's just how patchmeshes are supposed to work.

Well yes, but when you use multiple patchmeshes, they should not have _holes_ as shown in the first pic.

obsidian wrote:Big misconception. ...

It's just strange that I've had problems in that regard with 1.5 and not 1.4 in the past.

obsidian wrote:Also, GtkRadiant 1.6 is built off of the 1.4 branch. NetRadiant is based off of 1.5.

But then why does it look and behave more like 1.5?

way id do it, 4 simple patch meshes vertex edited. gives better lightmap on the edges.

themuffinman wrote:

obsidian wrote:Also, GtkRadiant 1.6 is built off of the 1.4 branch. NetRadiant is based off of 1.5.

But then why does it look and behave more like 1.5?

UI wise 1.6 is exactly like 1.4 and not like 1.5
I don't know how 1.5 "behaves" but I haven't really noticed any difference between 1.4 and 1.6 in regards of how it works or renders stuff.