Q3Map 2.5.7 "Oops I did it again"

(ydnar) #1

Q3Map 2.5.7 - The Man

Win32 (x86) - Linux (x86) - Darwin/Mac OS X (PPC) (2.3.36) - Readme

Lots of happy deep-fried goodness. Oblig readme c/p:


2.5.7 (2003-08-31)

- New: Jedi Academy support via -game ja
- New: DDS (DXT1/3/5) texture support for future games
- Re-enabled q3map_surfaceModel support, and the 'oriented' flag works as well
- Re-enabled (fixed, really) large external lightmap support
- Fixed a bug in the model code that would cause a crash if an uninvertable
  matrix was created
- Fixed a bug in Mathlib m4x4_t code where the tolerance for a singular matrix
  was too low and crapping out on small (scaled down) matrices
- Fixed bug in divide-by-zero on lightmap efficiency calculation
- Added -force switch, allows unsupported BSP formats to (try) to be loaded

y

(ogun) #2

Really, did anybody (except for mr. y) get all of that? :eek:

(pazur) #3

me likes the icon :moo:

(Hewster) #4

mmm, can we have COD with that :wink:

Hewster

edit: typo :confused:

(Emon) #5

EFII uses DDS.

(Hewster) #6

that maybe true , but can we “deep-fry” EFII ?

sorry, I’m just trying to de-crypt Ydnars secret messages :wink: hehe

btw, looking at NVIDIA’s tool for exporting DDS, currently leaves me a bit confused !!
And since its a DX dervied tool, I wonder if games using DDS will be ported to Linux.

Hewster

(ydnar) #7

I wrote a DDS library based on nvidia’s example code. It’s BSD licensed, and part of the GtkRadiant project. You can view the source here (ddslib).

y

(Emon) #8

Looks like Raven or LEC sent ydnar a copy of JA. Least they could do for his work over the years that would cost hundreds of thousands of dollars to reproduce. :slight_smile:

(ydnar) #9

Heh, that’d be nice, especially since LEC is in my neighborhood. But alas, no prizes for ydnar. I heard some rumblings from my friends at Raven though, we’ll see…

y

(Emon) #10

JA support without JA, certantly…interesting. :wink:

(rgoer) #11

Raven used q3map2 to compile their in-house maps for JA during development. If they wanted q3map2 to work for them, I’m sure they got in touch with ydnar to find out what they needed to do to get it to work. That’s not really that interesting.

(Codey) #12

I did a quick search of the net, but didn’t find anything definitive, so I’ll ask here:

Why use DDS over 32bit TGA? what’s the advantange(s)

Thanks in advance

(Hewster) #13

:slight_smile: cool

WHAT !! you don’t get any perks for them using YOUR work !! this needs
sorting

umm, well don’t take this as fact, but it seems the compression method is
somewhat awesome :slight_smile: in some tests I did using a 1024 x 1024 image,
when saving as 24bit TGA, the file size was 3Mb, when using tga RLE
compression it was 2.5Mb, when saving as JPG (with minimum loss of detail)
the file was 600Kb, and using DDS it was 512Kb.

There are LOTS of other options in exporting DDS, such as including
mipmaps in the file & LOADS of other stuff see pic:

Hewster

(rgoer) #14

Wow–DDS looks awesome. Thanks for the info, Hewster… the only DDS I knew of was related to dentistry, so I was a bit puzzled what all the hub-bub was about.

(Emon) #15

Looks like it would save on file size and time by letting you impliment basic shader functions right into the texture.

(Codey) #16

kewl, yes thanks for the info Hewster, that sheds a bit of light :beer:

Pitty the only real advantage with RTCW would be the smaller filesize, since we would have to modify the rendering engine to take advantage of other features, or could ydnar fudge these somehow into existing functionality?? :eek:

(Emon) #17

DDS couldn’t work for anything but a game that supported it, like EFII.

(Codey) #18

I don’t know about that emon, there is alot of things which could get translated straight from the image format if ydnar was inclined to do it

(RabidCow) #19

First off, Thanks greatly for your new version! :). I now have a large external lightmap for my terrain again with 2.5.7.

One peculiarity though, is that it creates two lightmaps of the size I expected, one completely black. Its not really a problem since I could delete the second lightmap with no deliterious effect on the display ingame. When I saw the two lightmaps, I deleted them both and recompiled to double check what was happening and repeated the same problem, so it wasn’t from an earlier complile. Anyway, the shader I used for my terrain that created this was…

textures/jeff10c/terrain_0
{

q3map_nonplanar
q3map_lightmapmergable
q3map_shadeangle 120
q3map_lightmapsize 512 512
q3map_lightmapGamma 2.0
q3map_lightmapsamplesize 2
q3map_lightmapaxis z
q3map_texturesize 512 512
q3map_tcGen ivector ( 512 0 0 ) ( 0 512 0 )

{
	map textures/jeffj/grassbrown.tga
	rgbGen identity		
	
}

{
map $lightmap
tcGen lightmap
blendFunc GL_DST_COLOR GL_ZERO
rgbGen identity
}

}

I realize the q3map_texturesize can be eliminated, but it was there during the compile so I left it in…just in case it was related.

One other small question…because my map is not square (it is rectangular), only half of the lightmap is used, doubling the required memory (i tried cropping it awhile back and that didn’t work :)), is there any possibility that the lightmapsize could be 256 512 etc?

Anyway, fabulous job Ydnar! Everything just gets better and better…

(ydnar) #20

Yep, lightmaps can be non-square.

Nice shot. :slight_smile:

BTW, due to recent fixes here and there, you might be able to get away without having to use an external lightmap on that terrain, especially since it has a darker/different texture.

Try nuking the lightmapsize/gamma/samplesize/mergable lines and recompiling.

The reason for the extra black lightmap was because Q3Map2 now creates an even # of lightmaps. For every new lightmap created, there is another created of the same size. This is so the lightstyles shader hacks can use a minimum amount of unique shaders.

y