Page 1 of 1

Q3Map2_fs, FYI

Posted: Wed Sep 12, 2007 10:37 pm
by obsidian
Some of you may be aware that GtkRadiant comes with Q3Map2 2.5.17. It's not really a new version, it just a modified version that supports Tremoulus and Warzow mods and a possible slight lightgrid bug fix.

Anyway, seems as if there's also another branch kicking around based off of 2.5.16 and updated by TwentySeven (Urban Terror). There's a few new features and bugfixes (and a few new bugs) so I'm not sure how robust this version is, but some of you may be brave enough to test it. It does solve the vertex paint blending issue I was having. There seems to be almost zero info on it otherwise.

http://ftp.snt.utwente.nl/pub/games/urb ... ps/q3map2/
The FS releases of Q3MAP2 are updated versions of Q3MAP2 .16 by Ydnar. This software is licensed under the GPL. Apply the included patch to the SVN version of q3map2 at https://zerowing.idsoftware.com/svn/rad ... ant/trunk/ to get a working source code.

q3map2_FS_XX.exe, q3map2_FS_XX.exe.manifest, Microsoft.VC80.CRT.Manifest and the dll's are needed to run.

--------------------------
Q3MAP2_FS_3.exe

Light samples are clipped to the bounds of their source triangle (not quads yet)
++This fixes triangle-seam black mark splotching on .ase models, thin brush models, and light leaking through thin joints.

Supersampling is broke, thats on my todo. Filter and Bounce still work as intended.

The PVS test was removed from "contributiontosample" - could make stuff slower for a while.

"-exposure" was added as a replacement to q3map2 standard light "normalization", uses exponential scaling
usage: -exposure 60-250
200 seems like a good starting value.
Exposure of 1 (default) will force standard q3map2 normalization/clamping
Exponential exposure control lets you use ALOT brighter lights in scenes without worrying about oversaturation/clamping
(dimmer lights will show up better too)
-- having really good results with no gamma, no compensation, and r_mapoverbrightbits to 0

--------------------------
Q3MAP2_FS_4.exe


"-floodlight" was added. New ambient lighting replacement. Defaults are ok but you can change a worldspawn key.
Note that this WILL bounce light in -bounce stages, so you might want to turn the intensity down.. or it'll get quite bright outside.

"_floodlight" "r g b distance intensity" with red, green blue, and "distance" a sample has to travel to contribute 100%.
defaults to 250,250,255, and 1024 distance. 2048 makes occluded rooms darker, 512 makes occluded rooms brighter.
intensity defaults to 128

example keys:
_floodlight 1 1 1 512 32
_floodlight 1 1 1 1024 64
(brighter indoors, less light overall)
(darker indoors, more light overall)
--------------------------

q3map2_fs_5.exe

- Lightgrid was fixed up so ambient is now 25% of the total light for a given sample. This was previously broken, so no more mingridlight is required
- When using -floodlight, the lightgrid takes a bit longer to compile but is sampled versus the floodlighting fairly decently.
(two floodlight samples are taken, upper and lower hemisphere with "normals" of 0,0,1 and 0,0,-1, and are attributed as directional lights to that point)

---------------------------

q3map2_fs_6.exe

"-lowquality" flag was added. Will speed up floodlighting by a factor of 10x or so, should be fairly close to the proper product but noisy.
- Fixed the black wall issue.
- bug?: "surfaceparam sky" should be correctly appearing invisible to floodlight checks.. not sure whats up there. Means you could get dark rooftops.

---------------------------

q3map2_fs_10.exe
- q3map_lightrgb can now be used to override the light color of surfacelights
- whole heap of epsillion issues

-----------------------------
q3map2_fs_13.exe
- Cleaned up normals for .ase and .md3
- .ase SGs supported now
- DO NOT USE FILTERRADIUS - I didn't break it but it sure does break things.
- you will probably need to use a finer lightmapscale (0.5 or smaller) to get nice curvature on meshes using sg's

-----------------------------
q3map2_fs_14.exe

-----------------------------
q3map2_fs_16.exe
-debugnormals switch in light stages
-using _floodlight in your worldspawn key turns floodlight on always, same as any other light
-turned off filtering for floodlight on ase meshes, which was causing some shading problems.

-----------------------------
q3map2_fs_17.exe
-.ase Mesh face normals were coming in wrong from the file, alot. Rebuilding them manually at load time now.
*this effectively broke alot of stuff that depended on them to get good smoothing/lightmapping

-----------------------------
q3map2_fs_18.exe
-Experimental - Autoclipped faces will now try and use quads.
- Really ugly meshes might confuse this code. Works ok on terrain and platonic solids from 3dsmax so far.

