qbism / q2tools-220 Goto Github PK

This is a legacy bug from the vanilla qrad3; SKY faces have early exits in a bunch of places. As a result, dface_t is left zero-initialized, leaving lightofs set to 0 and all styles set to 0. This causes all sky faces to just use whatever lightmap data happens to be at offset 0.

It seems like at some point post-release, id Software introduced this bug into their tools; most (if not all) vanilla maps (base1 as an example) have lightmap data for SKY. An easy example is base1, where the flyby ship that flies over sky receives proper lighting because it is always above a bright sky face.

Lighting base1.map from the tools in 4rad (or even qrad3) will cause all sky faces to use whatever lightmap happens to be at 0, causing a lot of flickering depending on the map.

Simple fix is to just allow sky to be lightmapped again. It doesn't need to be subdivided, because sky brushes are never in the surface cache in software mode afaik.

I loaded this solution with MSVC2019 Community with Windows 10 SDK. MSVC asked to convert the projects and I said sure thing.

4bsp/vis/rad seemed to compile with bunch of the following warnings:

warning C4244: '=': conversion from 'double' to 'vec_t', possible loss of data
warning C4244: '=': conversion from 'float' to 'int', possible loss of data
warning C4018: '<': signed/unsigned mismatch
warning C4244: 'return': conversion from '__int64' to 'int', possible loss of data

and stuff like that.

4data failed to compile:

q2tools-220-04-25-21\common\l3dslib.c(68): error C4700: uninitialized local variable 'ptri' used

Texture rotation stored in UVaxis is ignored when applying origfix.

In editor:

Ingame:

The map:
orig_bug.zip

Noticed during vis. Will try increasing stack in cmake config.

Bigmaps with large bounds leak in current release. Need to study commits to find what broke it.

This is a bit of a difficult issue to explain, but the short story is that the calculation that handles texture coordinates in vanilla Quake 2 and qbsp3 relied on x87 floating point calculation, which uses 80-bit precision intermediate values. Tools and engines compiled with SSE (either x86 or x64), however, will only use 32 or 64-bit floating point values, resulting in a mismatch for what the engines compiled with x87 instructions expect. The line in question is this one - https://github.com/qbism/q2tools-220/blob/master/4rad/lightmap.c#L135 (and the same line below it for QBSP) - creating a version of DotProduct that does the calculation via long double casts should be enough to fix it; it will then agree with vanilla engines on the surface extents.

I'm also working with engines to fix the disagreement as well. The same fix was applied across the board in the Q1 community for the bug in question, so I'm hoping we can match up with them. You can see a much more detailed description of the problem here: skullernet/q2pro#261 (comment)

This relates to this issue #13

Basically I build Debug build and it was still ignoring .wals flags. My tools are on D: drive, buried deep in subfolders. Then I copied .exe files into baseq2/ which is on F: folder, not too deep into subfolders. Compiling map worked wonderfully.

Then I decided to rebuild Release build. Copies and overwrote Debug .exe files in baseq2/ folder. The map compiled with all surface/content flags ignored again. So I went back and copied over Debug .exe files that previously worked just fine and .... now they compiled map ignoring all surface/content flags.

What's going on here ?! :/

Skewed faces either broken or not support currently it seems

images and example map attached

q2test.zip
.

