So could you make a package for other Mac users like clueless newbie?

Hello. I have been using netRadiant for a while now and love it, but today I ran into a problem which I think should have a walkaround or fix done for it.

A map I was building on suddenly started failing at one point during the BSP building. I found out that was because of a hard coded limit in q3map2 which limits the maximum number of brushes to 32768 (MAX_MAP_BRUSHES). I asked why it couldn't be bigger and was told it could crash or block the compiler on computers with lower resources if increased too much. I currently need to use a hacked q3map2 to keep building my map otherwise it won't work.

So my question is, could the limit for MAX_MAP_BRUSHES in the compiler be made a preference in the Preferences menu from netRadiant (if there is a way to get netRadiant to "talk" to q3map2.exe about such things). Or if not some q3map2.ini file for such settings or any other way just not a hard-coded number. That would be very useful for larger maps with many brushes or brush-based terrain so they can be built without a hacked compiler. Hope something can be done to fix this.

I looked at the code, and could make this specific limit dynamic (so it automatically expands while q3map2 runs).

q3map2 in NetRadiant now is able to compile RedStarRepublic.

I didnt really like the splash image so i did that in a couple of minutes =P
You are free to use this in any way you want =)
actual file is a .bmp, you can get it here:
http://kimi.kieru.net/433029

Great, can I have an editable source of this (xcf, psd, for example)?

xcf:
http://yuki.kieru.net/958069
=)

Committed, but not yet tested - thanks

hope the window size of the splash image will automatically adjust to the bmp.

Suggestion for q3map2: Allow -export to accept an argument, which would be a directory. There is a patch for ioquake3 to load external lightmaps, and it loads from maps/MAPNAME/lightmaps, rather than maps/MAPNAME(to prevent lightstyles from screwing up). Would be cool to have it like this:

Code: Select all

q3map2 -light -export <directory>

Where "directory" is the directory name inside of maps/MAPNAME.

I do not see whats to gain from this.. Nexuiz (at least the development version thats set to be released soon) can also use external lights maps: http://forums.alientrap.local/viewtopic.php?t=3685

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).

divVerent wrote: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).

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.

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.

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.

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.

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

divVerent wrote: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

divVerent wrote: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.

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

airscout wrote: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.

divVerent wrote:

airscout wrote: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.

The MacPorts path equivalent of sw/ is opt/local/

Does it work if you change every occurrence of /sw to /opt/local in install-dylibs.sh, and then run make again?

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

No, it's mapname/lm_????.hdr(hdr lightmap) + mapname/lm_????.png(deluxemap).

divVerent wrote:Does it work if you change every occurrence of /sw to /opt/local in install-dylibs.sh, and then run make again?

Tried the path changes– worked mostly. Led to the discovery that MacPorts doesn't install gdk-pixbuf with gtk2. So, at least for the time being, that one path seems to need to be: /opt/local/lib/gdk-pixbuf/loaders/libpixbufloader-bmp.so

However, I have a query in on a MP mailing list since at one point that wasn't the case and the loaders were in that same location in the path tree as with Fink. Otherwise the executable gets put together and launches properly but something is now out of whack with the application text. The complaint:

Code: Select all

3/5/09 9:53:36 PM [0x0-0x106106].NetRadiant (radiant.ppc:47821): Pango-WARNING **: failed to find shape engine, expect ugly output. engine-type='PangoRenderATSUI', script='latin'
3/5/09 9:53:36 PM [0x0-0x106106].NetRadiant (radiant.ppc:47821): Pango-WARNING **: failed to find shape engine, expect ugly output. engine-type='PangoRenderATSUI', script='common'

Ugly output indeed , check it out:

http://img135.imageshack.us/img135/1607/71134227.png

I wrote:Led to the discovery that MacPorts doesn't install gdk-pixbuf with gtk2. So, at least for the time being, that one path seems to need to be: /opt/local/lib/gdk-pixbuf/loaders/libpixbufloader-bmp.so

Hopefully you'll be able to just ignore my erroneous blathering above . Here's the lowdown regarding gdk-pixbuf loaders and MP from Dave Evans at MacPorts:

"The gdk_pixbuf library is now included as part of gtk2 ... the loaders for the formats I mentioned in the last email are not loadable modules but are built into the gdk_pixbuf library directly. If the app is built against the current gtk2 port, libpixbufloader-bmp.so is unnecessary and will never be called by the program because the built in loader code will be used instead for loading a bmp."

andy

In that case, you probably should remove the gdk pixbuf configuration file that comes with netradiant.

Is it Windows Vista Ultimate Ready?

I tried several times and still no dice, Under Run "Administrator" Priveledges Also.

Is it any way possible to create a distributed q3map2 for compilation on multiple machines at once? Kind of like how distcc works, it sends each client jobs to do and they send back the compiled results. Exept with q3map2 there's no architecture specific issues or header issues.

Could be done like the thread code, send each thread a raytracing job(for -light) or other such job to complete, except in this case it's send each client machine.

This would require a full rewrite of q3map2. Not even the threading is working right, there are cases where you get little splotches on the maps depending on the number of threads.

-lightmapdir doesn't seem to work:

Code: Select all

--- StoreSurfaceLightmaps ---
Subsampling...collapsing...sorting...allocating...storing...************ ERROR ************
mkdir mymap/lightmaps: No such file or directory

It's not creating the directory.