Patch Archway Gap


(chavo_one) #1

Some of my archways have been exhibiting strange behavior and I don’t know how to fix it. If you look at the screenshot, I’ve highlighted in green where the triangles don’t meet. There is a small gap that has formed.

I don’t quite understand it as everything is lined up in radiant. Has anyone seen this, and more importantly, does anyone know how to fix this?


(sock) #2

We had this problem with the barrel ceiling in the bank of goldrush. When you have 3 patches next to each other, like the front of an arch, the inside and the back of the arch you get LOD cracks. This is where the engine is trying to stitch the patches together and fails.

I’ve noticed this problem on complex patches where the control points are not at perfect right angles to each other. So on a 3x3 bevel/patch where one control point is at the base of the arch, one at the top, and one in the middle. If the middle point is moved closer to the center of the arch it starts to sub-divide the patch/bevel into more detail. Due to the way the engine calculates the mid points between control points, patches next to each other may not line up, so it cannot stitch them together.

One solution we found really useful was to convert the relevant patches to an ASE model. The ASE model will not LOD like normal patches but often this saving can more trouble than its worth.

Sock
:moo:


(chavo_one) #3

Thanks for the info sock! If I can get this error to disappear through ase models, then I’ll spend the time it takes. :slight_smile:

The new problem I’m seeing when using an ase model, is that it simplifies the curvature too much for my liking.

Is there anyway to tell q3map2 to not simplify the patches so much? These are the compile arguments I used to make the model.

-meta -v -patchmeta -mv 1024 -mi 6144

(ydnar) #4

Add -subdivisions 6 or so. The default is 8 (or 16, can’t remember offhand). Try progressively lower numbers until it gives you the result you want.

y


(ydnar) #5

Alternatively you could just compile your level with -patchmeta -subdivisions 7 and be done with it.

y


(chavo_one) #6

Beautiful!

Thanks ydnar! I decided to go with your first suggestion, and compile the ase with a small subdivision value (2). That way all of my other, more behaving patchwork wouldn’t be victimized by patchmeta.


(damocles) #7

chavo - that brick texture in the corridor there, is that an ET texture or a custom? I like the look of it…


(chavo_one) #8

It’s from the mapcenter mediterranean texture challenge. That texture set was my inspiration to do a venice map. :smiley:


(Blackadder_NZ) #9

Lookin good. :smiley:


(MuffinMan) #10

ya nice texture, should have a look at mapcenter again (though i don’t like the new design)!


(kat) #11

although you’ve fixed the problem I just wanted to add to what sock mentioned as I had this showing in a Wolf SP I’m doing… at the time the curves were ‘hand made’ in a similar way to what you did and no matter how many times i remade the curve the LODs still appeared until I tried to re- func_group them, as soon as I did that the problem dissappeared - presumably because the individual meshes are treated as a ‘single’ object?


(Matt) #12

Maybe I’m stupid and this is a completely different problem, but if you func_group those patches, instead of merging them, it may fix the problem?


(MuffinMan) #13

had this problem sometimes as well - not using end cap or bevel but using meshes and vertex editing worked for me


(sock) #14

This is very true as well, sometimes func_grouping patches/meshes together can also solve this problem. Certainly with a small amount of patches, like 3/4 grouped together. But when you get into 5+ patches lined up together they often don’t work. But you can do other solutions like the inside patch of the archways for the big doors into the tank bay in the map goldrush. Sometimes just having one patch slightly off from the other patches can control the LOD stitching problem.

Sock
:moo: