Thomas Debesse (8201f9b8) at 06 Apr 00:19

easy-builder: make it compatible with Ubuntu 18.04/CMake 3.10

Thomas Debesse (366e4cb1) at 05 Apr 03:59

readme: update

... and 7 more commits

Thomas Debesse (800aafc8) at 04 Apr 09:12

docs: set index.html to redirect

Thomas Debesse (932d21b4) at 04 Apr 08:59

contrib: update urls and names

... and 22 more commits

Thomas Debesse (7d2c6f1a) at 01 Apr 00:04

bundle: make daemonmap buildable and bundlable like other tools as ...

This is only made to make easy to build NetRadiant packages for Windows.

Windows library management has a design issue: instead of patching binaries with rpath to set an extra library directory to look for, we have to both patch binaries with assembly information using .rc files and distributes an .xml sidecar file that lists every library to look for in that library directory.

So, making a bundle from two repositories (i.e. merging two packages) requires to merge XML files.

So I had two alternatives:

1. write an helper to merge XML files
2. add a submodule and extend CMakeLists.txt

I obviously chosen the second option, I don't want to spend time writing software to workaround operating system design flaw. Workaround for operating-systems better live in toolchain.

Thomas Debesse (b8fc2520) at 31 Mar 23:39

easy-builder: make possible to check for more than one submodule

Thomas Debesse (36e32cba) at 31 Mar 16:50

easy-builder: strip release binaries, support older cmake

Thomas Debesse (350fed8a) at 31 Mar 00:45

readme: use cmake -S instead of undocumented -H

Thomas Debesse (00b3b32a) at 31 Mar 00:43

easy-builder: improvements

Also, this code is meant to be deleted one day: the long term goal is to build navigation meshes in game. Since I don't know when that would be done on game-side, I need an easy way to ship this tool on short term.

Note that this is completely optional at build time: if the submodule is not there, the tool is not built.

The repository is still entirely buildable without cloning any submodule (that just disables .crn file support (see !104 (merged)) and does not compile the daemonmap tool).

This is only made to make easy to build NetRadiant packages for Windows.

Windows library management has a design issue: instead of patching binaries with rpath to set an extra library directory to look for, we have to both patch binaries with assembly information using .rc files and distributes an .xml sidecar file that lists every library to look for in that library directory.

So, making a bundle from two repositories (i.e. merging two packages) requires to merge XML files.

So I had two alternatives:

1. write an helper to merge XML files
2. add a submodule and extend CMakeLists.txt

I obviously chosen the second option, I don't want to spend time writing software to workaround operating system design flaw. Workaround for operating-systems better live in toolchain.

Thomas Debesse (0bd48db4) at 29 Mar 21:27

bikeshedding: minor readme fix

Thomas Debesse (27e8ce20) at 29 Mar 18:58

q3map2/smokinguns: fix .tex writing, <3 @vloup

Thomas Debesse (dd26dc48) at 29 Mar 01:05

bikeshedding: reduce diff noise with Garux tree

Yes I'm running renderer2, I reproduce the bug with legacy renderer.

Thomas Debesse (5b33d0e7) at 29 Mar 00:30

q3map2: pad with zero, not with null pointers, ref #160

good catch. thx

Note that I then added a new commit (96a0d4ae) that replaces .[ExecutableType] by [ExecutableExt] before variable parsing. The later variable is using a per-OS define set in libs/globaldefs.h like other per-system defines. This makes variable parsing less hacky and less prone to errors.

Also the code previously used to set the ExecutableType is now deleted from Cmake and Makefile. If needed (I highly doubt about it), ExecutableType is still available as the executable extension minus the leading dot, if executable extension exists.

Using [ExecutableExt] in gamepacks is discouraged by the way, since it would make those gamepacks incompatible with other netradiant fork living out there, and with older builds.

I have tried tGridlightSun_net.bsp in xonotic, and it worked, as expected.
So lightgrid data is there, but not in form, understandable by some engines (vanilla q3, older ioq3, q3e github.com/ec-/Quake3e ).

Can you share the compiled map to check on my end? Screenshots look like renderer2, which may not or utilize lightgrid differently.

Note: I built map with both Linux and Windows build and get the same result as my previous screenshots whatever the OS.

I just noticed your example map, so I built it and I got this:

♦

♦

♦

♦

♦

I don't see anything wrong, but maybe I'm missing something?

