Q3Map2 2.5.13 - The colonel's secret recipe

(ydnar) #1

Q3Map 2.5.13 - The World of Tomorrow

This build has lots of little fixes for specific people and maps and stub code to support other games, such as Call of Duty, in the future. Thanks especially to rgoer for testing every busted version of this getting it right (quick someone hire this bloke!), and Swelt for finally convincing me that the One True Way to CPMA is paved with pie (apologies if you don’t get the joke).

On a side note (and I’m not really sure how to ask, as I’ve never done this before), in June I’m cycling from San Francisco to Los Angeles to support the San Francisco AIDS foundation. I’m trying to raise at least $5000 in donations/sponsorships for this cause. If you’ve used Q3Map2 or just wanted to maybe give something back (or just buy me a pint) or have some leftover tax refund cash burning a hole in your pocket, well…donate here. :slight_smile:

Note: like 2.5.12, this version should be installed in a seperate directory from older versions of GtkRadiant, as its DLLs might conflict.

Download: Win32 - Linux x86

Readme

Version history/changes:



2.5.13 (2004-03-03)

- New: -convert -format <game> to convert between different BSP formats.
  Example, to convert a Jedi Academy map to Enemy Territory:
  -game ja -convert -format et
- New: -game etut support for Urban Terror on Enemy Territory
- New: -analyze mode for reverse engineering a BSP format
- New: -compensate N.N (default 1.0) for descaling lightmap/vertex/grid
  data to compensate for ingame overbrighting. 4.0 is a good value for
  Quake 3 if used in combination with -gamma 2.2
- New: compensate/gamma per-game setting
- New: -light -cpma argument for "classic" (sic) vertex lighting
- Replaced malloc() with stack allocation in IlluminateRawLightmap for
  most small/medium lightmap calculations
- Misc cleanups in q3map2.h
- Support for non-128x128 lightmaps
- The -meta process will now generate surfaces with more than 64
  verts that have non-lightmapped shaders
- Extended lightmap size tolerance to 2x for merging meta triangles in
  maps with aggressive lightmapscale. Sorry kids!
- Moved surface finish pass (celshading, cloning) to final surface pass.
  This should fix a bug involving fog/tesselation/celshading/cloning
- Solid-color lightmaps (within 1/255 in RGB) are detected and replaced
  with a single pixel lightmap, saving space

Enjoy!

y

(kat) #2

ta

(Ramoonus) #3

nice fixes etc

the convert function is the best thing - im waitin for conversions :smiley:

(thegnat) #4

Does that also fix the ‘safeMalloc failed’ problem when compiling with -patchshadows on machines with < 1gig RAM? Or do we still have to compile with -lomem and wait hours? :wink:

Oh yeah! Happy converting! ET:Q3? :rofl: [/sarcasm]

(Ramoonus) #5

noh maps from q3 etc :slight_smile:

(Enforcer) #6

Lol call me dumb! for that is what i am! i just realized that your name is backwards :banghead: :banghead: :bash: :bash:

(cis) #7
  • Extended lightmap size tolerance to 2x for merging meta triangles in
    maps with aggressive lightmapscale.

what is the effect of an increased size tolerance, does it mean the _lightmapscale now only has 50% of the effect of version .12?

(RasputiN) #8

I suspect THESE are one of those effects - though I’m not sure. I do use a global 0.25 lightmapscale and 0.0625 on a few select brushes ( these are not among them ).

EDIT : images removed.

(ydnar) #9

Are you using the -debug switch? Solid lightmaps are colored red in debug mode.

Either way, give this development build a try, see if it cures your woes:

http://akiba.shaderlab.com/GtkRadiant/tools/quake3/q3map2/Release/q3map2.exe

y

(ratty redemption) #10

what are solid lightmaps?

(rgoer) #11

lightmaps in which every pixel (luxel?) is the exact same RGB value.

(RasputiN) #12

ydnar :
no -debug here, the only “special” switch I’m using is the -cpma.
Anyway, the dev build solved the problem, thanks!

(wudan) #13

OOh -analyze mode sounds nice :slight_smile: I’ll have to give it a runthrough the ole’ box and see what turns up.

(RasputiN) #14

It’s me again… the off-coloured lightmaps made a return, but it seems to vary with each build… sometimes they show up, sometimes they don’t. Weird.

Another problem, don’t know if it’s specific to 2.5.13 ( and 2.5.14 ) - some of the patch meshes have ugly black spots on them, like this :

EDIT : images removed, problem avoided by using _rs=0 on patches

(cis) #15

oha, i missed that red stuff, so its a q3map2 problem that i posted here.

edit: rasputin, do u have any pointlights partialy buried in patches? i had the same effect with a much older build when i did that.

(RasputiN) #16

No, I just checked and there are no point lights inside the patch ( not even inside its bounding box ).

(kat) #17

for those getting the missing dll error (q3map2 just flashes onscreen) I’ve uploaded a local version of the missing msvcr70.dll for you to grab and place in the q3map2 directory which should fix the problem, it’ll save you time trying to track the dll down over the net.

(Sinni) #18

I have a suggestion (If its possible), Doing a Q2 style lightstyle eg: style Flicker, style Flourescent Flicker, or style Candle 1.Even if it is still style 1, but have style 1 reference the Flicker lightstyle. It would help n00bs like myself who can’t figure out _styleNrgbGen && _styleNalphaGen to get the light they have invisioned. If someone who is brilliant and wants to use their own wave formula have it something like Sn, where “n” == _styleNrgbGen || _styleNalphaGen

Just a suggestion :slight_smile: