NetRadiant = Radiant 1.5 with useful q3map2 patches...

[Odin]

Also, q3map2 -export has no gain. It is only there so you can edit the lightmaps, and import them later.

Real external lightmaps work completely differently (and also use different file names), and offer the advantage of having a different allowed size (while -export only exports internal lightmaps).

http://www.ioquake.org/forums/viewtopic.php?f=2&t=100

^ External lightmap patch. Loads external lightmaps exported with -export. They have to be moved to maps/mapname/lightmaps to work so it does not conflict with lightstyles. It works great, I've already tested it. The amount of detail from a lightmap at _lightmapscale 0.15, -samplesize 1 -filter -super -lightmapsize 2048, is incredible.
q3map2 should support an arbitrary export directory because nexuiz might look inside a different directory for external lightmaps. It also lets mod devs choose where external lightmaps should be stored. Basically, for inter-operability purposes. If -export weren't given an argument, then just make it maps/mapname by default(which is already the default).

[divVerent]

This has nothing to do with -export, but with external lightmap writing with -lightmapsize. Entirely different subject. The correct solution would then NOT changing how -export works, but adding a -lightmapdir option that specifies where the external lightmaps created using -lightmapsize are written to.

Also, why did the ioq3 guys make it like that? How does it interfere with lightstyles? Note that DP isn't the first engine to use maps/mapname. Why can't ioq3 follow the standard set by that other engine (wasn't it ETQW?)?

After having read the thread of the ioq3 guys, wouldn't it be the better solution to change q3map2 so lightstyles images get saved in a non-conflicting space, and keep the place for lightmaps as is? That way it wouldn't break compatibility to other engines.

One way to do this would be:

Add to q3map2.h:

#define EXTERNAL_LIGHTMAP_FOR_LIGHTSTYLE "style_%04d.tga"

and in lightmaps_ydnar.c, change:

/* generate stages for styled lightmaps */
...
sprintf( lightmapName, "maps/%s/" EXTERNAL_LIGHTMAP, mapName, olm->extLightmapNum );

to

sprintf( lightmapName, "maps/%s/" EXTERNAL_LIGHTMAP_FOR_LIGHTSTYLE, mapName, olm->extLightmapNum );

That should need no engine changes for lightstyle support, as the names of the lightstyle images come from the .shader file.

[divVerent]

Anyway, I added a -lightmapdir option, to be used together with -lightmapsize. Like this:

q3map2 foo.map -light ... -lightmapsize 1024 -lightmapdir foo/lightmaps

you may have to create the directory first, didn't test that.

Still, consider changing q3map2 and possibly ioq3 to NOT need this.

[Odin]

The patch was not written by an ioq3 dev. But rather ported from XreaL by a fan. I figured its use would take off pretty quickly if it worked flawlessly(which is seems to do). Anyway, you are right about lightstyles needing a different name.

The issue with lightstyles is that they would be written with the same names as regular exported lightmaps, so any map with them would cause the loader to load the lightstyle lightmaps as regular lightmaps and screw everything up.

[divVerent]

Actually, all this isn't a solution. Existing external lightmaps-supporting engines will for example misdetect existing maps with lightstyles as ones with external LMs.

Using a different path for lightstyles would solve the problem - but only in the future. Someone at id simply didn't think about this...

Does XreaL use the same path name convention (mapname/lightstyles/lm_0000.tga)? In that case, I could add the same support to DP.

[divVerent]

http://emptyset.endoftheinternet.org/~r ... nt-205.dmg

First NetRadiant build for OS X (sorry, PPC only for now, universal isn't possible with fink libraries). I got the model loading crash finally sorted out.

It is built on OS X 10.5, so it might not run on anything earlier.
The only dependency should be X11 (is on the OS X DVD).

Can anyone test it?

Intel version (not well tested yet):
http://www.icculus.org/netradiant/files ... xintel.zip

[airscout]

First NetRadiant build for OS X (sorry, PPC only for now, universal isn't possible with fink libraries). I got the model loading crash finally sorted out.

It is built on OS X 10.5, so it might not run on anything earlier.
The only dependency should be X11 (is on the OS X DVD).

Can anyone test it?

Fantastic. Successfully tried the binary and did a new compile against the MacPorts tools and libraries, not Fink. The build runs fine, but only if the executable is manually launched from the from the command line– I assume a path to something in the (nonexistent) SW folder is now hard coded? Not a big deal.

Unfortunately, having the MD3 model import working now has brought something else to light. At least for me, it turns out you can import MD3s and OBJs, but they are mostly invisible in Radiant. They compile properly into BSPs, show up in the entity list and can have adjustments made in the entities window, but they can't be seen, selected and thus moved or otherwise modified in the the 2D or 3D windows.

I apologize for not catching it earlier, since I gave up on models after the initial import crash issue became apparent. I just now went back and tried an older build and it's probably always been there, even with OBJs.

Regardless, great progress,
Andy

[Odin]

Actually, all this isn't a solution. Existing external lightmaps-supporting engines will for example misdetect existing maps with lightstyles as ones with external LMs.

Using a different path for lightstyles would solve the problem - but only in the future. Someone at id simply didn't think about this...

Does XreaL use the same path name convention (mapname/lightstyles/lm_0000.tga)? In that case, I could add the same support to DP.

Yes, it uses the same paths. However, lightstyles are "not supported" as they are simply obsolete in XreaL.

[divVerent]

So in XreaL, it is always mapname/lightmaps/lm_????.tga, and mapname is empty other than the lightmaps subdirectory?

[divVerent]

Successfully tried the binary and did a new compile against the MacPorts tools and libraries, not Fink. The build runs fine, but only if the executable is manually launched from the from the command line– I assume a path to something in the (nonexistent) SW folder is now hard coded? Not a big deal.

Yes. It is in the "install-dylibs.sh" script you'll have to change to use another source folder to get the libraries into the .app. What folder does MacPorts use? I might be able to support both in the same script.