The weapon may look brighter (especially on the penultimate, but that's also because the light is not behind me, that looks better when I go from brighter zone to dark zone), but at least there is a going brighter and brighter as I walk into the bright zone.

This is well seen there:

♦

♦

Do you have ways to reproduce this bug?

On my end I compiled q3dm17sample map with q3 build profile and got this (using q3map2 master from this repository), then I loaded the map in ioquake3:

♦

♦

♦

♦

♦

♦

♦

So, the lightgrid seems to work on my end.

Thomas Debesse (96a0d4ae) at 28 Mar 02:09

radiant/buildmenu: rename ".[ExecutableType]" as "[ExecutableExt]"

Solved in my netradiant-1.5.0-20200328git build

A million thanks, folks ;)

Thomas Debesse (ae00fba5) at 28 Mar 00:53

radiant/buildmenu: fixup, ref #138

For posterity, what was extra confusing is that the bug wasn't actually in q3map2, but in Radiant's code that launches q3map2.

So, well done, that fix!

HAHA. Nice bug.

I can confirm that f4c0af26 fixes the bug. The code introduced in 25379b2c had indeed a bug in Radiant's state machine that parses [Variables] in command line strings, in particular in the new code to strip .[ExecutableType] on non-Windows.

netradiant-1.5.0-20200327git:

♦