-----------------------------
q3map2_fs_19.exe
-undid fs18

-----------------------------
q3map2_fs_20.exe
-Fixes to floodlight (twosided, not testAll)

-----------------------------
q3map2_fs_20g.exe
-Now compiled as 'release' in MS VS2005 instead of 'debug' in MS VS2003 (woekele)

<3, TwentySeven.

Re: Q3Map2_fs, FYI

Posted: Sun Sep 23, 2007 10:58 pm
by Hipshot
Did you ever get this to work? For some reason, my texture won't blend in Q3, do I need some special key for the terrain or some comple option?


The shader I'm testing looks like this, copied from the Urban tutorial.

Code: Select all

textures/nej/grid
{
	{
		map textures/nej/grid2.tga
		rgbGen identity
	}
	{
		map textures/nej/plat.tga
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		rgbGen identity
		alphagen vertex
	}
	{
		map $lightmap
		blendFunc GL_DST_COLOR GL_ZERO
		rgbGen identity
	}
}

Re: Q3Map2_fs, FYI

Posted: Sun Sep 23, 2007 11:05 pm
by Hipshot
2 sec later, works great.

Seems I forgot to change the path from Q3map2 til Q3map2FS =) Quiet an error =)

Re: Q3Map2_fs, FYI

Posted: Sun Sep 23, 2007 11:08 pm
by Hipshot
Hell, when I started making terrain i Max last autumn, I thought, wouldn't it be damn cool if I could vertex paint and then use that in Q3, but after like two failed attempts, I just thought that it was to much for the old beast. So I went placing alphamod brushes everywhere, fuck that sucks, take more time than doing the actual terrain. Damn this is good.

Image

have you noticed any side effects with not using the regular Q3map2 216?

Re: Q3Map2_fs, FYI

Posted: Mon Sep 24, 2007 12:33 am
by Hipshot
Wow, ownage, now I can use the blend function as it should be used, I can actually see how the terrain will look like without even having to make a pass through Q3map2. If anyone know, how to alpha paint with textures instead of colors, should, that would be the ultimate... not having to use the render thingie in max...

Image

Re: Q3Map2_fs, FYI

Posted: Mon Sep 24, 2007 1:00 am
by Silicone_Milk
lol somebody's excited ;)

Re: Q3Map2_fs, FYI

Posted: Mon Sep 24, 2007 1:06 am
by obsidian
I haven't tested it enough to know if there are any other issues, but if you read the readme, there seem to be a few minor issues with some of the other Q3Map2 functions. Vertex blending is ace, though.
Hipshot wrote:If anyone know, how to alpha paint with textures instead of colors, should, that would be the ultimate... not having to use the render thingie in max...
Alpha paint with textures... as in your texture's alpha channel? :dork:

Re: Q3Map2_fs, FYI

Posted: Tue Sep 25, 2007 7:25 pm
by Kat
I think he means using textures instead of coloured vertexes to paint, just makes seeing what you're doing easier at a glance. Using texture in Max to do that would kind of defeat the purpose really as you'd need to 'convert' the paint to verts anyway for the export process to work the way it's supposed to.

Re: Q3Map2_fs, FYI

Posted: Tue Sep 25, 2007 7:30 pm
by Kat
Hipshot wrote:Hell, when I started making terrain i Max last autumn...
lol, I asked ydnar about this a couple of *years* ago, he never implemented it at the time because he questioned it's usefulness, certainly considering there were only a handful of people that would actually have used the feature; required a complete rewrite of chunks of code from within Q3m2 as well which he wasn't too keen on (can't blame him for that really).

Re: Q3Map2_fs, FYI

Posted: Wed Sep 26, 2007 11:59 am
by Shallow
Correct me if I'm wrong, but as I understand it one of the main issues with ASE vertex blending was that ASE format doesn't actually store vertex alpha. So, I'm assuming that TwentySeven's version of Q3map2 is using the vertex colour channels for alpha? I think this is what Hipshot's getting at.

It's a shame, because if you could paint the vertex alpha instead of colour in Max, there's a DirectX shader included as standard that allows you to alpha blend two textures, and to preview it as you paint in the viewports. It would be fine to use that on the model in Max since Q3map2 doesn't care what's inside an ASE file's material, it merely uses the name to reference a Q3 shader.

Actually, I guess it would probably be fairly easy to write a MaxScript to cycle through all the vertices on a model and copy the alpha value for each one to its R, G and B channels. Then you could paint the alpha, with preview, run the script and export to ASE.

Either that or someone could write a modification for that Max shader that used colour to blend instead of alpha: Max's DirectX9 materials are just FX files, which I think is a standard format.

It's when you come up against these annoying limitations in standard model formats that you quickly understand why games so often use proprietary ones.