Patch stiching...

Discussion for Level editing, modeling, programming, or any of the other technical aspects of Quake
Post Reply
User avatar
Eraser
Posts: 19174
Joined: Fri Dec 01, 2000 8:00 am

Patch stiching...

Post by Eraser »

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?
User avatar
Eraser
Posts: 19174
Joined: Fri Dec 01, 2000 8:00 am

Re: Patch stiching...

Post by Eraser »

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:

Image

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:

Image

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

What am I doing wrong?
Noruen
Posts: 308
Joined: Thu Jan 28, 2010 11:45 pm

Re: Patch stiching...

Post by Noruen »

Arte those parts of arch made by whole >one< cylinder? Or is that half-arch formed by 4 patches?
User avatar
Eraser
Posts: 19174
Joined: Fri Dec 01, 2000 8:00 am

Re: Patch stiching...

Post by Eraser »

4 patches. I create a bevel and then use the "thicken" option. Always done it that way. Is it a bad habit?
dONKEY
Posts: 566
Joined: Mon Oct 15, 2001 7:00 am

Re: Patch stiching...

Post by dONKEY »

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.
dONKEY
Posts: 566
Joined: Mon Oct 15, 2001 7:00 am

Re: Patch stiching...

Post by dONKEY »

Again, side note....thicken isn't an issue so long as you snap to grid and delete unwanted faces.
Noruen
Posts: 308
Joined: Thu Jan 28, 2010 11:45 pm

Re: Patch stiching...

Post by Noruen »

As dONKEY said.
Third possibility is to make cilinder, it can map only one twxture - but without any problems.
themuffinman
Posts: 384
Joined: Fri Mar 05, 2010 5:29 pm

Re: Patch stiching...

Post by themuffinman »

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
User avatar
Eraser
Posts: 19174
Joined: Fri Dec 01, 2000 8:00 am

Re: Patch stiching...

Post by Eraser »

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?
dONKEY
Posts: 566
Joined: Mon Oct 15, 2001 7:00 am

Re: Patch stiching...

Post by dONKEY »

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.
Bliccer
Posts: 341
Joined: Thu Nov 26, 2009 4:27 pm

Re: Patch stiching...

Post by Bliccer »

Eraser wrote:Oh how did you get the texture?
Well, now you know why your computer gets slower and slower...
themuffinman
Posts: 384
Joined: Fri Mar 05, 2010 5:29 pm

Re: Patch stiching...

Post by themuffinman »

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.
obsidian
Posts: 10970
Joined: Mon Feb 04, 2002 8:00 am

Re: Patch stiching...

Post by obsidian »

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.
[size=85][url=http://gtkradiant.com]GtkRadiant[/url] | [url=http://q3map2.robotrenegade.com]Q3Map2[/url] | [url=http://q3map2.robotrenegade.com/docs/shader_manual/]Shader Manual[/url][/size]
dONKEY
Posts: 566
Joined: Mon Oct 15, 2001 7:00 am

Re: Patch stiching...

Post by dONKEY »

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.
User avatar
Eraser
Posts: 19174
Joined: Fri Dec 01, 2000 8:00 am

Re: Patch stiching...

Post by Eraser »

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?
User avatar
Eraser
Posts: 19174
Joined: Fri Dec 01, 2000 8:00 am

Re: Patch stiching...

Post by Eraser »

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 :up:
User avatar
Theftbot
Posts: 483
Joined: Thu Oct 08, 2009 4:03 am

Re: Patch stiching...

Post by Theftbot »

Solve problems-use a model!
ailmanki
Posts: 30
Joined: Wed Jun 30, 2010 6:35 pm

Re: Patch stiching...

Post by ailmanki »

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
obsidian
Posts: 10970
Joined: Mon Feb 04, 2002 8:00 am

Re: Patch stiching...

Post by obsidian »

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.
[size=85][url=http://gtkradiant.com]GtkRadiant[/url] | [url=http://q3map2.robotrenegade.com]Q3Map2[/url] | [url=http://q3map2.robotrenegade.com/docs/shader_manual/]Shader Manual[/url][/size]
ailmanki
Posts: 30
Joined: Wed Jun 30, 2010 6:35 pm

Re: Patch stiching...

Post by ailmanki »

Well yes, but when you use multiple patchmeshes, they should not have _holes_ as shown in the first pic.
themuffinman
Posts: 384
Joined: Fri Mar 05, 2010 5:29 pm

Re: Patch stiching...

Post by themuffinman »

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?
fKd
Posts: 2478
Joined: Sat Jun 03, 2006 2:54 am
Location: Wellington
Contact:

Re: Patch stiching...

Post by fKd »

way id do it, 4 simple patch meshes vertex edited. gives better lightmap on the edges.
User avatar
Eraser
Posts: 19174
Joined: Fri Dec 01, 2000 8:00 am

Re: Patch stiching...

Post by Eraser »

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.
Post Reply