@julius__ current master may be fixed (I'm not able to reproduce anymore on my end).

Thomas Debesse (f4c0af26) at 27 Mar 17:05

radiant/buildmenu: better executable extension strip, ref #138

♦

My build of Netradiant is: netradiant-1.5.0-20200206git

Light stage parameters: -light -lightmapsize 1024 -lightmapsearchpower 4 -deluxe -patchshadows -samples 4 -randomsamples -fast -fastbounce -bounce 4 -bouncegrid -dirty -dirtdepth 128 -dirtscale 1.0 -fill

Netradiant's console output:

...

Dirtmapping enabled

Dirtmapping depth set to 128.0

Dirtmapping scale set to 10.0

...

Thomas Debesse (179a7525) at 27 Mar 15:46

bikeshedding: some touchup on library-bundler

Bug seen while investigating #138.

Before:

$ q3map2 -light
2.5.17n-git-f41ca5cd
threads: 8
Q3Map         - v1.0r (c) 1999 Id Software Inc.
Q3Map (ydnar) - v2.5.17n-git-f41ca5cd
NetRadiant    - v1.5.0 Jan 30 2020 20:27:00
Your map saw the pretty lights from q3map2's BFG
VFS Init: /home/illwieckz/.q3a/baseq3/
VFS Init: /home/illwieckz/dev/netradiant/install/baseq3/

--- Light ---
--- ProcessGameSpecific ---
 lightning model: quake3
 lightmap size: 128 x 128 pixels
 lightning gamma: 1.000000
 lightmap colorspace: linear
 texture colorspace: linear
 _color colorspace: linear
 lightning compensation: 1.000000
 lightning exposure: 0.000000
 lightgrid scale: 1.000000
 lightgrid ambient scale: 1.000000
 shader lightstyles hack: enabled
 patch shadows: disabled
 deluxemapping: disabled
--- ProcessCommandLine ---
Erreur de segmentation

After:

$ q3map2 -light
2.5.17n-git-d0ddc5a3
threads: 8
Q3Map         - v1.0r (c) 1999 Id Software Inc.
Q3Map (ydnar) - v2.5.17n-git-f41ca5cd
NetRadiant    - v1.5.0 Mar 27 2020 01:39:21
Your map saw the pretty lights from q3map2's BFG
VFS Init: /home/illwieckz/.q3a/baseq3/
VFS Init: /home/illwieckz/dev/netradiant/install/baseq3/

--- Light ---
--- ProcessGameSpecific ---
 lightning model: quake3
 lightmap size: 128 x 128 pixels
 lightning gamma: 1.000000
 lightmap colorspace: linear
 texture colorspace: linear
 _color colorspace: linear
 lightning compensation: 1.000000
 lightning exposure: 0.000000
 lightgrid scale: 1.000000
 lightgrid ambient scale: 1.000000
 shader lightstyles hack: enabled
 patch shadows: disabled
 deluxemapping: disabled
--- ProcessCommandLine ---
************ ERROR ************
usage: q3map -light [options] bspfile

Thomas Debesse (e88113e0) at 27 Mar 15:43

Merge branch 'missingarg' into 'master'

... and 1 more commit

Illwieckz:

[q3map2] -light -lightmapsize 1024 -lightmapsearchpower 4 -deluxe -patchshadows -samples 4 -randomsamples -fast -dirty -dirtscale 1.2345 -fill "[MapFile]"

Dirtmapping enabled

Dirtmapping scale set to 12345.0

[q3map2] -light -lightmapsize 1024 -lightmapsearchpower 4 -deluxe -patchshadows -samples 4 -randomsamples -fast -dirty -dirtscale 0.001 -fill "[MapFile]"

Dirtmapping enabled

Dirtmapping scale set to 1.0

It is not multiplying by 10 as I said before, it is simply interpreting the values as integers, as if there was no "."

Garux seems right.

Related to "gtkradiant-1.5.0-20200326git", it was only a mistake from my part when making the directory to clone into. I have cloned the TTimo repo.

But it seems, if I'm not wrong, that GtkRadiant requires Scons for Python2. It is a package for Python3 here in Slackware and I'm having errors when trying to compile.

Bug seen while investigating #138.

Before:

$ q3map2 -light
2.5.17n-git-f41ca5cd
threads: 8
Q3Map         - v1.0r (c) 1999 Id Software Inc.
Q3Map (ydnar) - v2.5.17n-git-f41ca5cd
NetRadiant    - v1.5.0 Jan 30 2020 20:27:00
Your map saw the pretty lights from q3map2's BFG
VFS Init: /home/illwieckz/.q3a/baseq3/
VFS Init: /home/illwieckz/dev/netradiant/install/baseq3/

--- Light ---
--- ProcessGameSpecific ---
 lightning model: quake3
 lightmap size: 128 x 128 pixels
 lightning gamma: 1.000000
 lightmap colorspace: linear
 texture colorspace: linear
 _color colorspace: linear
 lightning compensation: 1.000000
 lightning exposure: 0.000000
 lightgrid scale: 1.000000
 lightgrid ambient scale: 1.000000
 shader lightstyles hack: enabled
 patch shadows: disabled
 deluxemapping: disabled
--- ProcessCommandLine ---
Erreur de segmentation

After:

$ q3map2 -light
2.5.17n-git-d0ddc5a3
threads: 8
Q3Map         - v1.0r (c) 1999 Id Software Inc.
Q3Map (ydnar) - v2.5.17n-git-f41ca5cd
NetRadiant    - v1.5.0 Mar 27 2020 01:39:21
Your map saw the pretty lights from q3map2's BFG
VFS Init: /home/illwieckz/.q3a/baseq3/
VFS Init: /home/illwieckz/dev/netradiant/install/baseq3/

--- Light ---
--- ProcessGameSpecific ---
 lightning model: quake3
 lightmap size: 128 x 128 pixels
 lightning gamma: 1.000000
 lightmap colorspace: linear
 texture colorspace: linear
 _color colorspace: linear
 lightning compensation: 1.000000
 lightning exposure: 0.000000
 lightgrid scale: 1.000000
 lightgrid ambient scale: 1.000000
 shader lightstyles hack: enabled
 patch shadows: disabled
 deluxemapping: disabled
--- ProcessCommandLine ---
************ ERROR ************
usage: q3map -light [options] bspfile

On my end (Linux), they both seem to work as expected:

illwieckz:~/dev/netradiant/install $ unbuffer ./q3map2 -light -dirtscale 0.2 | egrep '^Dirtmapping scale'
Dirtmapping scale set to 0.2

illwieckz:~/dev/gtkradiant/install $ unbuffer ./q3map2 -light -dirtscale 0.2 | egrep '^Dirtmapping scale'
Dirtmapping scale set to 0.2

(unbuffer from expect package is only used to be sure everything is printed out even if something fails later, I'm experiencing a segfault on my end, but that's another issue to fix).

cd /opt/gtkradiant-1.5.0-20200326git

Where do you find that 1.5 GtkRadiant? GtkRadiant 1.5 is maybe dead since a decade or something like that. TTimo repository (github.com/TTimo/GtkRadiant) provides GtkRadiant 1.6 which is a fork of 1.4 (from before 1.5 came to life, ignoring 1.5 entirely). The only GtkRadiant 1.5 that is alive is… NetRadiant (and its childs).

My first feeling is that it may be an issue in argument parsing, I was going to ask you to try to pass -dirtscale 1.2345 and -dirtscale 0.001 to see how it behaves…

It looks like @Garux is thinking the same.