So I saw that Heretic 2 .m8 texture support was tentatively added and decided to test it out on the latest release. It compiles a BSP successfully, but it does not seem to be able to find/read the game's textures. In my Heretic 2 installation, the textures are both inside the game's pak file and unpacked into the folder base\textures (with appropriate subfolders). Trenchbroom reads them fine. My command line options (using Trenchbroom's compiling utitilty) are as follows:
C:\Quake\heretic!compilers\q2tool.exe
-bsp -basedir "C:/Quake/heretic/base" -gamedir "C:/Quake/heretic" -h2tex -leaktest -threads 4 ${MAP_BASE_NAME}

The basedir is the game's data folder, and the gamedir is the location of the game's .exe as the readme specifies. However, it prints a message like "WARNING: couldn't locate texture general/trigger" for every texture used in the map. This seems to be the correct way to specify gamedir/basedir based on the documentation, but please let me know if it's not.

sorry for this but there doesnt seem to be any tools out there on the internet to convert quake bsp maps to source bsp maps (valve's source) and a tool like this could be extremely useful for many valve developers, thank you.

I am messing with a project converting Quake 1 maps to Quake 2 maps and then rebuilding them for Q2RTX. Everything is ok with vanilla Quake 1 maps and also community maps that use BSP29 (vanilla) format.

However, most of the modern maps like the ones from Arcane Dimensions use BSP2 format, which has greatly expanded limits of BSP29. Conversion into Quake 2 is impossible, even after jumping through many hoops, because 4bsp, for example, can't handle more brushes, more entities, larger areas, etc. :(

One particular case:

Is there any way you could expand the limits for Q2 BSP in these tools ? Maybe have like a cmd line arg "-eBSP" (e for expanded) that would compile Q2BSP that is on par with BSP2 ?

Thanks

My PC has been vis'ing AD's Tears of False God (QBSP + Valve220) since probably 10 am. So it's been roughly 10 hrs of just vis'ing. And it's still vis'ing:

Is it possible that you could add same kind of multithreading to 4vis as in 4bsp ?

Since Q2RTX doesn't use lightmaps, currently it's not possible to have smoothed (phong) shading in Q2 maps.

Could you please add such functionality, if possible, to 4bsp? It would need to generate and store vertex normals somewhere (in the vertex lump?) in .bsp file.

Q2RTX dev will add support for that, if he has something to work with. Thanks!

Change formula to allow oversaturation.

When compiling with the latest release (09-01-21), 4bsp generates errors that it cannot find any of the textures if they are in a custom/non quake 2 folder path, such as textures/decals/. It works fine if they are in textures/e1u1 e1u2 etc. The map still compiles and textures load in the map, but animated textures do not work, it just stays on the first texture of the animation (or whichever one you put on). Simply changing back to a previous release compiler "fixes" the issue.

I usually run hlrad_x64.exe with "-smooth 200" on GoldSrc maps (using VHLT).
I'm asking this because even if I use "-smooth" on Kingpin, faces doesn't get smoothed at all (with the same values). Basically, "-smooth 0" or "-smooth 200" makes no difference; every rounded brush is not smoothed.
"-bounce" doesn't seem to affect the lighting either.

I'm using J.A.C.K. with these compiling options on "$light_exe":

-extra -smooth 200 -bounce 30 "$bspdir/$file"

Do I have to setup J.A.C.K. in a different way maybe? I'm currently using the Quake 2 profile for Kingpin and I've edited "VDKGameCfg.ini" to make the Q2 configuration read TGA files.

Any help is appreciated.

In a map with numareaportals = 0, it is being read as 7012672 from a bsp produced with the Windows q2pro build. The bsp output from the Linux build is correctly read as 0. This was observed in Q2PRO when the bsp would not open with a "BSP_LoadAreas: bad areaportals" error.

As far as I can tell, Heretic II animated textures (.m8 format) do not work with this compiler. I compiled the same map with stock compilers and qtools-220 and they were only animated in the former. The game's CD comes with a toolkit (also found here) with the source code of Raven's qbsp3, which should be helpful in understanding how they implemented it.

TryLoadFileFromPak fails for me because on my machine size of pakheader_t and pakentry_t structs is wrong due to long being 8 byte long instead of 4 (ref), which causes wrong data being read and malloc failing because of that. Changing long to uint32_t in these structs fixes the issue.

Hey @qbism,

We've chatted before on the InsideQC forum. I maintain Quake2 and Quetoo support for GtkRadiant. Currently, Quake2 map compilation is provided by Quetoo's tool, quemap. However, Quetoo's BSP format is changing, and it's becoming painful to maintain both Quetoo and Quake2 support in a single code base.

Your tools appear to be well maintained, and from what I gather, they are the de facto Quake2 tools for Trenchbroom. I was wondering if you would be open to bundling these tools with GtkRadiant, or maybe pointing GtkRadiant users to these tools via GtkRadiant's documentation. I could work with you to either merge these sources into the GtkRadiant repository to provide the tools directly, or I can help with continuous integration and hosting of binaries. I have a build environment that would probably make Linux and MinGW-w64 builds of this project straightforward.

I'd also like to work with you to share fixes and improvements between these tools and quemap, but I don't mean to get ahead of myself :)

So, I was using latest pre-built release binaries for Windows, 64bit and everything worked fine. I needed to expand limits (the one that can be expanded) and so I downloaded source code with .zip file, tweaked values, re-compiled using MSVC 2019 x64 release build.

Now all content/surface values from .wal files are ignored. Sky is drawn like regular solid brush, all clip brushes are visible, etc.

Why is this happening ?

The binaries for the 16 Feb 2023 release were removed from the releases page, and the release was renamed and marked as a "pre-release". Is there a particular reason for this? I downloaded it while it was still available, but someone else pointed out the change on Discord.

Hello!
Nice work for your 220 q2tools!
I'm a mapper here!
4rad seems to manage sunlight. I tried to use the old arghrad setting for this, but it dosent seems to work. Is there a documentation somewhere?
Ty

transfer_t uses uint16_t for patch index, but patch limit was increased for qbsp. this could overflow for large qbsp maps.

With all the improvements that were added to these tools (and Q2RTX engine fork) we finally have first run of AD Sepulcher:

https://www.youtube.com/watch?v=uQ53oRGxJJ4

As you can see, the brushes with vines texture don't really look proper because in Q2 (from what I understand) brushes with mist content are always double sided.

Would it be possible to add a contents (or surface?) flag, so that when 4bsp compiler finds mist content with such additional flag, it will make such brush face to be single-sided (or whole brush rather).

Thanks

I'm trying to build on Manjaro Linux KDE 64bit as I have successfully in the past. Recent code errors out when it comes to compiling 4rad:

/usr/bin/ld: release/lightmap.o:(.bss+0x2b50040): multiple definition of `dlightdata_ptr'; release/4rad.o:(.bss+0x1580420): first defined here
/usr/bin/ld: release/lightmap.o:(.bss+0x2350040): multiple definition of `dlightdata_raw'; release/4rad.o:(.bss+0xd80420): first defined here
/usr/bin/ld: release/lightmap.o:(.bss+0x2b50048): multiple definition of `refine_setting'; release/4rad.o:(.bss+0x1580428): first defined here
/usr/bin/ld: release/lightmap.o:(.bss+0x2b5004c): multiple definition of `refine_amt'; release/4rad.o:(.bss+0x158042c): first defined here
/usr/bin/ld: release/lightmap.o:(.bss+0x2b50060): multiple definition of `texture_sizes'; release/4rad.o:(.bss+0x1580440): first defined here
/usr/bin/ld: release/lightmap.o:(.bss+0x2b70060): multiple definition of `texture_data'; release/4rad.o:(.bss+0x15a0440): first defined here
/usr/bin/ld: release/patches.o:(.bss+0x850040): multiple definition of `texture_data'; release/4rad.o:(.bss+0x15a0440): first defined here
/usr/bin/ld: release/patches.o:(.bss+0x830040): multiple definition of `texture_sizes'; release/4rad.o:(.bss+0x1580440): first defined here
/usr/bin/ld: release/patches.o:(.bss+0x30020): multiple definition of `dlightdata_raw'; release/4rad.o:(.bss+0xd80420): first defined here
/usr/bin/ld: release/patches.o:(.bss+0x830020): multiple definition of `dlightdata_ptr'; release/4rad.o:(.bss+0x1580420): first defined here
/usr/bin/ld: release/patches.o:(.bss+0x830028): multiple definition of `refine_setting'; release/4rad.o:(.bss+0x1580428): first defined here
/usr/bin/ld: release/patches.o:(.bss+0x83002c): multiple definition of `refine_amt'; release/4rad.o:(.bss+0x158042c): first defined here
/usr/bin/ld: release/trace.o:(.bss+0x20): multiple definition of `dlightdata_raw'; release/4rad.o:(.bss+0xd80420): first defined here
/usr/bin/ld: release/trace.o:(.bss+0x800020): multiple definition of `dlightdata_ptr'; release/4rad.o:(.bss+0x1580420): first defined here
/usr/bin/ld: release/trace.o:(.bss+0x800028): multiple definition of `refine_setting'; release/4rad.o:(.bss+0x1580428): first defined here
/usr/bin/ld: release/trace.o:(.bss+0x80002c): multiple definition of `refine_amt'; release/4rad.o:(.bss+0x158042c): first defined here
/usr/bin/ld: release/trace.o:(.bss+0x800040): multiple definition of `texture_sizes'; release/4rad.o:(.bss+0x1580440): first defined here
/usr/bin/ld: release/trace.o:(.bss+0x820040): multiple definition of `texture_data'; release/4rad.o:(.bss+0x15a0440): first defined here
collect2: error: ld returned 1 exit status
make: *** [Makefile:210: release/4rad] Error 1

Because the triangles count is very heavy with liquid.
Thank you

Likely argument list is not incremented (i++). Checking it out.

From #42; reformatted as issue:

Issue

The new Quake II remaster (henceforth Q2EX) supports an additional surface flag (bit 25, 0x02000000) for binary transparency, as seen in Q2Pro and KMQuake2. Like SURF_TRANS33 and SURF_TRANS66, this flag needs to be used in conjunction with CONTENTS_TRANSLUCENT in order to actually allow the contained brush to be seen through.

Solution

Q2Tools-220 currently automatically flags brushes with faces containing Trans33 and Trans66 as translucent, and this function could be extended to do the same for alphatest. I have drafted an example (#42) of what might need to be done. I don't really do much programming, so I don't completely understand everything involved, which is why this is currently labeled as incomplete and a draft. For example, there are some mentions of the translucency flags in src/patches.c that I have no clue what they do. I hope though, that as a draft, it explains well enough what should be necessary to accomplish what I am suggesting be added.

Additional questions

Originally posted by @qbism in #42 (comment):

1. Do any existing .map files compatible with q2pro support this? What compile tools for Q2EX exist?
2. Does rad need changes? For example, when transparency mask is enabled (SURF_TRANS33 + SURF_TRANS66) rad basically passes half the light through.
3. What do these maps look like in non-supporting engines?

Could this solution be adapted to 4rad?
commit: ericwa/ericw-tools@2d15d20
Currently 4rad uses delayed fall-off from emitting surfaces. Possible add or replace if improvement.

I've encountered disappearing triangles bug with recent versions of the compiler.
After bisecting, the offending commit seems to be b23900e.

Before that commit everything is good:

On this commit (and on the current version) the result looks like this:

Here's how it looks in the editor (TrenchBroom):

A sample map for reproduction:

// Game: Quake 2
// Format: Quake2
// entity 0
{
"classname" "worldspawn"
"_tb_textures" "textures/e1u1;textures/testing"
// brush 0
{
( -512 -64 -16 ) ( -512 -63 -16 ) ( -512 -64 -15 ) e1u1/florr2_8 0 0 0 1 1
( -64 -512 -16 ) ( -64 -512 -15 ) ( -63 -512 -16 ) e1u1/florr2_8 0 0 0 1 1
( -64 -64 -16 ) ( -63 -64 -16 ) ( -64 -63 -16 ) e1u1/florr2_8 0 0 0 1 1
( 64 64 16 ) ( 64 65 16 ) ( 65 64 16 ) e1u1/florr2_8 0 0 0 1 1
( 64 512 16 ) ( 65 512 16 ) ( 64 512 17 ) e1u1/florr2_8 0 0 0 1 1
( 512 64 16 ) ( 512 64 17 ) ( 512 65 16 ) e1u1/florr2_8 0 0 0 1 1
}
// brush 1
{
( -209 133 96 ) ( -209 101 96 ) ( -209 101 16 ) e1u1/florr1_2 0 0 0 -1 1
( -189 81 96 ) ( -177 69 62 ) ( -177 69 16 ) e1u1/florr1_2 0 0 179.99998 -1 -1
( -193 149 16 ) ( -193 149 96 ) ( -209 133 96 ) e1u1/florr1_2 0 0 180 -1 -1
( -177 69 62 ) ( -145 69 50 ) ( -145 69 16 ) e1u1/florr1_2 0 0 180 -1 -1
( -145 69 16 ) ( -129 117 16 ) ( -145 133 16 ) e1u1/florr1_2 0 0 180 -1 -1
( -169 141 96 ) ( -151 87 96 ) ( -189 81 96 ) e1u1/florr1_2 0 0 -179.99998 -1 -1
( -189 81 96 ) ( -139 86 91 ) ( -177 69 62 ) e1u1/florr1_2 -3.0517578e-05 -7.6293945e-06 180 -1.0000001 -1.0000001
( -151 87 96 ) ( -139 86 91 ) ( -189 81 96 ) e1u1/florr1_2 0 0 180 -1 -1
( -177 69 62 ) ( -139 86 91 ) ( -145 69 50 ) e1u1/florr1_2 0 0 -180 -1 -1
( -145 133 16 ) ( -145 133 72 ) ( -169 141 96 ) e1u1/florr1_2 0 0 1.3660378e-05 -1 1
( -169 141 96 ) ( -145 133 72 ) ( -149 134 88 ) e1u1/florr1_2 -4.5776367e-05 -1.1444092e-05 1.0245286e-05 -0.99999976 1.0000002
( -169 141 96 ) ( -139 86 91 ) ( -151 87 96 ) e1u1/florr1_2 3.0517578e-05 -1.5258789e-05 -179.99998 -0.9999999 -1.0000001
( -149 134 88 ) ( -139 86 91 ) ( -169 141 96 ) e1u1/florr1_2 0 0 180 -1 -1
( -149 134 88 ) ( -136 96 88 ) ( -139 86 91 ) e1u1/florr1_2 4.5776367e-05 1.5258789e-05 180 -0.99999976 -0.9999999
( -129 117 16 ) ( -129 117 24 ) ( -145 133 72 ) e1u1/florr1_2 0 0 180 -1 -1
( -145 133 72 ) ( -136 96 88 ) ( -149 134 88 ) e1u1/florr1_2 0 0 180 -1 -1
( -145 133 72 ) ( -129 117 24 ) ( -136 96 88 ) e1u1/florr1_2 0 0 180 -1 -1
( -145 69 50 ) ( -139 86 91 ) ( -145 69 16 ) e1u1/florr1_2 0 0 180 -1 -1
( -139 86 91 ) ( -129 117 16 ) ( -145 69 16 ) e1u1/florr1_2 0 0 180 -1 -1
( -139 86 91 ) ( -129 117 24 ) ( -129 117 16 ) e1u1/florr1_2 0 0 180 -1 -1
( -136 96 88 ) ( -129 117 24 ) ( -139 86 91 ) e1u1/florr1_2 0 0 179.99998 -1 -1
}
// brush 2
{
( -200 152 16 ) ( -212 196 16 ) ( -212 196 130 ) e1u1/florr1_2 0 0 0 -1 1
( -196 224 16 ) ( -196 224 130 ) ( -212 196 130 ) e1u1/florr1_2 0 0 0 -1 1
( -200 152 130 ) ( -165 131 130 ) ( -200 152 16 ) e1u1/florr1_2 0 0 180 -1 -1
( -165 131 130 ) ( -144 119 16 ) ( -200 152 16 ) e1u1/florr1_2 0 0 180 -1 -1
( -165 131 130 ) ( -144 119 82 ) ( -144 119 16 ) e1u1/florr1_2 3.0517578e-05 0 -179.99998 -0.9999999 -1
( -100 131 16 ) ( -96 203 16 ) ( -124 219 16 ) e1u1/florr1_2 1.5258789e-05 0 180 -0.9999999 -1
( -160 222 130 ) ( -114 153 130 ) ( -165 131 130 ) e1u1/florr1_2 0 0 180 -1 -1
( -196 224 16 ) ( -160 222 130 ) ( -196 224 130 ) e1u1/florr1_2 0 0 0 -1 1
( -196 224 16 ) ( -130 220 119 ) ( -160 222 130 ) e1u1/florr1_2 0 1.9073486e-06 0 -1 1.0000001
( -196 224 16 ) ( -124 219 16 ) ( -130 220 119 ) e1u1/florr1_2 0 0 0 -1 1
( -124 219 16 ) ( -124 219 96 ) ( -130 220 119 ) e1u1/florr1_2 0 0 0 -1 1
( -144 119 82 ) ( -100 131 65 ) ( -100 131 16 ) e1u1/florr1_2 0 0 180 -1 -1
( -160 222 130 ) ( -98 157 123 ) ( -114 153 130 ) e1u1/florr1_2 0 0 -179.99998 -1 -1
( -130 220 119 ) ( -98 157 123 ) ( -160 222 130 ) e1u1/florr1_2 0 0 179.99998 -1 -1
( -165 131 130 ) ( -114 153 130 ) ( -144 119 82 ) e1u1/florr1_2 0 0 180 -1 -1
( -114 153 130 ) ( -98 157 123 ) ( -144 119 82 ) e1u1/florr1_2 0 0 180 -1 -1
( -144 119 82 ) ( -98 157 123 ) ( -100 131 65 ) e1u1/florr1_2 0 0 -180 -1 -1
( -130 220 119 ) ( -98 171 119 ) ( -98 157 123 ) e1u1/florr1_2 -4.5776367e-05 -6.1035156e-05 179.99998 -1.0000002 -1.0000002
( -96 203 16 ) ( -96 203 27 ) ( -124 219 96 ) e1u1/florr1_2 0 0 0 -1 1
( -124 219 96 ) ( -96 203 27 ) ( -130 220 119 ) e1u1/florr1_2 0 0 180 -1 -1
( -130 220 119 ) ( -96 203 27 ) ( -98 171 119 ) e1u1/florr1_2 0 0 180 -1 -1
( -100 131 65 ) ( -98 157 123 ) ( -100 131 16 ) e1u1/florr1_2 0 0 180 -1 -1
( -98 157 123 ) ( -96 203 16 ) ( -100 131 16 ) e1u1/florr1_2 0 0 180 -1 -1
( -98 157 123 ) ( -96 203 27 ) ( -96 203 16 ) e1u1/florr1_2 0 0 180 -1 -1
( -98 171 119 ) ( -96 203 27 ) ( -98 157 123 ) e1u1/florr1_2 0 -7.6293945e-06 -179.99998 -1 -1.0000001
}
// brush 3
{
( -64 -64 32 ) ( -64 64 16 ) ( -64 64 32 ) e1u1/florr1_2 0 0 0 1 1
( -32 -64 32 ) ( -64 -32 32 ) ( -64 -32 160 ) e1u1/florr1_2 0 0 0 1 1
( -64 32 32 ) ( -32 64 32 ) ( -32 64 160 ) e1u1/florr1_2 0 0 0 1 1
( 64 -64 32 ) ( -64 -64 16 ) ( -64 -64 32 ) e1u1/florr1_2 0 0 0 1 1
( 64 64 16 ) ( -64 -64 16 ) ( 64 -64 16 ) e1u1/florr1_2 0 0 0 1 1
( 64 64 32 ) ( -64 -64 32 ) ( -64 64 32 ) e1u1/florr1_2 0 0 0 1 1
( 64 64 32 ) ( -64 64 16 ) ( 64 64 16 ) e1u1/florr1_2 0 0 0 1 1
( 64 -32 32 ) ( 32 -64 32 ) ( 32 -64 160 ) e1u1/florr1_2 0 0 0 1 1
( 32 64 32 ) ( 64 32 32 ) ( 64 32 160 ) e1u1/florr1_2 0 0 0 1 1
( 64 64 32 ) ( 64 -64 16 ) ( 64 -64 32 ) e1u1/florr1_2 0 0 0 1 1
}
// brush 4
{
( -512 -64 368 ) ( -512 -63 368 ) ( -512 -64 369 ) e1u1/sky1 0 0 0 1 1 0 132 0
( -64 -512 368 ) ( -64 -512 369 ) ( -63 -512 368 ) e1u1/sky1 0 0 0 1 1 0 132 0
( -64 -64 368 ) ( -63 -64 368 ) ( -64 -63 368 ) e1u1/sky1 0 0 0 1 1 0 132 0
( 64 64 400 ) ( 64 65 400 ) ( 65 64 400 ) e1u1/sky1 0 0 0 1 1 0 132 0
( 64 512 400 ) ( 65 512 400 ) ( 64 512 401 ) e1u1/sky1 0 0 0 1 1 0 132 0
( 512 64 400 ) ( 512 64 401 ) ( 512 65 400 ) e1u1/sky1 0 0 0 1 1 0 132 0
}
// brush 5
{
( -512 -512 368 ) ( -512 512 16 ) ( -512 512 368 ) e1u1/florr2_8 0 0 0 1 1
( -480 -512 368 ) ( -512 -512 16 ) ( -512 -512 368 ) e1u1/florr2_8 0 0 0 1 1
( -480 512 16 ) ( -512 -512 16 ) ( -480 -512 16 ) e1u1/florr2_8 0 0 0 1 1
( -480 512 368 ) ( -512 -512 368 ) ( -512 512 368 ) e1u1/florr2_8 0 0 0 1 1
( -480 512 368 ) ( -512 512 16 ) ( -480 512 16 ) e1u1/florr2_8 0 0 0 1 1
( -480 512 368 ) ( -480 -512 16 ) ( -480 -512 368 ) e1u1/florr2_8 0 0 0 1 1
}
// brush 6
{
( -512 480 368 ) ( -512 512 16 ) ( -512 512 368 ) e1u1/florr2_8 0 0 0 1 1
( 512 480 368 ) ( -512 480 16 ) ( -512 480 368 ) e1u1/florr2_8 0 0 0 1 1
( 512 480 16 ) ( -512 512 16 ) ( -512 480 16 ) e1u1/florr2_8 0 0 0 1 1
( 512 480 368 ) ( -512 512 368 ) ( 512 512 368 ) e1u1/florr2_8 0 0 0 1 1
( -512 512 368 ) ( 512 512 16 ) ( 512 512 368 ) e1u1/florr2_8 0 0 0 1 1
( 512 480 368 ) ( 512 512 16 ) ( 512 480 16 ) e1u1/florr2_8 0 0 0 1 1
}
// brush 7
{
( -512 -480 368 ) ( -512 -512 16 ) ( -512 -480 16 ) e1u1/florr2_8 0 0 0 1 1
( 512 -512 368 ) ( -512 -512 16 ) ( -512 -512 368 ) e1u1/florr2_8 0 0 0 1 1
( -512 -480 16 ) ( 512 -512 16 ) ( 512 -480 16 ) e1u1/florr2_8 0 0 0 1 1
( -512 -480 368 ) ( 512 -512 368 ) ( -512 -512 368 ) e1u1/florr2_8 0 0 0 1 1
( -512 -480 368 ) ( 512 -480 16 ) ( 512 -480 368 ) e1u1/florr2_8 0 0 0 1 1
( 512 -480 368 ) ( 512 -512 16 ) ( 512 -512 368 ) e1u1/florr2_8 0 0 0 1 1
}
// brush 8
{
( 480 -512 368 ) ( 480 512 16 ) ( 480 512 368 ) e1u1/florr2_8 0 0 0 1 1
( 480 -512 368 ) ( 512 -512 16 ) ( 480 -512 16 ) e1u1/florr2_8 0 0 0 1 1
( 480 -512 16 ) ( 512 512 16 ) ( 480 512 16 ) e1u1/florr2_8 0 0 0 1 1
( 480 -512 368 ) ( 512 512 368 ) ( 512 -512 368 ) e1u1/florr2_8 0 0 0 1 1
( 480 512 368 ) ( 512 512 16 ) ( 512 512 368 ) e1u1/florr2_8 0 0 0 1 1
( 512 512 368 ) ( 512 -512 16 ) ( 512 -512 368 ) e1u1/florr2_8 0 0 0 1 1
}
}
// entity 1
{
"classname" "info_player_start"
"origin" "0 0 56"
"angle" "135"
}
// entity 2
{
"classname" "light"
"origin" "-24 72 120"
"target" ""
"targetname" ""
"light" "1000"
}

I'm aware that floating-point coordinates is a potential source for bugs and already tried snapping to both integer and grid, but nothing helps.

Sadly I'm also encountering these issues with way simpler and more 'regular' geometry than the one I'm showing here (without those long skinny triangles) like rotated arches.

I'll investigate further and report my findings, and hopefully a pull request to fix that.

Make qdir and gamedir able to be manually set with parameters -qdir and -gamedir respectively. Right now -basedir doesn't seem to do anything. Also could 4rad search for colormap.pcx from the directory 4rad is located in if it fails to find it in ${basedir}/pics/